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 更新后架构图
如轮询失败，需在晚上与第三方支付公司对账。对账任务一般由核算系统完成。除了和第三方公司进行对账，核算系统还要核对账务系统与业务系统之间的一致性关系。
添加核算系统的架构图：
至此，基本满足电商公司日常支付需求。
对账系统
对于对账，一般分为两个类型：交易对账 与 结算对账
交易对账
交易对账的核心点是：检查每一笔交易是否正确。它主要目的是看我们系统中的每一笔交易与第三方的每一笔交易是否一致。
这个检查逻辑很简单，对两份账单数据进行比较，拿到在第三方那边完成的交易数据。然后跟我方的交易成功数据进行比较。检查是否存在误差。
这个逻辑非常简单，但是有几点需要大家注意：
- 我方的数据需要正常支付数据+重复支付数据的总和；
- 对账检查不成功主要包括：金额不对、第三方没有找到对应的交易数据、我方不存在对应的交易数据。
针对这些情况都需要有对应的处理手段进行处理。在我的经验中上面的情况都有过遇到。
金额不对：主要是由于第三方的问题，可能是系统升级故障、可能是账单接口金额错误；
第三方无交易数据： 可能是拉去的账单时间维度问题（比如存在时差），这种时区问题需要自己跟第三方确认找到对应的时间差。也可能是被攻击，有人冒充第三方异步通知（说明系统校验机制又问题或者密钥泄漏了）。
自己系统无交易数据： 这种原因可能是第三方通知未发出或者未正确处理导致的。
结算对账
那么有了上面的 交易对账 为什么还需要 结算对账 呢？这个系统又是干嘛的？先来看下结算的含义。
结算，就是第三方网关在固定时间点，将T+x或其它约定时间的金额，汇款到公司账号。
下面我们假设结算周期是： T+1。结算对账主要是 每一笔结算的款项都是由哪些笔交易组成（交易成功与退款数据）。以及本次结算扣除多少手续费用。
它的逻辑其实也很简单。我们先从自己的系统按照 T+1 的结算周期，计算出对方应该汇款给我们多少金额。然后与刚刚接口获取到的数据金额比较：
银行收款金额 + 手续费 = 我方系统计算的金额
这一步检查通过后，说明金额没有问题。接下来需要检查本次结算下的每一笔订单是否一致。
结算系统是 强依赖 对账系统的。如果对账发现异常，那么结算金额肯定会出现异常。另外结算需要注意的一些问题是：
- 银行可能会自行退款给用户，因为用户可直接向自己发卡行申请退款；
- 结算也存在时区差问题；
- 结算接口中的明细交易状态与我方并不完全一致。比如：银行结算时发现某笔退款完成，但我方系统在进行比较时按照未退款完成的逻辑在处理。
针对上面的问题，大家根据自己的业务需求需要做一些方案来进行自动化处理。
4 第三方支付系统
第三方支付系统和电商公司的支付系统的核心组件都差不多，主要因为它俩都不能管理实际资金，因此都是信息流的处理系统。
电商公司通过支付系统，将信息流交给第三方支付系统处理。第三方支付系统会将这信息流再转交给银行处理。在做跨境交易的时候我们甚至还能看到不同国家第三方支付公司之间的彼此合作。
相同地方不复述，这重点讲三点不同：流量支持、资金池和清算系统。
5 总结
本文梳理支付业务逻辑，最终推导出 C 端支付核心组件。
C 端支付需解决**核心问题是信息流与资金流分离。**先分析最简单点券系统，这种系统信息流与资金流不分离。点券系统需要账务系统来对点券这种资产进行管理，用户需要通过支付网关来对接点券系统。
资金流与信息流分离的系统又是啥样？电商的支付系统就很有启发性。点券系统需要处理的同步消息，支付系统则需要处理异步消息。所以支付系统除了需要复用点券系统的核心组件外，还需要核算系统来保证异步消息的正确处理。
有前面基础，再分析第三方支付系统的核心组件就容易。第三方支付在业务上需要用资金池来降低业务成本，因此在架构上需要有核心组件来对资金池进行操作，同时也需要用清算中心来简化资金池操作的优化管理。
