支付系统设计是金融科技领域中极具挑战性的一部分，它不仅需要处理复杂的交易流程，还要确保资金的安全和准确流动。本文作者凭借其丰富的行业经验，将支付系统设计的核心知识体系提炼为十句口诀，帮助读者快速掌握支付系统的架构与核心设计要点。

之前白话支付设计的文章推出了一套完整的三方支付系统的架构与核心设计内容。这次我把整套系统设计重新进行整理，并提炼了日常设计和面试中最高频的问题整理成最佳实践分享给大家。

01 三流合一，基础概念

做支付核心还是要掌握本质，理解清楚本质才能建立起完整的知识框架，才能沉淀下更多知识细节。所以我还是要在开头多啰嗦几句支付基础概念和核心知识逻辑。

1.1 支付三要素

我们知道支付由“交易、清算、结算”三部分组成。本文的所有所有的系统设计、账务设计都是围绕这个三个要素展开的。

1、交易：

就是记账，通过单据的信息串联起来了联机的链路，帮助用户完成支付。

2、清算：

就是算账，根据单据信息，确认交易各方能拿到多少钱，这是最后结算前的账务工作；

在国内清算这个概念是特指金融机构之前的，因此同样是Clearing面对不同的结算对象，在支付语境下有不同的定义；

1）清算：金融机构与金融机构之间的账务处理一般称为清算；例如轧差清算、净额清算等；

2）清分：金融机构与客户之间的账务处理一般称为清分；例如分账、计费等；

3、结算：

就是结账，最终把钱划转到客户的账户上，并用生成结账单完成最终的资金转移；

4、清结算：

收单业务、移动支付业务可以实现线上化的跨行资金转移，因此他包含了渠道清算和客户结算。因此这类业务被称之为“清结算”；

因此，本文后面会把三方支付的对账结算称之为“清结算”，细分的渠道资金处理称为“清算”，面向商户的资金处理称为“清分”或者“结算”。

1.2 三流合一，耦合架构

由于资金不能像指令一样在网络上传输，为了实现跨行资金转移，我们通过结合信息流和资金流的交易链路，并利用中间账务记录待结算的资金。在日终时，这些资金到账后会进行账务核销、渠道清算，最终完成客户的跨行资金结算。

三流合一，耦合链路

02 耦合链路，支付架构

支付架构的划分可以简化为“五横一竖”，其中重要的是交易与核心两层，他是整个支付平台的最核心八个模块。

业务架构

整个核心模块串联如下，日间“联机链路”进行跨行支付，驱动账务登记待结算资金，日终资金到账后通过“结算链路”完成账实一致，给客户结算资金。

核心流程

2.1 联机链路（信息流）

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

联机链路

2.2 结算链路(资金流）

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

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

结算流程

03 四段交互，支付收银

3.1 系统框架

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

收银台四段式交互

为了将多种支付方式整合到一个简洁的收银台页面中，首先提取标准化“统一收银能力”，其次将不同支付方式的差异化进行“统一包装”，最后把支付方式以选项的方式呈现给用户。

统一收银服务能力

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

收银台的用例模型（集成关系）

3.2 最佳实践

好的收银台需不断优化支付方式集成、用户体验和后台配置，以提升支付流畅度和效率。

04 四句口诀，支付交易

4.1 系统架构

交易系统的集成关系

交易是支付系统的核心服务，它接收业务请求，进行限额、风控和商家资质检查，并通过支付引擎完成支付和记账，最后将结果通知给相关方。

交易系统内部服务划分

交易系统内部服务按支付场景划分为“收单支付服务、余额支付服务、付款支付服务”，服务之间解耦可以支持不同交易场景扩展。

订单领域模型

交易系统虽然采用多服务的方式进行扩展，但是依然遵守着统一的订单模型来记录交易的处理过程，它接收来自终端的支付请求，记录交易过程和费用，驱动支付引擎完成支付和记账。

4.2 最佳实践

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

05 三级路由，支付渠道

5.1 系统架构

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

路由因子与系统匹配关系；

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

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

2）特征因子：对应渠道的一系列的特征参数表，他是每条渠道的个性化信息参数。

3）质量因子：对应渠道网关网关，他是表现每条渠道实际健康情况（运行时状态），减少渠道异常对于平台交易的影响；

支付渠道架构

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

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 系统架构

10.1.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 热点账户拆分

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

热点账户拆分

本文由人人都是产品经理作者【刚哥】，微信公众号：【刚哥白话】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。