一个做Saas的朋友前阵子问我：我们公司就一条产品线，现在要拓第二条，支付这块得重新搞一遍吗？
我说你现在的支付怎么做的？
"就对接了微信和支付宝，业务代码里硬编码的。"
那你第二条业务线也这么搞？
"也得这么做啊，不然还能咋办。"
我说你这就是典型的"支付功能"和"支付中台"的区别。一条线的时候无所谓，两条线以上——没有中台，光支付这块就能把人累死。
这篇文章不是讲理论，是把支付中台怎么从0到1搭起来、每块干什么、能给你省什么钱，全部拆开来讲。
---
先搞清楚一个事：支付中台不是什么高大上的概念。
说白了就是——把支付能力抽象出来，做一套统一的工具，让所有业务线都能用。
一条业务线的时候，你只需要一个支付功能。
两条业务线的时候，你发现很多代码是重复的。
三条、四条呢？运营要管N套支付渠道的流水，技术要对接N遍微信和支付宝。重复的事情做三遍还不抽象，就是在给公司挖坑。 这事我见的多了去了，真不夸张。
那中台能干嘛？
对运营：一个平台管所有商户进件、支付配置、对账、分润、分账。不用今天登微信商户后台、明天登支付宝开放平台。
对开发：新业务线接入支付，调中台接口就行，不用重新对接支付渠道。新渠道接入，中台改一次就行，所有业务线都能用。
对老板：多一条业务线的边际成本大幅降低，而且支付流水能带来分润收入——业内叫"睡后收入"。
---
支付中台不是一套代码，是一套能力。核心就5个模块，每个都能单独拎出来说。
### 2.1 商户账号配置
你Saas服务商要帮商户收款，商户得有收款账号。账号从哪来？你得替商户去支付渠道（微信、支付宝、银联等）做进件申请。
进件分两种模式：
直连模式：商户直接在支付渠道下申请一个商户号。简单但费率没有优势。
服务商模式：商户挂在你（Saas服务商）的服务商下面。费率更低，而且每笔交易你都能拿到分润。这也是很多Saas愿意做支付中台的根本原因——不是功能需求，是商业需求。
运营人员或者代理商在支付中台里替商户走完进件流程，配置好支付账号、绑定支付渠道、设置路由规则，商户就能收款了。一套流程走完，后期基本不用再管。
### 2.2 支付核心系统
这是中台的心脏。
用户在前端发起支付（POS扫码、小程序拉起、APP内支付），请求到了支付核心，它做两件事：
① 路由决策：根据商户配置的支付渠道和路由规则，决定这笔订单走微信还是支付宝还是银联。
② 指令转发：把支付指令转发给对应的支付渠道，然后把渠道返回的结果同步给业务线。
围绕这个核心，还有几个配套能力：
能力 | 干什么用 |
:---|:---|
统一下单 | 不管B扫C、C扫B、JSAPI还是APP支付，统一入口接入 |
订单查询 | 异步回调没等到？主动轮询查状态 |
退款 | 成功交易后发起退款，原路返回 |
撤销 | 超时或失败的订单，关掉防止重复支付 |
回调通知 | 支付/退款完成后，通知业务系统更新状态 |
听着复杂对吧？但你把这些都放到中台里，新业务线接的时候——一个接口搞定所有支付场景。
### 2.3 对账模块
对账是最容易被低估的模块。
每天早上运营要做的第一件事：前天收了多少钱，和支付渠道的账单能不能对上。
没有中台的时候，运营需要登录每个支付渠道的后台去下对账单，然后手动比对。对！手！动！ 这种活干一个月还行，干一年真的会让人想跑路。
有中台之后，系统自动拉取各个渠道的对账单，和系统内的交易记录做比对，不一致的标出来。
从门店维度、收银员维度、POS维度、支付渠道维度——想看哪个维度都行。
对不上账才是一个Saas服务商最大的风险，比系统宕机还让人头疼。
### 2.4 分润模块
这是每个Saas老板最关心的模块。
你替代理商做支付进件，代理商的商户交易走了你的服务商通道，支付渠道会给你分润。这笔钱你得分给你的代理商——按事先约定的比例。
分润模块的核心逻辑就一句话：每笔交易进来，按配置好的分润规则，自动算出各方该拿多少。
如果商户用的是代理自己的服务商（不是你的），那分润跟他自己跟支付渠道算，你这边不用管。
### 2.5 分账模块
很多Saas服务的客户是连锁品牌——总部统一收款，然后按比例分给各个门店。
这就是分账要做的事。
分账日到了，系统按照预先设置的比例，把资金分给各个参与方。不用人工一笔笔去算，也不用财务每个月手动转账——系统自动分，省事又合规。
---
不管你搭什么中台，最终落地的都是具体的支付场景。常见的有4种：
### 3.1 B扫C（被扫）
商家拿扫码枪扫顾客的付款码。零售场景最常见的支付方式。 顾客打开付款码就行，操作由商家完成。
流程：收银系统发起 → 支付核心路由 → 支付渠道扣款 → 结果通知
### 3.2 C扫B（主扫）
顾客扫商家的动态收款码。商家在POS端生成一个带金额的动态码（一次性使用），顾客扫码后在手机端确认支付。
流程：商家生成订单 → POS展示动态码 → 顾客扫码 → 手机端确认支付 → 支付核心处理
### 3.3 JSAPI（公众号/小程序支付）
顾客在公众号或小程序里下单，调起微信支付。码牌支付本质上也是JSAPI的一种——静态码附着页面链接，用户扫码后在自己手机上完成支付。
流程：用户在页面下单 → 调起各支付APP → 输入密码 → 完成支付 → 回调通知
### 3.4 APP支付
发生在Saas自有APP内的支付。用户选择商品、发起支付、跳转支付渠道收银台、输入密码完成。
流程：APP内发起支付 → 获取预支付信息 → 调起各支付渠道APP → 用户支付 → 回调
---
支付中台不是什么神秘的东西。它是一套架构，更是一套生意逻辑：
- 技术上：把重复的支付能力抽象成统一的平台，新业务线接入成本降到最低
- 运营上：一个平台管所有支付渠道的进件、对账、分润，不再需要登录N个后台
- 商业上：支付流水带来的分润是Saas服务商的天然收入来源，支付中台是收钱的管道
回到开头那个朋友的问题。他不是一定要搭中台——一条业务线确实不用。
但如果你有两条以上，或者你打算拓展更多业务线——越早抽象支付能力，后面的坑越少。
长胜证券提示：文章来自网络，不代表本站观点。
