从 0 开始的支付业务架构演进之路

随着互联网的高速发展，线上支付已成为各行各业不可缺少的一个环节。一个公司面对支付的解决方案，可以是简单记录三方收单支付结果，也可能是一个庞大的系统（如 交易，清结算，账务，风控，渠道路由等）支撑。作者从业与支付解决方案数年，在支付系统方面有点自己的见解，今天就和大家一起分享下怎么去搭建一套支付系统。

渠道模块层

作者这里假设 A 是一家电商公司。A 公司创业初期，业务量还不是很大，满足用户线上支付形成闭环，A 公司找了微信对接（相信大部分公司都是这样）。这时候 A 公司的支付系统就只需要记录所有微信的支付结果。但当微信上线一段时间，A 公司为了方便用户，又对接了支付宝支付。这时候我们考虑到公司可能后续还会对接 QQ 钱包，百度钱包，云闪付等，所有我们这时候会把所有对接三方支付的能力进行抽象，我们就有了渠道层。可以说渠道层是一切支付接入的基础。

当然，公司订单起量时，微信/支付宝手续费对于公司是一笔巨大的成本。为了节约成本，公司决定引导用户使用银行卡支付，这样 A 公司不得不去找有银行卡收单的银行或支付公司对接。为了保证成功率和成本，A 公司一般会选择多家银行或支付公司对接，这时候我们渠道就需要较好路由。当对接的支付公司越来越多时，我们就会抽象一套公用的对接模板，同时也会统一整合出口网关。

交易及产品层

刚提到的支付，只是满足于用户简单支付场景。但随着公司业务的发展，公司会延伸不同的交易场景，如电商常见的担保交易与即时到账。公司想提升用户的粘度，开放充值功能和余额支付（这里先暂不谈合规问题）。有了充值当然就会有提现，渠道侧我们还要去对接银行/支付机构的出款通道。公司可能发放红包，代收代付等场景。所以我们针对于不同的交易场景，我们需要定义一套交易产品。

账务与会计

随着用户余额模式的使用，这就必须使得我们要建立一套账务系统来记账。最开始可能只需要一个字段来记录用户的余额，但随着业务场景的多样性，对于部分资金只有在特殊场合才能使用，所有我们要引进多账户概念。我们对于资金属性不同的分类又要以借记，贷记，冻结区分。当然提起账务，不得不想到财务和会计，所有我们在记账时候，建立的账户号要根会计科目挂钩。因满足财务要求，除了用户账户（称外部户）我们还需要建立一些内部户来满足记账要求。当账务产生变更流水时候，我们需要将数据送到会计系统，形成会计分录，并生成试算平衡表等。

支付清结算

刚刚我们上面谈到的交易产品，种类很多形势各样。对于每种产品对应的账务处理及资金结算我们不能放在交易层处理，这里我们会抽出支付清结算模块。支付层主要上接交易层，下对渠道和账务模块。

1 指令定义：支付业务流程的抽象，我们可以抽象定义为 入款，出款，转账，退款。

2 渠道清算：对外（外场-外部银行支付/机构）清结算规则定义，请求银行渠道清算。

3 账务处理：对内（内场-账务体系）清结算规则定义，账务复试记账条款。

对于支付层的设计，我们要抛开业务产品形态的影响，尽量配置化去设计，以工作流的方式去定义支付指令的流程。

商户及其接入

当 A 公司业务拓展迅速，有不同的业务部分都需要对接支付时候，我们就需要对每个业务线单独管理。这里我们把各个业务线就是我们的商户（也可能外部其他公司），对于各个商户有不同业务诉求，我们就需要搭建一个商户管理平台。主要包含以下内容：

a 商户基本信息：即接入平台方的信息记录。

b 商户秘钥管理：安全对于支付非常重要，通信签名必不可少。所以我们需要对于证书/秘钥的发放做管理。

c 权限管理：不同的商户接入，肯定有不同的权限，保证接口不能跨商户号调用。

d 产品管理：对于不同产品接入的管理，给商户赋予各交易产品能力。

e 路由管理：一般解决商户指定接入渠道，如 XX 业务线只走 XX 支付通道。

f 账单管理：满足商户对账诉求以及账单流水查看。

A 公司为了满足各业务线（商户）快速接入，这时候可能就会统一包装支付收银台，这里包含支付方式的展示，以及用户点击支付的统一流程。考虑到不同终端的需求，我们收银台也会提供多个版本（app web H5 等）。

存管层

在刚刚聊余额支付谈到了合规问题，如果公司有三方支付牌照，这里就不再叙述。但公司如果没有牌照，用户充值的余额就需要落到银行或支付公司账户，可能大多数公司都还是直接用的银行或支付公司的记账。但公司已经自己在做记账或考虑到存管体系的替换，这里不得不延伸存管层的概念。存管模块主要来负责处理用户余额，交易和银行的同步。如 A 公司 和 B 银行进行商业合作，A 公司所有用户都在 B 银行开户，方 A 公司内用户发生交易时，肯定 B 银行内对于的账户也要进行发生交易。

对账层

其实上面我们已经谈到对账。当支付完成后，对账也是支付系统必不可少的一环，当 A 公司最开始只接微信的时候只虚和支付机构对账（或者直接使用三方平台）。但随着系统的增多以及业务系统的发展，我们除了和各支付机构对账，也需和各商户对账。甚至内部系统模块增多，我们也需要内部系统间的对账，来确定是否有漏单问题。

商户对账：支付系统和业务方的对账，D+1 产生即可，需商户主动拉取。

内部对账：支付各模块间的对账，需做到准实时，反应支付系统现在。

渠道对账：支付与银行或支付机构对账，一般 T+1 或 D+1。

支付风控

支付毕竟直接是和钱打交道，当支付起量时风险控制也必不可少。具体针对于风控规则的制定就不再叙述，毕竟每家公司都有自己的一套策略。支付风控是通过采集交易、渠道、账户、用户等信息，对这些数据进行实时和定时的挖掘分析，所以我们最好用大数据知识搭建一套合理的数仓。

最后做个总结吧，没有一套最好的支付系统，只有最适合你公司的一套支付系统。个人浅薄认知，希望对大家有所帮助，不喜勿喷~