图解支付系统设计（附电子书）

大家好，我是爱画图的刚哥！

前面写了央行清算、三方清算以及数币体系，从这篇开始我们写点落地的东西，就是如何设计一套支付系统。我会继续用图解的方式从支付的第一性原理出发，系统的给你串联支付的全流程，最终告诉你支付系统设计的十套模型。

当然，本文主要做框架性的知识梳理，详细设计的小伙伴可以通过以下方式获取试看版的电子书。

01 支付第一性原理

在进行支付设计之前，我们先要了解支付的第一性原理是什么，这样你才不会被纷繁复杂的场景所绕晕，从本质上建立起自己的知识框架。所以我还是要在开头多啰嗦几句。

1.1、支付第一性原理

支付的第一性原理就是“货和币的收支与交付”，这个过程分为“交易、清算、结算”三个步骤。因此人们习惯的把他称为“信息流、账务流和资金流”，只有这三个流程完成闭环，这笔交易才算完成。

1.2、支付的三流合一

我们每天用的支付钱包，其实里面存放的并不是真实的“钱”，而只是电子记账信息。

要把我们银行卡上的钱转到钱包，就需要类似支付宝、微信这样的持牌机构去银行开备付金账户。

当用户支付的时候，通过联机“交易链路”来驱动你的发卡银行和钱包账户间进行收付记账。不过，当天你在钱包上看到的钱只是一笔待结算的“账务信息”，真实的资金还在你的开户银行的过渡户当中。

所以日终，需要银行把钱清算到支付机构的备付金账户，通过“结算链路”把资金和电子记账信息进行核对后你的钱才到账，此时你就可以提现了。

三流合一，耦合链路

02 耦合链路，支付架构

要实现线上的支付，支付系统需要设计成耦合架构，通过“清算账务”将“联机交易信息”与“日终结算资金”串联起来，最终在资金到账后，由清结算和账务系统配合完成信息和资金的最终一致。

而我要介绍的这套设计正是基于这样的核心逻辑打造的一套价值数百万的真实支付系统。

2.1、系统业务架构

整个支付系统按领域划分可以简化为“五横一竖”，其中最重要的是交易与核心的八个模块，支付系统对外展现出来的特性都是由这八个模块决定的。

支付系统业务架构

从支付系统核心流程可以看到“联机交易”和“资金结算”的两条链路，而“账务系统居中”实时记录联机账务，日终结算系统对账后，配合清结算系统完成渠道和客户资金的结算，最终通过总账核算来确保信息和资金的账务平衡。

支付系统核心流程

下面我们来详细看下两条链路是如何协调工作的。

2.2、联机联机链路（信息流）

联机交易通过订单信息实现跨行支付和账务处理。它从前端接收支付请求，生成交易订单，并通过支付引擎完成跨行支付及账务登记。最终，交易结果会通知消费者和商家，并展示账单。

联机交易链路

2.3、资金结算链路（资金流）

日终资金到账后，经过对账和差错处理确保账目准确，通过渠道清算确认资金到账，然后在客资结算阶段，核销客户在途资金为可用余额，这样客户就能D1提现了。

为了结算灵活，渠道清算和客资结算可以解耦并独立运行。在异常订单不结算的情况下，日终通过总账平衡检查确保账实相符。

资金结算链路

整体信息和资金流程清楚了，下面我们来分模块拆解下各个子系统如何实现的。

03 四段交互，支付收银

收银台是收单能力的可视化包装，随着微信、支付宝的普及，收银台的交互方式也趋于统一，总结下来分为“下单、跳转支付、结果回调通知、返回商家页结果”这四个步骤。

3.1、业务架构

收银台四段式交互

在系统实现层面，收银台接收来自不同终端和网关的请求，将支付能力通过收银台页面展示给用户。其后台整合了会员、商家、交易、账户等综合能力以支付方式的形式供用户选择。

收银台的用例模型（核心流程）

3.2、最佳实践

收银台的核心指标是转化率，关键在于提供流畅的用户体验。为此，通常会设计“聚合收银台”来集成多种支付方式，并通过统一界面屏蔽不同支付方式的差异，将最简洁的操作呈现给用户，帮助他们快速完成支付。

聚合收银台服务能力

04 四句口诀，支付交易

用户提交订单后，交易系统负责按约定流程处理买卖双方的订单。作为联机交易链路中的核心服务，交易系统将底层支付资源整合为各类支付产品，供上游商家使用。我们常见的充值、提现、收单、退款、付款等功能，均由交易系统提供支持。

4.1、业务架构

交易系统接收前端订单请求后调用相应子服务。各子服务按流程完成订单拆分、配置读取、手续费计算、风控处理等操作，再通过支付引擎完成支付与记账，最终将结果通知买卖双方。

交易系统的集成关系

交易系统根据不同的场景可以拆分成“收单交易、余额、付款”等子服务，服务之间解耦可以支持不同交易场景扩展。

交易系统内部服务划分

交易系统虽然采用多服务的方式进行扩展，但是依然遵守着统一的订单模型，对整个支付过程进行全流程的记录和跟踪，确保每一笔交易都被安全有效的执行。

订单领域模型

4.2、最佳实践

交易系统的复杂性主要来源于其业务规则的逻辑。我们将其简化为四句口诀，掌握了这些基本原则后，就能应对各种场景。

05 三级路由，支付渠道

支付渠道又称为资金渠道，它最为人津津乐道的就是渠道路由能力，它可以动态的为用户选择最快、最便宜的通道完成支付。

路由因子与系统匹配关系

渠道路由通过一套可配置化的路由参数组成，这些参数在系统架构层面分别对应支付渠道的几个子系统；

1）基础因子：对应一条渠道的基础信息，也是资金渠道最核心的标准参数；

2）特征因子：对应渠道特性数据，它是每条渠道的个性化信息参数。

3）质量因子：对应渠道网关，它是每条渠道运行质量，通过质量因子可以减少渠道异常对于平台交易的影响；

5.1、业务架构

从业务架构层面上看分为三层，并且部署在不同的网段；

1）渠道管理：部署在内部网络，它是负责管理和配置“路由服务、资金渠道、基础服务”等，这一层的应用都是将标准化的服务能力提供给上游系统调用，以屏蔽底层渠道差异；

2）渠道网关：部署在隔离网段，负责外部渠道的适配，将不同渠道的支付方式标准化，以便上层服务可以直接调用。

3）外部渠道：这一层已经是外部网络了，按照接入的支付产品进行网络的通讯、安全等方面的部署和配置；

支付渠道架构

支付渠道的集成实现了“服务、路由、渠道、网关”的逐级解耦，大家都比较关注路由，其实这里最核心的还是“渠道管理”，因为只有资金渠道路由参数丰富、配置合理、接口转换清晰，才能有灵活的路由和渠道接口适配与组装。

支付渠道集成关系

5.2、最佳实践 5.2.1、渠道三级路由串联

渠道通过三级路由策略选择支付通道：首先根据支付基本信息筛选出一批通道，然后依据各通道的个性化特点进一步筛选，最后从筛选结果中根据通道质量选出最快的渠道完成支付。

渠道三级路由逻辑串联

5.2.2、渠道路由局限性

支付渠道主要适合API形式银行卡产品；对于微信、支付宝（简称AT）这类有多种终端类型，甚至需要sdk和终端秘钥验证的支付产品，其实并不适合路由，因为自动切换随时可能被AT风控，一般是通过控制收银台支付方式展现来进行切换。

06 三户模型，客户系统

客户系统负责对客户全生命周期的管理，所谓的三户就是“客户、用户、账户”的简称，其目的是实现“身份认证、产品使用、交易权限”的灵活管理。

三户模型

1）客户：是个人或者企业在社会中的唯一标识，例如个人只有一个身份证，企业只有一个营业执照；

2）用户：是产品使用者的身份，其会根据使用的产品不同有多重身份，例如多个手机号可以注册多个用户，一个企业有多个操作员等；

3）账户：用来存放用户的资金或资产，它也是交易的载体。

4）特殊用户：商户是一个特殊的用户，可以把它理解成一个用户角色或者标签。

6.1、业务架构

在客户系统中，会员就是用户。从系统架构上可以看到所有的用户服务都是围绕会员模块展开的，包括“登录、注册、签约、开户、交易、结算、注销”等用户全生命周期的管理。

客户系统集成关系

客户系统以会员账号为核心，允许用户使用多个账号注册和登录。实名认证时，系统会将这些账号与唯一的客户身份（区分个人或企业）关联起来。经过申请和认证的会员可以签约多种支付产品，并开通相应的账户进行交易。

客户领域模型

6.2、最佳实践

俗话说“三分支付，七分进件”，由此可见，在开展一个支付业务前要做大量的客户准入与审核工作。客户系统的复杂度在于商户准入阶段通过收集进件资料对客户进行KYC和KYB的审核。这就需要端到端的全流程管理，以及会员模型的灵活组合能力。

6.2.1、端到端用户服务

一个支付产品的客户来源很多，参与角色的协作关系也较为复杂。因此要对参与的角色按不同的“端”来进行划分，进行全生命周期的管理，确保客户全流程的自动化、无卡点。

端到端用户服务流程

6.2.2、灵活的模型组合

支付业务中有复杂协作关系，包括会员、商户、平台商、子商户、服务商、代理商等多种模式，这些都是通过客户的领域模型来完成各种灵活的组合。

三户模型灵活组合

07 一户多卡，钱包账户

每个互联网公司的老板都梦想拥有类似“支付宝”一样的商业生态，它通过为大量用户提供支付功能来构建支付、融资和投资的闭环生态系统。虽然从零开始打造一个支付宝非常困难，但利用银行现有的金融产品，创建一个聚合钱包还是可行的。

7.1、业务架构

钱包是会员、支付与金融服务能力的一个可视化包装，一款好用能营销、能赚钱的红包需要一套多角色的商户体系，并且底层提供不同业务之间过渡科目来实现资金的清算。

钱包支付架构

钱包应用基础能力主要由会员、交易服务提供，通过基础服务能力嵌入各种生活、信贷、理财等服务场景。

钱包集成架构

钱包应用并不是一个简单的系统能力的集成，他更加注重C端的用户体验。从注册登录每一个环节都要紧密衔接，并且需要数据埋点、用户画像和标签体系来分析用户的转化率。

钱包应用服务旅程

7.2、最佳实践

回到做一个“支付宝”的问题，与支付宝自建整个电商+支付+金融的生态体系不同，普通商户主要目的在营销，因此只要基于自身的业务场景构建一套账户体系即可，金融生态服务可以通过外部资源来进行集成。

7.2.1、一户多卡模式

所谓的一户就是面向客户的一套账户体系，所谓多卡是就是外部商户或机构提供的账户服务。一户构建平台C端用户的核心能力，外部各类金融账户采用绑卡的方式与账户进行集成。

整个模式难点就是“账户”与“卡”之间资金清算，这需要结合具体的活动由持牌机构来提供不同商家的清算服务。

一户多卡账户模式

7.2.2、个性化账户能力

会员服务提供的是基本的账户功能，这些功能与底层账户系统相映射。因此，钱包需要根据具体使用场景，对不同账户间的余额进行适当的整合和展示。

个性化钱包能力包装

08 内外双驱，支付引擎 8.1、支付核心

支付核心通过中间清算账务科目实现“信息流”和“资金流”之间的自动转换，其中支付引擎负责联机交易的调度，资金系统负责资金的对账和清结算，而账务系统记录完整的账务信息，最终实现钱账一致。

支付核心的学习还是有一些门槛的，首先你就要有基本的会计知识，这个可以下载我的电子书看下有个基本了解。

支付核心系统架构

8.2、支付引擎

支付引擎的作用就是提供联机交易的调度，通过支付订单调用不同原子支付接口，并且匹配到提前编排好的服务流程，驱动内场的账务系统完成记账，外场的支付渠道进行跨行支付。支付结果会原路返回同步通知上游系统更新结果，并通知交易参与方。

支付引擎集成架构

支付引擎的核心是支付指令，它基于支付订单生成。支付指令将“结算协议”转化为“外部渠道支付指令”，将“清算规则”转化为“内部记账分录”，从而驱动渠道和账务系统完成支付与记账。

支付引擎领域模型

8.3、最佳实践 8.3.1、参数化服务路由

支付引擎向上层交易系统提供多种原子化支付接口。为了灵活管理这些接口，我们使用参数化的策略模板来解析订单信息，并根据模板将请求发送到相应的服务入口，从而完成支付调度。

支付引擎服务路由

8.3.2、步点化流程编排

支付引擎一般都是采用步点化的组合来实现支付处理流程，流程可以按模版自定义，步点可以组件化扩展和复用。指令的组装和状态的控制全部实现标准化参数。这样就能确保支付引擎高效，稳定的运行。

09 清算结算，清结算系统

清结算系统又称为“资金系统”他负责日终核算账务，给客户结算资金。资金系统的复杂性在于你要有相应的账务基础，

9.1、业务架构

支付引擎完成了联机交易和账务处理的登记，清结算系统就是将结算资金与交易订单进行核对完成客户资金的结算。

清结算系统架构

清结算的核心流程涉及“对账（汇总和明细）、差错调账、渠道清算、客资结算”几个步骤，最终通过“总账平衡”来完成账务的核算。

清结算系统核心流程

9.2、最佳实践 9.2.1、对账三张表

设计一个对账系统主要是三张表就能建立起整个支付系统的核心规则；

对账三账表

1）对账要素表（必选）：抽取标准对账要素和主键进行对账，不同渠道的差异特性都要解析为标准对账要素进行核对。

2）差错策略表（必选）：按照“渠道、交易类型、本方结果、对方结果”的维度指定不同差错情况下的调账策略，这样可以提高自动化程度，减少人工介入。

3）账务核算表（可选）：根据对账结果核对账务明细和总账明细，确保试算平衡。这类表格主要用于收集结算人员的报表需求，并非设计时的必要条件。

9.2.2、清算结算解耦

为了实现清算与结算的解耦来提高客户资金结算的灵活性，因此渠道侧的清算和客户一侧的结算可以单独处理。通过差错调账和总账平衡来确保资金结算准确。

1）差错调账：明细部分，客户的资金可以根据D1/D0/Dn的结算周期优先结算成功订单，而异常订单则在差错调账完成后进行结算。

2）总账平衡：总账部分，日终时，在完成清结算后，可以核对渠道清算和客户结算的资金是否一致，确保总金额匹配且无遗漏。

清结算解耦

10 钱账一致，账务核心

账务核心负责平台内信息和资金流转的所有账务处理，也是一家持牌机构最重要的业务系统，所有子系统都要以他的账务结果为准，因此被称为“账务核心”。

10.1、业务架构

账务核心从系统架构层面看主要分为账务系统和会计系统，由于账务处理有事务一致性要求，因此为了提高性能，两个子系统之间通过MQ异步通讯来实现解耦。

1）账务系统：实时处理账务请求和账户资金的变动；

2）会计系统：异步处理账务信息确保事务一致性；

账务系统业务架构

10.1.2、核心流程

账务系统核心流程

账务系统的核心流程主要分为日间和日终两部分；

1、日间联机账务：

实时处理联机账务信息的记录，包括账户余额变更与复式记账；

• 同步资金变动：根据账务请求生成记账凭证，同步更新付款方客户账户余额；

• 异步复式记账：为了提升性能，它采用异步方式调用会计系统来复式记账和更新内部账户，并异步更新收款方的账户余额。

2、日终总账核算：

日终资金系统渠道清算和客户结算完成后，总账系统进行汇总核算确保当日资金处理无遗漏。

10.1.3、科目结构

直接上账务领域模型过于抽象，这里介绍下账务系统科目结构。

1）科目编号：科目依据财政部的标准进行扩展，形成一个科目树结构。其中，根节点代表总账科目，叶子节点是明细科目，而分支节点则用于分类，没有实体。

2）总账科目：相当于账务树的根节点，在系统实现上是一张汇总表，它是由末级科目的明细汇总而成。

3）明细科目：相当于账务树的叶节点，系统通过明细账簿和分户余额表来实现功能。其中，明细账簿记录详细的账务信息，而分户余额表（即客户账户）则记录余额的资金变化。

账务科目编码

科目与系统实现关系可以按照客户账户、内部账户视角来看。

1）客户账户：

• 自动生成账户

  ：客户账户是在会员开通后自动生成的，因此他是按照客户模版来生成。

• 分户记录资金

  ：按照模版会开通记录在途资金的结算户和记录余额的基本户。每个账户根据科目的余额方向生成对应的“可用与冻结”分户来记录资金变动；

• 账簿记录明细

  ：底层有对应的明细账簿来记录账务信息。

2）内部账户：

• 内部预先设置

  ：内部账户由结算人员根据业务提前设置，他是用来记录账务过渡信息。

• 账簿记录明细

  ：内部账户有对应的明细账簿用来记录账务信息。

系统与科目映射关系

10.1.4、核心账务流程

账务的核心流程包括了联机、清算、结转三部分；

1）联机交易：是按照收单、退款、付款、来账四个维度来设计整个账务体系；客资结算可以按照联机成功的订单进行处理。

2）渠道清算：日终每条渠道对账后会轧差计算发生金额；

3）银存结转：按照每条渠道的清算发生额与银存账户进行结转，银存账户与银行一侧结算户（或备付金户）期末完成平账。

核心账务流程

10.2、最佳实践

作为支付业务的“皇冠”，账务系统知识点满满，这里挑两个最常见的性能优化问题给大家介绍下；

10.2.1、缓冲记账一致性

缓冲记账是一种解决过渡户瓶颈的方法，它通过实时扣除付款方的资金余额，并以异步批量的方式进行账务处理。为确保交易的完整性，因此在缓存记账前，会生成一个事物号，通过事物号来保障记账顺序的顺序执行。

缓冲批量记账

10.2.2、热点账户拆分

支付交易中存在大量过渡户，这在高并发场景下成为瓶颈。同构缓冲记账只是短期内解决问题，但长期来看，需要将过渡户分散到各个客户下以分散热点，并对相关联机记账科目进行改造。

热点账户拆分

讲在最后

最后我们总结下吧，其实整个支付系统记住下面这张图就行了，通过“交易、清算、结算”我们梳理出来了“联机”和“结算”的两条链路，通过账务系统负责联机账务登记，最终通过结算流程完成“信息与资金”的最终一致。

剩下来的就是按照这张图对每个模块进行大量实践和积累。

按这张图死磕每一个模块

【加我微信入群与更多的支付老法师交流】