支付的动力引擎

各位小伙伴大家好！

支付系统有三大黑盒“清结算对账、支付引擎和账务系统”，之所以说是黑盒一来是因为他们深藏后台很少被人看到，二来是有会计知识的门槛。这篇文章就用尽可能大白话的语言来介绍三个黑盒之一的“支付引擎”。

一、什么是支付引擎

支付引擎又被称为支付核心，他是支付系统的后台调度者，他负责本地账务的处理和跨行资金清分。并且支付引擎要能够承受每天百万笔的交易量和处理上亿的资金，因此他需要又快又准。

图1：支付引擎的位置

从上图可以看到，支付引擎处于后台中间的位置，他是联机交易和日终核算的调度者。

1.1、联机交易：

他承上启下负责将交易请求发送到账务中心记账和渠道清分，使得这笔交易的资金和账务实现最终一致。

1.2、日终核算：

他为对账中心提供记账数据，辅助对账中心和账务中心完成期末的账务核算。（核算就是会计的处理流程。）

二、支付引擎的设计 2.1、业务架构

图2：支付引擎业务架构图

支付引擎采用了分层的架构设计，支付前置接收交易订单和预处理；支付引擎负责核心账务逻辑的处理。

2.1.1、支付前置（业务场景过滤）

支付前置负责请求订单的解析、风控的检查和算费处理，其目让支付引擎更加高效的处理账务结算和渠道清分逻辑。

支付前置对外提供的可访问的接口是具有业务含义的，例如“充值、收单、快捷支付、网银支付、条码支付”等，支付前置根据不同交易去校验充值的同名、收单的商户交易风险、快捷的卡bin信息等，然后按照不同支付产品的账务要求来向支付引擎发送指令。

2.1.2、支付引擎（专注账务处理）

支付引擎负责核心的账务逻辑处理，这里的账务包含了账务结算的会计分录和渠道清分的交易金额。因此他对外提供的都是原子化接口，例如上面所说的“充值、收单”支付引擎统一按“入款”账务逻辑处理，是否同名只是收付款双方账号的填写区别，这些都在支付前置预处理阶段检查过了。

2.2、核心流程

支付引擎、账务中心、对账中心三者共同组成了支付核心系统。支付引擎在其中起到了核心调度者的作用。

图3：支付核心的处理流程

1）账务交易触发

触发支付引擎的账务交易有两种启动方式，一种是通过交易和收银台主动调用支付引擎（图中1.1、1.2）。另一种是配置清分场次来定时进行“自动结算、渠道清算、结算到卡”等周期性结算业务。

2）支付前置处理

支付前置负责报文解析、风控检查、费用计算等业务预处理，然后将指令转发给支付引擎进行账务处理。如果在风控检查阶段被拦截将直接撤销订单，返回给前台结果信息。

3）支付引擎处理

支付引擎就负责账务逻辑，记账的账户信息来源于用户的“结算协议”，记账分录和渠道交易金额来源于“清分规则”。

4）内场和外场处理

支付引擎调用外部账务系统和支付系统称之为出场，出场还分为内场和外场，内场负责账务中心记账，外场负责支付渠道的清分。内外场相互配合完成资金和账务的最终一致。

5）账务中心的处理

账务中心负责支付引擎发送的账务指令的处理。需要注意的是为了满足互联网用户高并发的要求，账务中心采用资金和账务分开处理的方式，实时更新客户账户的资金余额，异步来登记明细账务和更新内部分户账余额（详细的实现原理我们下次“账务核心”模块单独介绍）。

6）对账中心的处理

支付引擎为对账中心提供成功结算的入账数据，对账中心也通过支付引擎来进行调账和期末的结转平账操作。

2.3、业务模型

支付引擎分为驱动业务流转的服务模型和指令传递的订单模型。

2.3.1、支付服务模型

图4：支付服务ER模型

1）服务触发

服务流程有两种触发方式，一种是通过外部指令的主动触发，一种是通过清分场次来定时触发任务。

2）指令解析

支付服务首先会解析请求，然后创建指令来调用服务，

3）服务的执行

服务内部采用了流程化的处理方式，而流程则通过状态机来控制。状态机把每一次出场作为一个服务步点，出场的支付结果作为下一个步点的执行条件，如此循环往复直至支付完成。

3）生成指令

出场指令的生成，就根据参与者结算协议、清分规则生成清结算条款。内场条款是会计分录，外场条款是交易金额。

2.3.2、支付订单模型

图5：支付订单ER图

支付订单和指令分成了四层：

1、交易层：接受交易系统和收银台发起支付请求。每一笔请求都会生成一笔支付订单。

2、前置层：解析支付订单中的“产品编码、支付方式、交易类型”来生成支付指令，推送支付引擎进行账务处理。（详细的解析过程见《支付引擎服务流程》）

3、核心层：用来生成记账信息和渠道清分信息。

4、接触层：按支付流程分别访问账务中心和支付渠道。

为什么不拆分“收、付、退”子单？ 因为支付引擎只关注账务处理，这些场景在指令层面只有“账务和流程”的参数的不同而已，这样的设计一套指令就能适应不同场景的账务要求。当然如果考虑更高的性能要求，可以将其单独拆分子单来记录，但指令信息是差不多的。

图6：支付服务路由策略

支付引擎的策略模型是通过对订单因子的解析来路由目标服务，服务运行前为服务加载清结算参数。可以看到在整个策略路由过程中过滤掉了业务信息，只留下了账务信息和需要调用的服务节点。

图8：支付引擎策略模型

当订单因子在支付前置解析时，交易类型都被转化成“入款、出款、退款”等具有账务含义的支付类型。因为，这些交易在账务层面都是一样的，只是填写的收/付款方账号不同而已。

同时支付方式“快捷B2C借记、网银B2C贷记”等类型也统一归类为“快捷、网银、条码”等支付模式，因为对支付引擎来说他们只是调用渠道的流程有所不同，卡类型、公私标志对流程没有任何影响。

从上面这些过滤方式我们可以更加清晰的理解到“支付引擎只关注账务信息和跨行收付款”这个定义。

三、支付引擎服务流程

支付引擎采用流程化的服务处理方式，可以调用一个服务的主流程顺序执行，也能直接访问服务节点单步执行。为了流程能够灵活的流转，支付引擎采用了“交易步点+指令状态”的方式来顺序执行。

1）交易步点：就是支付流程处理的每个一子服务。

2）指令状态：就是个子服务执行指令的结果是“成功”还是“失败”。

每个流程都有一个“初始”节点，作为流程的入口节点，同时初始节点也会创建一个新的支付指令。每个流程节点处理的结果决定下一步走哪个子节点。

当然现在很多开发平台做成了更加方便的低码平台，可以用鼠标拖拽流程节点和设置分支逻辑。

3.1、入款处理流程

图9：入款处理流程和清结算指令

入款流程是先访问外部渠道，再完成内部账务处理。因此他有三个分支“支付成功、支付失败和支付撤销”，其中只有支付成功会涉及账务处理。日终对账后会完成渠道的汇总结转。

上图中“支付”是一笔指令，而“初始、申请、成功”是这笔指令控制的服务步点，结算和结转也是如此。

3.2、退款处理流程

图10：退款流程和清结算指令

退款业务是先从客户账户扣款，渠道退款成功则入待清算账户，退款失败则把钱退回客户账户。退款一般都是和正向交易配套出现的，简单的收单有通用的退款处理，复杂组合支付需要做资金来源的退款。

3.3、出款处理流程

图11：出款流程和清结算指令

出款流程与退款账务处理方式类似，先扣客户账户然后渠道完成出款，如果失败则返还客户账。

四、支付引擎交互设计 4.1、支付引擎交互主流程

图12：支付引擎交互主流程

支付引擎的核心是围绕支付服务展开的，他可以通过指令直接触发，也能通过配置的清算场次来触发。在流程处理过程中会获取默认的账号模版来生成相应的会计分录访问账务核心，以及交易金额来调用支付渠道。

4.2、服务流程：

图13：服务流程配置

支付引擎采用流程化的配置方式，按照服务编码和支付类型来访问对应的服务节点。访问支付服务可以通过“初始”节点作为主流程的入口程序，然后顺序的访问子流程。当然也可以直接填写子流程编码直接访问。

图14：流程设置

每个流程节点可以单独配置，内容包括对应的清算规则和下一步要执行的流程。当然现在比较流行的是采用可视化的拖拽方式来配置服务处理流程。

4.3、清分场次：

图15：入款业务清分场次

前面介绍的是实时触发流程的执行方式，当然也有定时触发的执行方式。例如期末核算、下发对账文件、商户资金的结算到卡等都可以通过场次的方式来配置不同提交和执行频次。

4.4、结算协议：

结算协议包含了账务处理的默认账号，以及不同交易的结算周期。

4.4.1、协议账号

图16：协议账号

存放填写会计分录时所使用的账号，因为有些账号只有在交易运行的时候才能获取到，例如“会员账号”、“机构待清算账户”等，因此可以在这里用参与方角色的方式来表示这些账号如何取值。

4.4.2、结算周期

图17：结算周期

填写每类交易的结算周期，例如充值、收单、提现等需要实时处理。提现次日到账等需要T+1日来执行。

4.5、清分规则

图18：清分规则

清分规则就是内场和外场的账务处理规则。例如上图给入款类账务处理设置一个“入款类条款”针对不同的清算代码设置账务处理规则。服务运行的时候会通过清算代码来执行这些规则。

4.5.1、内场条款

图19：内场条款

内场条款就是向“账务中心”进行记账处理的会计分录。他通过套号来管理这些记账分录，其中“会员账号、机构清算户”这些运行时才能明确的账号，用角色来替代。固定的内部过渡户直接填写相应的账号即可。

4.5.2、外场条款

图20：外场条款

【加我入群，注明"所属行业+地点"】

不炒币、不空投、不兑换、没代理