图解：支付系统产品架构

在支付行业，系统架构的设计对于确保交易的安全、高效和稳定至关重要。本文将通过图解的方式，详细介绍支付系统的产品架构，包括耦合架构、产品架构、交易系统、客户系统、钱包账户、支付渠道、支付核心、支付引擎、清结算系统和账务核心等关键组成部分。

关于产品架构和业务架构的区别，一直存在争议。由于产品架构没有固定的标准，许多产品架构借鉴了TOGAF的4A架构理论中的业务架构方法。如果非要区分技术和产品，可以这样理解：产品主要关注用户使用的功能和内在关系的展示，而技术则更侧重于功能实现和技术栈的支持。

画的产品架构一般遵循三图两表的规范（业务架构图、集成架构图、业务时序图、功能清单、要素清单），限于篇幅我们清单就不罗列了，重点用前面三张图来进行介绍。

01 两条链路，支付架构

支付流程从行业内定义上来说，主要是“交易、清分、结算”这三个过程。

这三个过程在支付系统上就表现为“交易与结算”相结合的耦合架构。

1.1、耦合架构

为了支持买卖双方在线交易，清结算系统采用了耦合架构的设计方案。

鉴于资金无法如同订单一般直接通过互联网进行流转，本系统结合了交易链路和结算链路，形成了一种独特的清结算模式。

在此模式中，联机链路负责信息流的传递，而结算链路则承担资金流的转移任务。最终，账务系统通过执行相应的账务处理流程，实现了信息与资金之间的有效转换。

1.2、产品架构

支付的产品架构问四横一竖，四横代表了“网关层、产品层、交易层、核心层、渠道层”以及相关的基础服务。一竖则是业务支撑系统，包括“客户应用、运营管理、风控管理”等系统。

在我们的讨论中，最为关键的部分是交易处理与核心层的八个模块。这些模块构成了整个支付系统的核心功能，并且是本文重点介绍的内容。

1.3、两条链路

这八个核心模块共同协作，通过联机交易链路和结算交易交易链路，完成了线上的交易和资金流转。

1、联机交易链路

用户在前端业务系统操作后，订单被发送到交易系统，经过计费和风控检查，再由支付引擎调度，完成内部账务登记和外部渠道支付。

支付完成后，结果通过回调返回，更新账务和订单信息，并将入账流水推送到清结算系统，最终通知商户支付成功。

2、日终结算链路

日终结算链路，由资金系统和账务系统共同组成。

资金系统按预设批次处理当天的联机交易，与各渠道对账并清算，然后将待结算款项转入客户账户。

会计系统汇总这些交易和清算数据，进行总账校验，确保账目准确一致。完成后，系统结束当日的会计日切。

了解这两条链路和八个模块之后，下面我们就把最核心的7个模块来进行逐一介绍。

02 四段交互、支付收银

用户对支付最多的感知来源于收银台。收银台随着移动支付的推广，以及微信/支付宝的长期的市场教育，收银台形成了四段式标准化的交互流程，只要缺少任何一个步骤，交互体验都会出现问题。

1）交易下单

用户选择支付方式后提交，系统需要先向支付系统下单提交商品交易信息，同时系统也会上传回调地址作为支付结果的通知。

2）调用收银台

下单成功后渠道按照支付方式返回对应的收银台参数到支付系统内，支付系统调用收银台引导用户跳转到渠道侧进行支付。我们平时所看到的各种扫码、小程序的聚合支付就是在这里包装的。

3）回调通知

用户在渠道侧支付成功后，渠道侧根据上传的回调地址将支付结果通知到支付系统后台，完成订单的更新。

4）跳转返回

客户支付完成后点选返回，渠道根据商家申请的支付产品或者入网时配置的结果页面地址跳回商家收银台完成支付。返回时的跳转方式与下单时的需要匹配，否则就会出现无法跳转回商家收银台的情况。

03 四句口诀、交易系统

3.1、四句口诀

交易系统为买家和卖家提供支付功能，根据不同的支付场景，它支持收单、充值和付款三类服务。所有交易最终会通过资金系统进行日终对账，并为客户结算资金。虽然交易系统有很多功能，但简单来说可以用四句话概括。

1、两个范式

为了保障交易的安全，交易系统采用了收款和付款两种模式，他们分别负责控制支付的流程。

1）收款范式：先完成渠道扣款，然后再更新本地状态。

2）付款范式：先扣减客户余额，然后再向渠道完成付款，付款失败则冲回余额。

2、三态控制

交易过程有大量的交易节点组成，“成功、失败、处理中”这三类状态来控制每个节点交易的处理。其中成功、失败又被称为终态，而处理中则被称为运行态。

3、查退合一

交易过程中有很多的异常情况发生，影响了订单进入终态，因此需要用查询和退款的方式保证本地订单和渠道订单的最终一致。

4、差错三账

如果订单在联机交易阶段还没有进入终态，就需要通过日终对账来确认结果。对于账务差错采用了补账、冲正和挂账这三种差错处理方式

3.2、交易系统

在支付系统中，交易系统起到了承上启下的作用。他内部包含了“交易、充值、付款”三个主要服务，每个服务分别面向不同的交易场景，其中以交易服务场景最为复杂。

3.3、功能划分

虽然从产品使用上来说会划分出“收单、分账、余额、付款”等多种场景，但是他们都是对“交易、充值、付款”的二次包装而已。

1）交易服务：除了收单、分账以外，还包含了转账和冻结解冻；

2）充值服务：相对简单主要是充值、代充和充值退款

3）付款服务：对账户的出金服务，包含了单笔付款、批量付款以及付款的逆向交易退汇。

3.4、订单模型

交易的订单模型核心主链路是”交易订单、支付订单”，交易订单负责记录交易信息，而支付订单把订单信息转化成支付请求，最终通过支付引擎的指令完成内部记账，渠道流水完成跨行支付。

交易订单记录的信息比较丰富包含了正向的交易订单、逆向的退款订单，以及支持多层级商户分账订单。同时交易订单和支付订单分别对应的商户手续费和渠道成本，这样的方式收入和成本可以记录的更加清晰。

3.5、支付状态

支付状态按照收支分离的方式分为收款状态机和付款状态机，他们遵守着三态合一的规范，运行态控制着每个节点，终态负责记录最终的结果。

1）收单状态：收款状态机包含了收单、充值的两类交易，同时兼具退款功能。针对收单功能还延展出了分账状态。

2）付款状态：付款状态机对应着付款交易，他没有收款状态那么复杂只要处理付款的三态和退汇结果即可。

详情参考支付小钢炮，公众号：刚说产品四句口诀，搞懂支付交易设计

04 三户模型、客户系统

4.1、三户模型

所谓的三户就是“客户、用户、账户”的简称，其中客户拥有唯一的身份，但是他可以通过不同账号来开通多个用户身份，通过不同的用户身份来使用产品并且开出对应的账户进行交易。

1）客户：个人或者企业的唯一身份

2）用户：使用者的登录账号，每个账号都有不同的权限来使用产品。其中商户就是一种特殊身份的用户。

3）账户：给用户提供存放和支取资金、债务和权益的实体。

他与组织、渠道、交易、产品共同构成了以客户为中心的服务体系。

4.2、会员类账户模型

客户模型按照支付业务类型分为，银行卡收单的商户类模型和移动支付的会员类模型，我们这套系统采用的是面向互联网的会员类模型。

互联网支付类场景他们天然认为平台内所有的客户都是他们的用户，因此他们采用会员制，通过线上来开展业务。用户的身份通过开展的业务不同而在会员和商户之间转化。虽然会员系统结构简单，但是他的缺点就是扩展性差，做多只能支持两级商户体系。

4.3、产品架构

而我们这里给大家介绍的客户系统采用的是适合于互联网的会员模型体系。

1）对外端到端

一个客户系统一般包含多类角色，每一类角色都可以是看做一个用户端，这里就包括了面向个人的消费者端、面向企业的商家端、面向技术人员的开发这端，以及负责客户审核与服务的运营端。

2）对内全流程

整个客户服务流程包含了“注册、登录、实名、审核、签约、开户、对接”等多个节点，这些节点有贯穿了系统内部的“网关、渠道、认证、产品、交易”等多个系统。每个节点与多个流程有效衔接才能保障客户体验的流程。

4.4、集成关系

客户系统与内外部多个系统关联来保障客户的服务流程的顺畅，其中会员管理是核心服务，他通过会员号来管理商户和客户信息。

4.5、数据模型

客户数据模型采用了三户模型的结构，并且加上其关联的“产品、绑卡、认证等服务”

在这个客户领域模型中以会员模型代替了用户模型，但是他依然遵循了统一客户身份，会员多角色、账户与产品关联授权的三户模型关系。

05 一户多卡，钱包账户

要做个像支付宝一样的即能存放零钱，又能购买理财，消费时还能先享后付。这类钱包突破了传统的支付账户范畴，需要与更多的金融机构合作。因此需要从采用一户多卡的钱包账户模式。

5.1、钱包业务架构

钱包应用通过对网关和收银台的包装为用户提供了从注册、登录、商业应用、金融产品等一系列的服务。

5.1.1、钱包应用

为了构建这样的钱包体系，分为C端和B端都需要在支付体系内开户。

1）C端应用：用户提供账户和钱包支付能力。

2）B端应用：为场景提供方，为用户提供营销卡券、生活类应用和金融服务。

5.1.2、账户体系

为了实现资金在平台内的流动，就需要开出对应的中间科目。通过这些中间科目清算不同商业主体之间资金流转。

当然这里的账户之间的清算在我国是监管很严的。现在普遍通过收银台跳转到持牌机构的方式为用户提供金融服务。这样账务中心也就逐步减少这些中间科目了。

5.2、一户多卡，数据模型

如果要实现一个支付宝一样兼具银行卡、账户、理财、分期支付功能的钱包产品呢？这里就要介绍到一户多卡的模式了。

所谓的一户多卡，定义如下

1）一户：

内部的余额账户为“户”，通过一个主账户来保障消费者与平台内商户基本的消费交易。

2）多卡：

外部合作账户被称为“卡”，当主账户余额不足时，系统会自动通过已绑定的银行卡进行支付。理财账户和分期账户同样采用绑定银行卡的方式进行管理，并且在支付时会跳转至合作机构的收银台以完成交易。

3）两种清算方式中间科目清算：持牌机构一般通过购买一系列的牌照，实现账户、银行卡、理财、分期产品的合作，需要支付平台开通多个中间科目来实现金融产品间的清算。合作机构直清：非持牌机构一般与银行的Ⅱ/Ⅲ类户、理财账户、信贷分期产品合作，银行给商家提供给直接清算的服务。由于这种模式需要平台内的商户去银行开户，因此这种模式普遍用于营销活动当中。

06 三级路由、支付渠道

支付渠道作为外部接入系统，承担着与银行及第三方支付平台进行接口对接的任务。而支付路由则负责通过三级路由机制来选择最优的支付通道，以确保用户支付请求能够顺利完成。

6.1、渠道路由因子

渠道的路由因子就是对渠道参数的拆分，通过因子的组合可以形成不同的渠道路由规则，最终来确定一条通道。路由因子主要分为以下三类。

1）基础因子：对应的是渠道基本信息，通过支付订单的拆解匹配产品形态和目标机构符合要求的银行。

2）特性因子：对应渠道的特殊参数，例如维护、交易限额、黑白名单等需要单独配置的参数，这些因子需要深度的特性匹配，匹配到的渠道实际已经可以支付了。

3）质量因子：对应的是渠道网关，他主要是匹配渠道的运行状态是否正常，防止渠道异常造成大量的订单积累。

6.2、渠道集成关系

渠道整体的集成关系由“渠道服务、渠道路由、渠道管理、渠道网关”四部分组成，渠道服务接收来自支付引擎的请求，并将支付请求拆解成路由因子传递给“渠道路由”系统，经过三级路由计算后，选中一条支付通道，通过调用渠道网关完成接口的组装并完成支付。最终支付结果以回调的形式返回，并通知上游系统。

6.3、三级路由流程

分析完渠道设计后，下面我们就把流程、参数和模型进行串联，以此来了解其上下游的对应关系。

①解析支付订单，提取路由因子，准备路由。

②判断路由模式：动态路由则自动筛选渠道；直接路由则获取渠道号后直接进行第三级路由。

③一级渠道匹配：基于基础因子筛选符合条件的支付渠道，存入一级列表。

私二级特性匹配：遍历一级列表中的渠道，检查其限额、维护期、商户白名单等特性，符合条件的存入二级列表。

⑤三级网关检查：检查支付网关的服务质量（QoS），选择成功率高且速度快的渠道。

⑥组装接口并支付：根据选定的渠道组装接口，完成支付。

07 支付核心

支付核心是支付系统的一组核心服务，他由“支付引擎、账务核心、资金系统”三部分共同组成，将联机交易指令、跨行清算资金和本地账务三者融合，实现信息与资金的转换。

1）支付引擎：

支付引擎负责提供原子化的支付接口，将交易系统的支付请求转换支付指令，根据清结算规则，推动信息流的内场记账和外场清算。

2）账务核心：

负责内场的记账和会计账务处理，账务核心为了提升性能采用了异步账务处理的方式，先单边更新客户余额，然后异步复试记账，最后通过内外部客户账同步实现一笔联机账务的处理。

3）资金系统：

资金系统也叫清结算系统，负责渠道和内部系统的对账、差错处理与资金的清算与结转，驱动账务核心进行客资结算和总账核算，实现信息流与资金流的最终一致。

08、内外双驱、支付引擎

8.1、支付引擎

支付引擎是支付系统的核心驱动器，他对内提供原子化的支付服务，接收来自交易、收银台的支付请求；内部通过流程编排、清算协议、清分规则来执行支付指令，并驱动内场账务核心记账和外场支付渠道支付。

8.2、支付模型

支付引擎接收来自交易系统的请求，根据接口和产品编码找到支付入口，按照加载的清算协议和清算规则，并生成支付指令。然后执行设定的服务编排流程，驱动内场的记账和外场的支付。

• 服务配置：用来设置服务入口和流程配置。
• 清算协议：清算参与的对象和设定单笔或者汇总清算的周期。
• 结算周期：用来设定清算协议按照实时逐笔，还是按照定时汇总的方式进行清算。
• 参与方：用来设定参与方的默认账号和角色，用以统一配置账务记账规则。
• 资金渠道：用来配置不同资金渠道对应的记账科目。
• 内场规则：按账套设置账务核心记账的账套和对于的记账规则。
• 外场规则：设置账套设置支付渠道请求的支付处理参与。
• 清算场次：一个定时任务，用来设置什么时候开始对账和清算处理。

8.3、核心流程

支付引擎按照支付模式来编排流程，其中包含了“入款、入款退款、出款、出款退汇”等几组交易模式。我们这里主要介绍入款和出款两个核心流程。

1、入款结算流程

收单为入款交易，因此他实时联机交易先发送到渠道上，支付成功后完成账务处理。

日终对账后，根据明细文件更新商户订单后给商户进行轧差结算（收单金额扣减退款金额），根据清算文件进行渠道清算，实现银存与备付金的平衡。

2、出款结算流程

付款和提现为出款交易，出款交易的特点就是先扣减客户余额，然后发送渠道。如果成功就将资金结算到渠道清算账户；如果失败则冲正回到客户账户。

日终对账后，由于付款即结算，因此不需要给客户结算资金，直接做渠道的付款结转即可（由于出款是钱离开系统，因此这里要做出款核销，即渠道清算账户和渠道银存账户都扣减掉资金）

09 清算结转，清结算

9.1、清结算流程

清结算系统主要由资金系统来负责进行对账和结算处理，他是个业务作业系统，产品架构上本身没有特别的复杂度，复杂度还是在对账和清结算的账务处理。

整个日终流程主要包含三个阶段

1）资金对账：从备付金银行下载资金清算文件，将其与账务发生金额进行汇总核对，如果对平做银存结转，保障银存账户与备付金期末余额一致。如果没有对平就下载明细对账文件进行业务对账。

2）业务对账：从每条渠道下载明细对账文件与入账明细进行核对，不同则进行差错处理。渠道全部对平则给客户结算资金。

3）客资结算：核对每个客户当日收单与退款的交易明细，跟进成功的订单将客户待结算资金转为可用。

9.2、差错策略

在清结算对账中，其实清算、结账与客资结算是比较固定的，日常维护和新增渠道比较常见的问题是差错处理。差错处理跟进订单中的差错因子来找到对应的差错策略。

10 最终一致，账务核心

账务核心是支付平台的账务的基准。他日间与支付引擎配合记录联机交易清算账务，日终与对账中心配合处理期末的总账核算。

10.1、缓冲记账

日间联机交易分为内场结算和外场清算，账务核心负责内场结算账务的处理。为了实现支付高性能账务核心采，通过单边记账来更新客户余额，通过异步和缓冲记账的方式来更新内部户和客户月。

其中缓冲记账是针对集中操作内部户，或者涉及批量更新客户账户的情况，比如分账、担保交易、组合支付等。

这里以即时分账为例，首先通过单边记账扣减付款方余额，然后异步将记账分录推送到会计系统保持到分录流水表，并设置缓存记账任务。系统定时的根据缓冲任务来进行账簿的登记和内部户的更新，同时将结果推送外部客户账户来更新分账方的余额。

10.2、总账核算

我们在资金系统中已经介绍了清算结转，这里我们就介绍期末的总账核算。

总账核算是明细账簿的核算，通过明细账簿发生额核对，生成账簿的期末余额，并将明细账簿按照科目汇总到对应的总账账簿上并更新总账的科目余额。

最后对总账进行平衡检查，然后讲当日的期末余额更新到历史表作为下个会计日的期初余额。

最后系统完成会计日切。