0 前言
金融业务都很复杂。我们有可能复用第三方支付既有经验，解决其他金融业务问题吗？
和解数学应用题一样，应对第三方支付这类复杂业务：
- 先分析它里面的核心原理
- 再尝试通过核心原理推算出可能规律。这些规律就决定系统架构的演进规律
掌握这些分析问题的方法，碰到其他金融业务问题时就能游刃有余。
先搞懂支付涉及核心金融原理，按架构由简到难，逐步学习点券系统、支付系统和第三方支付公司的支付系统。就能理解支付系统咋遵循核心金融原理，一步步从简单组件发展到完善系统架构。
1 分离的信息流与资金流
架构设计要确保架构原理和业务原理一致。
业务原理，支付业务中最核心概念是信息流与资金流分离：
- 信息流，想象中钱的流转过程
- 资金流，钱的实际流转过程
1.1 案例
假设你（用户 A）和你朋友（用户 B）做生意。你银行账户有1块钱。白天你给朋友转1块钱。但你并没把钱实际转你朋友，而是给朋友一张字条，记下你转给你朋友一块钱。同样的，你朋友过一会儿也通过字条转给你一块钱。在白天你们俩就这么来回转来转去。
到晚上，你和你朋友对白天所有交易，发现你共转给朋友 51 元，而朋友共需转50元。
显然你俩这 50 元可互相抵消。抵消后，你只需给你朋友转1块钱。于是你通过银行将这一块钱转给朋友。
1.2 过程示意图
1.3 分析
你账上1块钱在白天一直没动，这是真实资金，你在白天一直都有这1块钱所有权。
但白天你和朋友通过纸条将这1块钱转来转去，其实转移的是这1块钱的使用权。这种资金使用权的转移过程就是信息流。
只有晚上你俩对完账，并通过银行转完账，这1块钱所有权才真正属你朋友。这种资金所有权的转移过程就是资金流。
本例中用字条转账过程就是清算中心每天做的事，最后通过银行转账的过程就是央行在做的事情。
原理只是说信息流和资金流可分离，通常这两者也是处在分离态。但它俩不一定需要分离，如实时清算概念，可实时保证信息流和资金流一致。
现代支付系统普遍采用信息流和资金流分离，系统架构角度分析会发现：
- 实时清结算对软件系统吞吐量和延时要求很高
- 同时要求所有参与的支付公司都具有实时清结算能力，任何一家达不到都不行
这就得整个国内和国际金融系统都重新设计系统底层的核心架构。这技术投资并无相应规模的经济收益支撑，可能也就量化交易能做得起了。
所以，目前支付系统架构设计假设这两者分离。
1.4 架构设计影响
① 非银行参与者只产生信息流
支付环节的非银行参与者只产生信息流，不能产生资金流。因大多金融机构并没有物理现金，纸钞都放在银行。
虽信息流和资金流分开，但它俩最终还是需要同步。同步过程需再次和银行系统对接，即支付系统需要通过网关的形式与外部支付系统进行状态同步。
② 不同主体分开流转
资金流和信息流分开后，这两者将以不同速度在不同时间的不同主体分开流转
即支付系统本质是异步处理系统，资金流和信息流的统一具有最终一致性（Eventual Consistency）。所以，扫码支付状态拉取时，银行对接是异步消息处理的。
③ 资金流和信息流最终需要同步
即需要一个核算系统来确认同步过程准确无误。
至此，支付系统架构的核心原理就是内部信息流系统与外部资金流系统的异步交互。
咋把原理转成技术架构？
2 点券系统
点券系统里，资金流和信息流是一致的。金融业务最简单的情况，也是所有相关架构基础。
点券系统，管理点券的系统。假设只有代金券这一种点券，而且你只能使用代金券来购买产品。
2.1 购买流程
业务系统发起一笔交易单：用户A用 10 元代金券从用户 B 购买一支笔。
交易单接着会变成支付单。支付单只记录用户账号的变动关系，不包含物品交换的关系。即：
- 交易单包括财产交换和物品交换两种信息
- 支付订单只包含财产交换的信息
该支付单发给支付系统。支付系统收到后，要对用户 A 及用户 B 的代金券账号处理。
假设最开始用户 A 持 100 元代金券，用户 B 持 10 元代金券。购买后，用户 A 的代金券账号需减少 10 元代金券，同时用户 B 的代金券账号需增加 10 元代金券。
可见，支付过程至少需 3 个系统：
- 业务系统，生成交易单和支付单
- 支付网关，负责处理支付单
- 账务系统，负责维护用户账户情况
2.2 系统架构图
点券支付：
查询系统：用代金券支付完成后，用户可能需要检查自己的代金券余额，以及与代金券相关的账单。
产品体验角度的不足：用户 B 不知道自己账户收到点券。这时及时通知用户 B 可能是更合适的产品设计。这时还需一个账户变动的通知系统。
假设所有和用户相关的系统都在业务系统内。更新之后的架构图：
账务系统、查询系统及消息系统处理的都是用户的点券数据。数据传输除了上图基于服务的实现，还可直接通过数据库，即基于数据库的：
3 电商的支付系统
3.1 背景
现实绝大多数支付业务场景是资金流和信息流不一致。所以重点是啥样架构系统，能处理好信息流与资金流不一致。
电商公司一般无第三方支付牌照，需通过支付系统对接第三方支付公司。我们以支付系统中通过第三方支付完成的银行卡支付业务为例。
用户 A 用 10 元钱从用户 B 那里购买一支笔。但这次用户 A 用银行卡付款，而非点券。
3.2 业务分析
银行卡是属于用户所有的资产，电商公司无权处理。所以银行卡这资产只能通过第三方支付公司进行操作（其实是通过第三方公司背后的银行及卡组织）。
第三方公司提供 API 接口都是异步。异步接口除成功、失败态，还有不确定状态，即点券系统到支付系统的架构演进其实是从同步系统到异步系统的演进。
按业务流程逐步分析，看基础的 4 个系统之上，还缺啥功能，要增加啥组件。
业务系统发起一笔支付订单给支付网关：用户 A 将银行卡上的 10 元转给用户 B。不同在于，支付网关收到这笔支付订单后，需判断支付系统能否独立完成资产转移：
- 点券这种内部资产可内部解决
- 但银行卡属用户，是外部资产，支付系统不能自主解决
所以支付网关要实现路由能力，将内部资产和外部资产两种操作，分发给不同资产处理组件。因此，新增内部、外部资产管理系统组件：
外部资产管理系统需对接第三方支付公司来完成银行卡转账业务。这个对接任务通过金融网关来实现。金融网关主要是实现二进制协议的对接，如证书签名、加解密、协议传输、数据校验等。
金融网关会对接多家第三方支付公司或银：
- 当一家支付公司临时连接不上，可切换到下一家
- 或当一家支付公司费率相对较优时，可临时切换
选择哪家支付公司对接的过程也叫路由，通过当前情况智能选择路由的过程叫智能路由。因此，架构图新增金融网关服务：
金融网关和第三方支付公司之间是异步通讯协议。异步通讯有额外的不确定状态，架构上咋处理？不确定状态处理方法分两步：
- 规定时间内重复查询支付状态，一般把这种行为叫作轮询。如用户 App 通过轮询来获取支付状态
- 规定时间内轮询若失败，支付过程并不一定失败，有补救机会。每天晚上电商公司会有一个与第三方机构进行对账机会，在这时双方会对白天所有交互明细进行对比，查漏补缺
这就是异步系统对接时的架构设计原则，需将同步系统的一次调用拆分成三个步骤：异步调用、轮询和对账。
- 电商支付系统的外部资产管理系统处理的是信息流
- 金融网关对接的第三方支付公司处理的是资金流
信息流和资金流分离后，两者状态就不再一致。
所以从信息流系统角度，资金流系统会存在不确定状态，这就是为啥除了成功和失败，会出现第三种状态。信息流和资金流虽分开，最终还是需要同步，因此要通过轮询、对账两种方式实现同步。
这就是由支付业务原理所推导出的系统架构设计原理。
最后还要把剩下的一些关键组件补充完整。发现架构图无法保存信息流相关信息，所以也无法处理和资金流的同步。
信息流是通过记账保存，因此要加回账务系统。这账务系统和点券系统的账务系统功能类似，但覆盖面不同。
3.3 更新后架构图
如轮询失败，需在晚上与第三方支付公司对账。对账任务一般由核算系统完成。除了和第三方公司进行对账，核算系统还要核对账务系统与业务系统之间的一致性关系。
添加核算系统的架构图：
至此，基本满足电商公司日常支付需求。
4 第三方支付系统
第三方支付系统和电商公司的支付系统的核心组件都差不多，主要因为它俩都不能管理实际资金，因此都是信息流的处理系统。
电商公司通过支付系统，将信息流交给第三方支付系统处理。第三方支付系统会将这信息流再转交给银行处理。在做跨境交易的时候我们甚至还能看到不同国家第三方支付公司之间的彼此合作。
相同地方不复述，这重点讲三点不同：流量支持、资金池和清算系统。
4.1 系统的流量支持
第三方支付公司有很多家客户，可能面临非常大的支付流量，如：
- 第三方支付公司负责代发工资或代缴水电费，一到月底就面临大流量
- 除了可预测的高流量，第三方支付公司还面临电商大促这种突然高支付流量
所以第三方支付公司要有能力处理这种常见的互联网应用高并发问题。这就是金融系统架构和互联网架构结合好的地方。应对高并发场景，互联网有成熟解决方案。如异步消息处理，就能削峰填谷，降低峰值流量压力。
如流量再高，还可选择熔断降流等手段进行服务降级。如存储能力支撑不了这么高流量，还可用各种不同缓存技术降低查询操作对数据库的压力或分库分表进一步降低每个数据库的压力。
4.2 备付金资金池
第三方支付公司在调用银行接口的时候会产生费用。咋利用备付金资金池：
- 减少交易费用
- 同时提高用户体验
资金池，一种常见的用户资金管理手段，将属于用户的钱都放在一个大池子。池子里的钱不分你我，你是将资金池看作一个整体来操作。但你还留个账本，上面记载每个人原来在资金池里放多少钱。这样虽然钱混在一起，但账面上清楚。
资金池有很大的资金挪用风险，因此金融业对资金池设立有严格监管。有支付牌照，第三方公司才可建立用户的备付金资金池，一种新的金融产品，因此也需要新的系统组件支持。
例
第三方支付公司 App 时常见的余额或钱包。你可将银行卡里的钱转到余额账户。之后就可直接使用余额里的钱。但第三方支付公司并不一定会将你和我的余额分开存储，很可能放在一个资金池。
如下图展示一种资金池管理方式。ABCD 四个用户在第三方支付公司都有自己的余额账户。但是这 4 个余额账户并不是实际存在的，只是 4 个虚拟账户而已。真正的钱其实还是存在第三方支付公司在银行的账号里。
第二个例子是第一个例子的升级版。外汇市场是一个个有层级的市场。资金池也一样，多个资金池也可拼成一个更大资金池。于是第三方支付公司可在多家银行开设很多资金池账户，所有这些资金池账户的钱形成更大的资金池（监管机构正在逐步限制这种行为）。
当把资金池分散在多家银行之后，第三方支付公司就不再受制于单独某家银行。这样就可以利用不同银行的费率情况来进一步降低运营成本。
如跨行转账需要多家银行之间配合，还可能需要支付一定的跨行交易费用。但是如果第三方支付公司在每家银行都有资金池，就可以直接在两家银行内部完成用户资金和资金池资金之间的操作了。
利用资金池来优化跨行转账的例子也有升级版。在进行跨境贸易的时候也可以使用多个资金池来降低交易成本，但这不是主要原因。跨境转账一个不太友好的问题是时间非常久，需要好几天才能到账。这时候如果你在每家银行都有资金池账号，跨境转账问题就变成多个银行内部转账的问题了，这样就能实时到账，大幅提升用户体验。
备付金资金池要求账务系统有层级式的账户体系，并且有相应的账户和资金操作。升级版的资金池看起来是下图这个样子：
4.3 清结算能力
清结算中心处理的是多家银行之间的跨行转账。当第三方支付公司有了多个资金池之后，这些资金池之间的转账关系其实和跨行转账一样。既然是一样的，那么第三方支付公司有没有可能做一些清算公司的事情，从而进一步降低交易成本呢？
的确如此。所以成熟的第三方支付公司内部都会有一个自己的清算中心。这个清算中心把自己当作一个外人，对资金池之间的转账交易进行清结算工作。这里要注意清算中心的结算过程涉及到资金流操作，需要通过内部支付网关来操作外部资金。
这样我们就把第三方支付公司最后一个组件补完了。现在架构图：
跨银行备付金和清算中心合在一起后，第三方支付机构就具备了跨行清算的能力。由于这种业务模式不容易监管，容易出现洗钱等非法行为，国家已经逐步取消了这种资金管理模式。
但是清算中心这个组件还是保留了下来。尽管不能再进行跨行清算，不过有了清算中心之后就有了清算的概念，这让一些常见的内部信息流和资金流处理的方式变得更加清晰。
该例表明，由于监管条例完善，支付业务和系统架构也要改变。如你在欧洲从事第三方支付业务，很可能会碰到欧盟制定的“通用数据保护条例”，要求你对系统架构的信息存储做进一步划分。因此设计支付系统要根据当地监管条例合理选择架构。
5 总结
本文梳理支付业务逻辑，最终推导出 C 端支付核心组件。
C 端支付需解决**核心问题是信息流与资金流分离。**先分析最简单点券系统，这种系统信息流与资金流不分离。点券系统需要账务系统来对点券这种资产进行管理，用户需要通过支付网关来对接点券系统。
资金流与信息流分离的系统又是啥样？电商的支付系统就很有启发性。点券系统需要处理的同步消息，支付系统则需要处理异步消息。所以支付系统除了需要复用点券系统的核心组件外，还需要核算系统来保证异步消息的正确处理。
有前面基础，再分析第三方支付系统的核心组件就容易。第三方支付在业务上需要用资金池来降低业务成本，因此在架构上需要有核心组件来对资金池进行操作，同时也需要用清算中心来简化资金池操作的优化管理。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：
随时随地看视频
