摘要
企业在接入支付渠道的时候, 最害怕的就是各个部门都自己管自己的事情。对账工作基本上全都靠Excel表格来处理。这篇文章讲得非常清楚, 它会分别说明综合支付、统一支付、支付中台、支付中心以及结算中心各自负责什么事务。
文章还给出一套完整的思路, 从最初的渠道归一化开始, 一直到最后实现资金的分配。这样做可以帮助技术团队和管理层把大家的说法和口径全部对齐。
先把几种概念分开来看。综合支付, 就是把银行卡、微信、支付宝、数字人民币这些渠道, 都放到一个接口后面, 业务端只需要调用一个方法。
统一支付是在综合支付的基础上, 额外增加了一层功能: 它把支付状态机, 做了统一；它把幂等逻辑, 做了统一；它把差错处理, 也做了统一；它的目的是让多条业务线能够共用一套规则。支付中台是一种技术上的抽象做法, 它的做法是将支付能力从各个业务系统里抽取出来, 最终形成可复用的服务。
支付中心是从产品的角度来开展工作的, 它为运营部门和财务部门提供了数据看板、退款审批流程还有渠道监控的功能。结算中心主要是负责管理资金应该如何进行分配, 它会处理商户、平台以及渠道费用是如何拆分的问题, 涉及到采用T加1还是T加0的结算周期, 以及分账规则究竟应该如何配置。
在落地的时候, 最常见的坑就是渠道各搞各的, 对账全靠人工来做。
建议分成三步去走, 首先第一步叫渠道归一, 就是把那些散落在各处的支付SDK收拢到统一的网关里面来；接着第二步, 是把订单状态、回调机制以及幂等逻辑沉降到支付中台里去；最后第三步, 是让结算中心挂在支付中台的后面, 然后根据业务规则来进行自动分账, 这样就减少了人工干预的情况。
在挑选方案的时候, 千万不要只是去盯着功能列表看, 而是要把重点放在这四个方面上面。第一点是要看多渠道是否能够并行接入, 第二点是看结算规则是不是可以配置, 第三点是对账过程能不能实现自动闭环, 第四点是接口文档是否写得非常清楚。
如果在后续的使用过程中, 需要去接诸如跨境、虚拟账户这样的一些场景, 那么就要考虑架构方面到底有没有留出扩展的空间, 这一点的重要性是超过它能够为当下节省多少开发工时的。
FAQ：
Q1：支付中台和支付中心是同一个东西吗？
并不是这样子的, 那个中台它主要是更偏向于技术这一层的, 它是去输出能力的接口的；然后那个中心呢它就是更偏向于业务那一层的, 它是去输出运营的看板以及管理的功能的。
Q2：业务线少，需要一上来就建支付中台吗？
完全不用急着动手, 第一步就是先把综合支付网关给搭建起来, 好把那些分散的渠道全部都收拢到一个地方来。等到你的业务线数量超过三条这个界限的时候, 再去思考要不要抽出中台这块东西, 这么做能避免出现设计过度这种浪费资源的状况。
Q3：结算中心必须自建吗？
这种情况并不一定是这样的。有一部分通道, 它们自己的系统里就带有分账的功能, 但是, 当业务场景涉及到多个商户参与, 以及需要分层级进行分账操作的时候, 选择自己去搭建一个结算中心, 会显得更为灵活, 并且对整体状况的控制力也更强。
Q4：统一支付和综合支付到底差在哪？
综合支付这个技术能够解决一个接口对接多个渠道这个问题, 至于统一支付呢, 它是在综合支付的基础上头, 把状态管理这一套东西给统一起来了, 同时也把异常处理给统一了, 还有那个幂等机制也跟着被统一的进行了规范。
