支付系统设计概览

前言

就个人对支付的一些理解和经验，在此编辑出来和大家一起交流分享。请大佬多多指正。

1. 在各种互联网场景中，牵扯到交易的情况，大多都需要支付系统的支持。
2. 支付系统往往不是一蹴而就的，往往都是随着业务的不断扩展，进而不断演进。
3. 项目初期阶段不要太过于追求大而全的系统建设，适应当前阶段系统的发展就好。
4. 无论什么阶段的支付系统，在处理数据时都需要注意幂等和安全问题，避免资损。
5. 对于信息的验证一定不能少，注意临界值情况，注意信息的完整性。
6. 该有的验签和加密流程切勿不能少，要抱着不能信任的态度去处理请求。
7. 在支付过程中未明确得到响应的情况下，不要贸然凭借个人经验将订单修改为终态。
8. 针对渠道的请求一定要尽量多保留一些现场，方便后期随时排查。

支付演变

简易版支付系统

在以前接触到的一些简单项目中，由于这个阶段业务需求较简单，仅仅需要满足一个支付场景（例如使用支付宝支付或者微信支付），为了快速上线，设计方案就简单粗暴，对外直接暴露支付服务接口，由业务系统发起直接调用。如下图。

这个阶段由于只有一个支付渠道，也不需要有路由系统，直接由业务系统调用支付服务接口发起支付。比较简单易用，但是这个设计方案存在很多问题：
- 业务系统与支付系统位于同一个系统，系统任何一次变更都会影响整个系统。
- 扩展性问题。接入新支付渠道，如微信，需要新暴露一个微信支付服务接口。业务系统需要改动代码。从另一方面讲，业务系统承担路由系统的功能。
- 复用性。新支付渠道，其实除了与支付渠道交互相关代码之外，其他代码可以复用。
因此针对以上问题，新的系统需要进行相应改造。

进化版支付系统

在随着业务规模的不断扩大，需要接入多个三方渠道为系统提供服务，应对限额和风控、限流、并发等等的问题。因此将支付系统与业务系统单独拆分出来，成为两套单独的系统。支付系统对外暴露一组通用接口。业务系统仅对接这组接口。业务系统若想指定支付渠道支付，接口参数传入渠道标识即可。这样就将耦合在业务系统中的支付功能下沉到支付系统统一的管理。整体的架构大概如下图：

1. 业务系统只需要将订单上送至订单中台，在订单中台中会进行进一步的处理，如扣手续费等；同时会根据购买产品策略将对应的订单进行拆分，（例如购买投顾产品，会按照策略中配置的购买比例进行拆分，然后针对不同的标的购买一定份额的产品），接下来就会将这些子订单发送给支付中台进行扣款。因此，订单与支付单的关系可能是1:N。
2. 支付系统首先会收单，然后根据一定的路由规则或者业务方指定的支付渠道向渠道侧发起支付请求。其中支付单与渠道单的关系是1:N，主要是由于可能会因为各种各样的原因导致特定的渠道支付失败，而在这样的只有在明确失败的情况下情况下呢，需要换单支付，只要有一个渠道单支付成功，就可以视为当前的支付单是成功的。此处注意如果上一个渠道单在未明确失败的情况下不要重新发起支付，否则可能会重复支付。
   
3. 对账服务主要是在每个交易日结束后，渠道方会把资金对账文件上传到FTP服务器，同时支付系统也会生成对账文件并上传至FTP。最终有对账平台触发资金流比对。大概流程如图：
   
   以上是个人理解的支付系统总体上的概览，将会在后面的文章中针对各个部分详细进行说明。