支付系统概述（二）：渠道网络

构建一个支付系统，如果不仅仅只支持余额支付的话，都避免不了和渠道打交道。即使只支持余额支付，余额也需要充值，不可能单靠发行虚拟货币吧 ^_^ 所以，构建一个支付系统，首先需要搭建的系统往往就是渠道网络系统。

渠道网络系统最重要的职责就是支撑支付过程所需的渠道交互，保证渠道信息交互的准确、安全和可靠。在业务架构上，我们一般将支付所需的渠道分为如下类型：

• 支付渠道：包括卡组、支付机构（PSP）、钱包等。

• 资金渠道：主要是指各类的银行，以及银行间报文交换的网络 SWIFT。

• 外汇渠道：主要是各大银行，协议有银行特定的协议和 FIX。

• 信息渠道：包括进行 KYC 的政府机构，发送短信用的运营商等。

一般来说，支付系统用到的主要是信息渠道和支付渠道，大一点的支付系统如果需要自建外汇需要用到外汇渠道。有了自建外汇就必然涉及流动性管理，这个时候相应的会有接入资金渠道的诉求。

在应用架构上，渠道网络在整个支付系统中承担的是一个承上启下的职责：对上对接支付或者资金类的业务系统，接受发的订单指令；对下对接渠道机构，进行渠道指令的交互。订单指令和渠道指令之间，往往存在一个一对多的关系：

• 异步交互：很多渠道协议，特别是像 SWIFT 和 FIX，往往都是一个异步的协议，请求之后渠道没有实时的应答或者只是一个已受理的应答，后续通过通知消息给到准确的结果。

• 附带认证的交互：部分渠道，在实际进行业务报文交换前，需要有一个认证的过程。

• 组合交互：部分特殊的渠道，需要用多个指令完成一项业务需求。例如部分渠道会给我们开两个账户，支付的时候需要将资金从 A 账户划转到 B 账户，然后再下发指令才能完成一次成功的支付。

同时，渠道的交互大致上可以分为 API 交互和晚间交互两类。对于文件交互，还有一个将渠道指令打包成文件发送的过程。

所以，在渠道网络的应用模型设计，会有两类的模型：

1. 组合单和原子单模型：组合单对于内部的订单指令，原子单对应和渠道的交互。一类的支付指令，对于不同的渠道，可能需要拆分成不同的原子单。这个配置就是渠道网络核心的渠道配置模型，相应的实例就是渠道交互的实例。对于卡支付、SWIFT 网络、FIX 外汇机构这类有标准的，我们可以定义一类通用的渠道配置模版；对于不同的机构，将模版中的原子单配置映射到渠道 API 即可。对于特殊的渠道，就需要 case by case 单渠道接入了。这里遵循两个二八原则：接入 20%的渠道基本上就可以完成 80%的支付覆盖，其中 80%的渠道又是上述可以抽象成模式的渠道。

2. 批处理单模型：对于文件类打批的渠道，需要记录文件批次和原子单之间的关系。后续进行交互的时候可以进行核对和跟踪。

同时，由于渠道网路的特殊地位，也是资金风险的高发区。在设计渠道网络的过程中，需要严格设计好幂等逻辑和核对规则。在接入渠道的过程中，需要反复确认幂等和重试逻辑：

• 非终态不要换单重发。

• 机构不支持幂等重试就先查询到终态再重试。

• 实在无法明确结果就依靠人工介入。

• 设计逻辑的过程中充分考虑掉单、重发、乱序的可能性。并有相应的测试能力保障。

由于渠道网络负责和外部机构的交互，所以在渠道网络的建设上，技术架构（部署架构）会有较大的挑战。

首先，我们要考虑到机构的不可靠性，建设隔离和保护的机制。

在隔离上，包括内外隔离和渠道间隔离：

• 内外隔离：不能让渠道交互影响到我们内部的系统交互。所以，有渠道交互的功能，我们一般会做成异步的方式。即使前端需要同步交互，也会做成前端轮询这种异步转同步的方式。对于文件类的渠道，打批功能和文件交换功能会分开。具体说，就是将打批的结果生成一个内部的暂存文件，不管是用 OSS 还是 NFS。然后文件搬运功能再将这个临时文件搬运到机构需要的 SFTP 或者其他存储上。

• 渠道间隔离：每个渠道应该有逻辑上隔离的计算和网络环境。对于一些特殊的渠道，比如 SWIFT 和一些银行，需要专门的前置机或者专线支持，这天然就保证了隔离性。对于通过公网对接的渠道，也需要有一定的逻辑隔离的能力，不能因为一条渠道的问题影响到其它渠道的交互。

在保护上，需要有基本的限流和备份能力：

• 限流：国内的银行着几年被微信支付宝“教育”的系统能力已经很强了，大促几千的 TPS 不在话下，但是国外还是非常原始的，TPS 能到 100 的就算“尖子生”了。所以，我们需要充分考虑渠道的容量问题，在突发大流量下，需要有限流机制保护渠道。同时，上面的异步交互的设计，也可以很好的保证限流。

• 备份：就算做了限流，渠道被打挂或者自身问题导致不可服务的情况在国际支付的场景下，也是非常大的，对于一些通用的渠道，比如卡支付、SWIFT、FIX 等，需要有两家以上的机构做备份。出了问题可以灵活的切换。

其次，对于渠道的特殊要求，我们还是必须 follow 渠道的要求。我们内部可以有一些成本上的考虑，比如专线实在太贵那这个渠道也就不用考虑接入了。对于 PCI 等该有的认证，尽量去保障。如果实在搞不到，那就通过支付架构去对接。

再者，和外部的交互需要充分考虑安全性：

• 传输安全性：专线、VPN、HTTPS，这些都是和渠道沟通的时候需要明确的。如果一条渠道这些都没有，是否考虑一下放弃这条渠道的接入？

• 报文可靠性：需要有非对称加密或者加验签机制保证报文不会被篡改。我们在国际上是碰到一些渠道这些能力都没有的，可以考虑给渠道赋能提升他们的安全性？否则可能只能人工操作了。

最后，对于国际化的支付场景，需要在部署架构上考虑到跨洲的问题。解决跨洲问题哟两类思路：

• 网络加速：这个方案是相对简单和经济的。如果支付系统和渠道分属两个大洲或者物理上相聚较远，可以在网络层采购网络加速服务，就近接入。

• 全球部署：如果支付系统做大了，在多个国家都有收单支付业务，那可以考虑全球多机房。对于跨洲跨国的渠道接入，可以考虑内部多机房间路由，在本地出口的方式，降低网络时延。