立即登录 做了几年支付产品，时不时会被人问起，支付系统到底是怎么回事。以前整理过一份内部资料，但总觉得对内讲的东西，未必适合直接拿出来说。今天刚好有空，也想趁这个机会把思路理一理，写出来跟大家交流，就当是练习，也希望能碰撞出一些新的想法。
支付系统的使命其实特别简单：给各种业务场景提供支付能力。如果只是服务一两个业务倒还好，可一旦要对接很多业务方，系统设计就必须往模块化、公共化的方向走——把最基础的能力沉淀成通用的服务，这样才可复制、可配置地支撑不同业务。在这个定位下，支付系统通常会被放在中台那一层，成为支撑前台业务的基础能力。
在进入具体架构之前，有两个概念最好先拎清楚：信息流和资金流。信息流指的是整个交易过程中流转的指令和数据，比如谁下了单、谁发起支付、结算指令怎么传；资金流则是真金白银的变动，从储蓄卡余额、信用卡额度，到钱包里的钱，这些都属于资金流动。把这两条线分开看，很多设计上的问题就更容易理解。
接下来，我们按信息流的视角，把支付系统拆成四层来看。
第一层是应用层，也就是直接使用支付能力的业务场景。你在电商网站下单、在餐厅餐后扫码付款、买理财产品、给账户充值，这些场景背后都对应着支付系统在运转。应用层就是形形色色的业务方，他们不需要知道支付有多复杂，只需要拿到结果。
第二层是服务层。这里提供的是具体可用的支付功能，最典型的就是收银台。收银台把银行卡快捷支付、信用卡支付、网银支付、支付宝、微信支付等聚合在一起，业务方接一个收银台就能用上多种支付能力。除此之外，接口服务还会封装一些原子能力，比如扣款、付款（也叫提现）、退款、分账，这些功能通过接口直接暴露给业务层调用。
第三层是基础层，核心是支付路由和渠道网关。路由的作用，说白了就是在多个可用的支付渠道里，帮你选出一条最合适的，比如成功率更高、成本更低的那条。根据公司所处的阶段和业务复杂度，路由可能是人工配置的，也可能是系统根据规则自动决策的。选好渠道之后，网关就负责把请求发给对应的渠道，然后完成后续流程。目前，大部分支付公司都需要经过银联或网联这类清算机构，和银行连接起来，所以渠道网关后面往往还要对接清算层的通道。
第四层是支撑层，这一层是保障整个支付系统稳定运行的后盾，比如监控预警、异常处理（重试、补偿任务）、数据报表等服务。它们不直接参与支付指令流转，但离了它们，系统出了问题就很难快速恢复。
有了这个架构打底，支付能力最终还是要靠渠道来落地，所以有必要单独聊聊支付渠道。
渠道对接模式经历过一次比较大的变化。2018年6月30日之前，很多支付公司是直连银行，一家一家银行去谈合作，银行开放接口，支付公司就接进来。那时候各家拼的是谁接的银行多、额度高、费率低，能力差异很大。后来监管要求切断直连，支付公司和银行之间必须通过网联或银联来清算，对接模式就变成了间连。这样一来，各家支付公司能拿到的扣款能力差别就不大了，银行覆盖、限额、费率都趋同，也就没必要接太多渠道，覆盖主流需求就行。
渠道提供的产品，说几个常见的。代扣，以前常被叫做裸扣，意思是用户不用输短信验证码，支付公司就能直接扣款。因为合规收紧，现在裸扣接口基本很难见到了，市面上还能用的代扣大多是包装出来的，比如用银联的无卡支付产品包装，或者通过撞库拿到协议支付的协议号再包装成代扣。至于扣款所需的验证要素，有的渠道用四要素，有的只用二要素（身份证、卡号）或三要素（姓名、身份证、卡号），要素越少，成功率可能反而越高，但风险管控的要求也不一样。
快速支付，也就是协议支付。用户第一次绑卡的时候，银行预留手机号会收到验证码，回填验证码之后，就生成一个协议号，这个协议号绑定了银行卡、支付公司和发卡行三方的签约关系。后续扣款的时候，凭这个协议号就能直接扣，不需要再走短信验证流程。网联的协议支付和银联的首次验短产品，基本上都属于这一类，大家习惯上就叫快捷支付。在这个基础上，支付公司还包装出了各种变种，比如认证支付，每次支付都要短信验证；还有虚假协议支付，第一次验了短信，但后面其实用的是假的协议号，这类产品风险相对高一些。
除了扣款，支付渠道还能提供其他服务。比如代付，就是把钱付出去，可以对接银联代付或者人行的大小额系统；退款，一般是原路返回；分账，可以把一笔钱分到不同的商户号或账户里；鉴权，用来验证实名信息，比如姓名、身份证号、卡号、手机号是不是匹配，支持二三四要素鉴权，常用于绑卡前的校验。
最后再聊一下支付路由的自动逻辑。规则路由的思路很直接：先过滤，把不可用、不满足条件的渠道筛掉；再排序，在剩下的渠道里按优先级选出最优的。路由决策依赖的支付要素主要这么几类：卡信息，包括发卡行、卡类型（借记卡、信用卡）、信用卡的属性等；限额，单日限额、单月限额；费率，有固定费率（比如每笔几元或者按比例），也有阶梯费率（比如小于1000元收2元，超过2000元按0.2%收）；业务要素，不同主体下的商户号、业务类型（是退款还是分账）都会影响渠道选择；最后还有操作规则，比如人工调整优先级，或者针对某些特殊错误码做特殊判断，用来优化成功率、处理异常情况。
支付系统的基础框架大概就是这些。如果有什么遗漏或者理解有偏差的地方，欢迎留言讨论，一起学习。
