0 简介

金融服务非常复杂，我们能否复用第三方支付现有的经验来解决其他金融服务的问题？

就像解决数学问题一样，处理第三方支付等复杂业务：

掌握了这些问题分析的方法，你将能够轻松地处理其他金融业务问题。

首先了解支付涉及的核心金融原理，然后按照由简到难的架构逐步学习优惠券系统、支付系统、第三方支付公司的支付系统，了解支付系统如何遵循核心金融原理，从简单的组件一步步发展到完整的系统架构。

1. 信息流与资金流分离

架构设计必须保证架构原则与业务原则一致。

商业原则：支付业务的核心理念是信息流与资金流的分离：

1.1 示例

假设你（用户 A）和你的朋友（用户 B）正在做生意。你的银行账户里有 1 美元。白天，你向朋友转了 1 美元。但你实际上并没有把钱转给你的朋友。相反，你给你的朋友一张纸条，写下你向朋友转了 1 美元。同样，你的朋友稍后也通过一张纸条向你转了 1 美元。你们两人在白天就这样来回转着。

晚上你和朋友查看白天的所有交易，发现你给朋友一共转了51元，而你的朋友一共需要转50元。

很显然，你们俩之间的50元是可以相互抵消的，抵消之后你只需要转1元给你的朋友，于是你就通过银行把这1元转给你的朋友了。

1.2 流程图

1.3 分析

你账户里的这一美元在一天内没有动过。这是真钱，你在一天内始终拥有这一美元的所有权。

但在白天，你和朋友通过纸币把这1块钱来回转账的时候，实际上你们在转移的是这1块钱的使用权，资金使用权的转移过程就是信息流。

只有当你们两个晚上对账，通过银行把钱转走后，这1元钱的所有权才真正属于你朋友，这种资金所有权的转移过程就叫资金流。

这样的话，用纸币来转移资金的过程就是清算中心每天做的事情，而最终通过银行来转移资金的过程就是央行做的事情。

原则是信息流和资金流是可以分离的，通常情况下，两者是处于分离状态的。但不一定需要分离，比如实时清算的概念，可以保证信息流和资金流实时一致。

现代支付系统一般将信息流与资金流分离，从系统架构角度可以发现：

这需要整个国内和国际金融体系重新设计系统的核心架构，这种技术投入并没有相应规模的经济效益支撑，或许也只有量化交易才能承担得起。

因此，目前的支付系统架构设计就假设了两者的分离。

1.4 架构设计影响 ①非银行参与者仅产生信息流

支付过程中非银行参与者只产生信息流，而不产生资金流，因为大多数金融机构没有实物现金，纸币都存放在银行。

虽然信息流和资金流是分开的，但最终还是需要同步的，同步的过程需要跟银行系统再打通，也就是支付系统需要通过网关的形式跟外部的支付系统同步状态。

②不同主体分开流通

资金流与信息流分离之后，二者将以不同的速度、在不同的时间分别流向不同的主体。

也就是说，支付系统本质上是一个异步处理的系统，资金流和信息流的统一具备最终一致性（）。因此，在扫码拉取支付状态的时候，银行连接是异步消息处理的。

③资金流与信息流最终需要同步

也就是说，需要一个会计系统来确认同步过程的准确性。

此时，支付系统架构的核心原则是内部信息流系统与外部资金流系统的异步交互。

如何将原理转化为技术架构？

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向用户B购买了一支笔，价格为10元。不过这次用户A用的是银行卡，而不是优惠券。

3.2 业务分析

银行卡是用户自有的资产，电商无权处理，因此银行卡只能通过第三方支付公司（实际上是通过第三方公司背后的银行和卡组织）来操作。

第三方公司提供的API接口都是异步的，异步接口除了有成功、失败状态外，还有不确定状态，也就是说从优惠券系统到支付系统的架构演进，其实就是从同步系统到异步系统的演进。

按照业务流程一步步分析，看看缺少了什么功能，在基本的4个系统之上需要添加什么组件。

业务系统向支付网关发起支付订单：用户A从银行卡转出10元给用户B。不同的是，支付网关收到支付订单后，需要判断支付系统是否能自主完成资产转移：

因此支付网关需要实现路由能力，将内外部资产操作分发到不同的资产处理组件上，因此增加了新的内外部资产管理系统组件：

外部的资产管理系统需要对接第三方支付公司完成银行卡转账业务，这个对接任务是通过金融网关来实现的，金融网关主要实现证书签名、加密解密、协议传输、数据校验等二进制协议的连接。

金融网关将对接多家第三方支付公司或银行：

选择对接哪家支付公司的过程也叫路由，而根据当前情况智能地选择路由的过程叫智能路由。因此，架构图中增加了新的金融网关服务：

金融网关与第三方支付公司之间的通信协议是异步的，异步通信多了不确定状态，架构上该如何处理呢？不确定状态的处理方法分为两步：

这是对接异步系统时的架构设计原则，对同步系统的调用需要拆分成三个步骤：异步调用、轮询、对帐。

信息流与资金流分离之后，两者的状态不再一致。

所以从信息流系统的角度来说，资金流系统会处于一个不确定的状态，这也是为什么除了成功和失败之外，还有第三种状态。虽然信息流和资金流是分开的，但是最终还是需要同步的，所以通过轮询和对账来实现同步。

这是由支付业务原则衍生出来的系统架构设计原则。

最后需要完成剩下的关键组件，我们发现架构图无法保存信息流相关的信息，所以无法处理与资金流的同步。

信息流是通过记账来保存的，所以需要重新加回到会计系统中，这个会计系统和优惠券系统的会计系统功能类似，只是覆盖范围不同。

3.3 更新架构图

如果轮询失败，晚上就需要和第三方支付公司对账，对账任务一般由账务系统完成，账务系统除了要和第三方公司对账，还需要检查账务系统和业务系统的一致性。

添加会计系统架构图：

至此，电商企业日常支付需求基本得到满足。

4 第三方支付系统

第三方支付系统与电商企业支付系统的核心组成部分比较类似，主要是两者都不能管理实际的资金，因此都是信息流处理系统。

电商通过支付系统把信息流交给第三方支付系统处理，第三方支付系统再把信息流交给银行处理，在做跨境交易的时候，我们甚至可以看到不同国家的第三方支付公司之间的合作。

相同的部分我就不再重复了，而是重点说一下三个不同点：流量支持，资金池，清算体系。

4.1 系统流量支持

第三方支付公司拥有众多客户，可能面临非常大的支付流量，例如：

所以第三方支付公司必须要能处理好这个互联网应用常见的高并发问题，这也是金融系统架构和互联网架构很好的结合之处，互联网对于高并发场景有成熟的解决方案，比如异步消息处理可以减少峰值流量压力。

如果访问量更大，可以选择通过熔断降级的方式降低服务，降低访问量。如果存储能力无法支撑这么大的访问量，也可以通过各种缓存技术，减少查询操作对数据库的压力，或者将数据库划分成不同的表，进一步减少每个数据库的压力。

4.2 储备基金池

第三方支付公司调用银行接口会产生费用，备用金池使用方式：

资金池是用户资金管理的常用方式，就是把所有属于用户的钱放到一个大池子里，池子里的钱不分你我，你负责整体运营，但你还是要留个账本，记录每个人当初往资金池里投了多少钱，这样虽然钱混在一起了，但账面上还是一清二楚的。

资金池存在很大的资金被挪用的风险，所以金融行业对资金池的设立监管很严格，第三方公司只有持有支付牌照才能建立用户备付资金池，这是一个新的金融产品，因此也需要新的系统组件支持。

例子

余额或钱包在第三方支付公司应用中很常见，你可以将银行卡里的钱转到余额账户，然后直接使用余额里的钱就可以了。但是第三方支付公司不一定把你的余额和我的余额分开存放，他们可能会把余额和我的余额放在同一个资金池里。

下图是一个资金池管理方式，四个用户ABCD在第三方支付公司都有各自的余额账户，但这四个余额账户其实并不存在，只是四个虚拟的账户，真正的钱还是在第三方支付公司的银行账户里。

第二个例子是第一个的升级版，外汇市场是一个层级化的市场，资金池也是一样，多个资金池也可以组合成一个更大的资金池，所以第三方支付公司可以在多家银行开立很多个资金池账户，这些资金池账户里的钱加起来就形成了一个更大的资金池（监管机构正在逐步限制这种行为）。

当资金池分散到多家银行后，第三方支付公司就不再受制于单一一家银行，可以充分利用不同银行的利率优势，进一步降低运营成本。

例如跨行转账需要多家银行合作，可能还需要支付一定的跨行交易费用。但如果第三方支付公司在各家银行都有资金池，那么就可以直接完成两家银行内部用户资金与资金池资金之间的操作。

使用资金池优化跨行转账的例子也升级了，在进行跨境贸易时，使用多个资金池也可以降低交易成本，但这不是主要原因。跨境转账一个不友好的问题就是耗时非常长，需要好几天才能到账。这时候如果你在各个银行都有一个资金池账户，跨境转账问题就变成了多家银行内部转账的问题，这样资金就可以实时到账，大大提升了用户体验。

备用资金池要求会计系统有层级账户体系和对应的账户、资金操作，升级版的资金池如下图所示：

4.3 清算和结算能力

清算结算中心处理的是多家银行之间的跨行转账，当第三方支付公司有多个资金池的时候，这些资金池之间的转账关系其实和跨行转账是一样的。既然是一样的，那么第三方支付公司是否可以承担一些清算公司的工作，进一步降低交易成本呢？

确实，成熟的第三方支付公司都会有自己的清算中心，这个清算中心把自己当成一个局外人，对资金池之间的转账交易进行清算结算工作。需要注意的是，清算中心的结算过程涉及到资金流操作，外部资金需要通过内部支付网关进行操作。

这样我们就完成了第三方支付公司的最后一个组件了。现在上架构图：

跨行备付金与清算中心合并后，第三方支付机构具备跨银行清算能力，由于该业务模式不易监管，容易滋生洗钱等违法犯罪行为，国家已逐步废除该基金管理模式。

但清算中心部分还是保留了下来，虽然跨行清算已经不可能了，但是清算中心的概念自带了，使得一些常见的内部信息流、资金流处理方式更加清晰。

这个例子说明，随着监管法规的完善，支付服务和系统架构也必须随之改变。如果你在欧洲从事第三方支付业务，可能会遇到欧盟制定的《通用数据保护条例》，要求你对系统架构的信息存储做进一步的划分。因此，在设计支付系统时，一定要根据当地的监管法规，合理选择架构。

5 结论

本文对支付业务逻辑进行了梳理，最终得出了C端支付的核心组件。

C端支付需要解决的核心问题是信息流与资金流的分离。我们先分析一个最简单的优惠券系统，其中信息流与资金流没有分离，优惠券系统需要一个会计系统来管理优惠券资产，用户需要通过支付网关接入优惠券系统。

资金流和信息流分离的系统是什么样的？电商的支付系统很有启发，优惠券系统需要处理同步消息，而支付系统需要处理异步消息，因此支付系统除了复用优惠券系统的核心组件外，还需要一个记账系统来保证异步消息的正确处理。

有了以上基础，我们很容易分析第三方支付系统的核心组件。第三方支付需要使用资金池来降低业务成本，所以架构上需要有核心组件来操作资金池，同时也需要一个清算中心来简化资金池运行的优化管理。