两条耦合链路，支付架构

我们这里说介绍的支付就是三方支付使用的支付结算系统，他能够为买卖双方进行线上的交易、清分和结算功能。很多人觉得支付架构不好画，其实还是因为不得要领，因为支付系统做的是清结算业务，因此在架构表现上就是以账务为核心的两条耦合链路。

一、两条耦合链路

之所以要设计成耦合的交易链路，是因为资金不能像指令一样在网络上传输，因此我们跨行线上交易都是采用的待结算方式。

待结算就是先实时让指令传输，并以记账的形式登记处理结果，此时客户看到的资金是待结。资金到账后支付系统根据银行清算文件，把账务信息转化成给客户结算的资金，此时客户看到的资金可用。

图1：支付架构的两条耦合链路

1. 联机交易链路

联机交易是指令从网关到渠道跨行收付款，在这过程中会使用到收银台来进行支付、会员系统验证客户身份。整个过程系统会把指令的往来收付结果在账务系统记账；此时客户查询的余额并不能提现，而是待结算。

2. 日终核算链路

日终银行清算后，对账系统将银行清算文件与支付数据进行核对，确认无误后给客户结算资金、渠道清算平账。最终完成总账的汇总核算，实现资金与账务的最终一致。‍‍

为什么是耦合的？

看到这里是不是觉得这张图很眼熟？是的，这就是银行会计的“收付实现制”；这也是我提出信息、账务、资金的支付三流合一原因。

二、支付的分层架构

支付系统是按客户订单完成‍跨行收付款，并将资金最终‍转移到收款人的账户里。因此整套系统按照“一个系统、两个通‍道、三层架构”来进行划分。

图2：支付系统架构分层

1. 一个系统

为了实现买卖双方的跨行收付款，支付平台会把支付产品包装成接口或支付页面提供给客户来使用，并通过系统的层层转换来实现资金的跨行转移到收款人账户里。

2. 两个通道

（1）网关/终端（接入端）

它是支付系统的“接入端”，将支付产品通过接口、页面、终端设备的形式提供给用户进行支付、开户和认证。同时访问网关或者使用终端设备还要安装“密钥和证书”，以此来保证你支付的安全。

（2）渠道（接出端）

它是支付系统的“接出端”，他负责对接三方、银行、清算机构的支付接口，把他转换成标准支付产品提供给上层的产品使用。如果选择对接了多家银行相同的支付产品，他能根据“订单、渠道、稳定性”进行动态的路由选择。

（3）三层架构

①产品层（场景化包装）

产品层是为了适应不同场景的支付需求，把基础支付产品包装成面向不同场景的支付产品，满足不同行业对于支付的需求。例如面向个人用户的B2C、C2C支付，面向企业的B2B支付，以及面向金融机构的消金支付等；因此产品层是基础产品的场景化包装，方便不同用户使用。

②交易层（基础支付产品）

为使用者提供基础的支付产品，包括充值、提现、收款、分账、付款等支付服务，满足多场景对支付的基本需求。他主要包括了收银台、交易系统、客户系统三部分。

③核心层（原始支付服务）

“核心层”又叫“支付层”，是为交易层提供原始的账务、渠道、清结算服务，他专注于内部账务逻辑和支付渠道的处理逻辑，并且核心层也代表了一个系统的核心能力，他决定了上层产品是否好用。这里主要包括了支付引擎、账务核心、对账中心三部分。

三、支付业务架构

图3：支付业务架构

业务架构顾名思义就是面向业务场景提供的架构图，他主要目的就是让非技术人员了解系统具有哪些能力，以及系统提供的能力是否符合期望。业务架构一般分为两张图“架构图、流程图”，架构图负责展示系统的功能结构，流程图负责展示功能之间关系。

从支付的业务架构我们可以看到，相对于分层架构，实际的业务架构有许多的辅助系统来支持支付业务的运行。不过支付业务核心闭环的还是支付服务中的8个模块当主角，下面我们来分别介绍下。

1. 收银系统

收银台系统就是以页面的形式提供给用户进行收款操作，同时它也会面向不同的支付终端提供各种类型的收银台，我们按终端类型把它们分H5收银台、SDK收银台、小程序收银台、WEB收银台、聚合收款码为五类。收银台形式有很多种了，主要还是依托于支付场景包装，让用户能够更顺畅的支付。

2. 交易系统

通过前面的介绍我们知道，交易系统是面向支付场景和用户提供的服务，因此他主要职责是处理业务场景复杂多变的支付处理需求。

图4 交易系统核心能力

（1）支付服务提供者

交易系统是支付服务的提供者，他负责给外部使用收款、付款、余额支付等交易方式，并以订单的形式记录支付的处理过程。

（2）交易服务提供者

据不同的场景它还提供担保交易、合单支付、组合支付等分账交易把资金分配给交易的参与方。因此我们使用的支付产品其实都是交易系统提供的服务。

3. 客户系统

顾名思义是为客户提供服务的系统。客户注册的时候都是会员角色。随着客户开出的账户不同就有了不同的身份。例如客户开出基本账户就是用户角色，如果申请支付产品开出特约商就是商户角色。因此在系统上表现为面向C端的用户钱包，面向B端商户平台，以及提供技术对接的开放平台。

4. 产品中心

产品中心是包装对外销售产品的一个配置中心，并且商户相关的签约产品、计费信息、交易限额等都可以通过灵活的模板来进行配置。它的作用就是提高配置效率，通过组件化的配置工具，能快速搭建一个新的支付产品出来提供给客户使用。

5. 支付引擎

支付引擎顾名思是支付的发动机，他负责所有系统与账户、渠道的支付流程处理。

图5 支付引擎核心能力

（1）支付提供者

它对交易层的“交易系统、客户系统、收银台”等屏蔽了底层支付账务、支付渠道管理的复杂性，让交易层可以专注于业务场景，即使底层渠道更换，账务进行调整，交易层也不会受到影响。

(2）流程调度者

有了支付引擎这个大当家，流程处理相关的“脏活累活”都由他来负责。账户、渠道、清结算就可以各司其职做好本职工作，如果涉及其他系统协作，通知“支付引擎”去干就可以了。

6. 账务中心

账务中心又叫账户系统、账务核心。他一般系统包含了账务、会计、总账三部分。账务对外提供记账服务，并且实时更新客户账户余额。会计部分用来登记会计账簿、更新内部账户余额。总账是日终的汇总核算服务，总账平衡后当天的业务才算结束。

7. 对账中心

又称为清结算系统，资金系统，他负责与支付渠道进行账务核对，差错处理、手续费的清分和客户资金的结算。同时对于资金归集、划拨等无法在实时交易中完成的结算操作，也是由清结算系统负责处理的。

四、支付架构流程

由于支付系统对于交易处理性能和资金结算效率要求都比较高，因此它采用的是流水线作业方式。从前面介绍的两条耦合链路我们知道，在支付架构的流程上表现出来的是联机链路、结算链路两条链路。

图6：支付系统流程图

1. 联机交易链路

联机交易链路从“网关”到“渠道”形成一条支付请求的处理流水线，客户、收银台、账户和清结算各节点按部就班的处理流水线传递过来的信息，完成客户信息校验，资金账号获取，收银台展示，账务登记，渠道路由和跨行收付款操作。

2. 日终结算链路

结算链路又叫清结算流程，他针对日间的实时交易，进行对账和清结算等处理，只有日终处理完了，一天的交易才算完毕。

下面我们就按照这两条链路来详细介绍他的处理机制。

五、联机交易链路

1. 收单流程

收单业务是第三方支付的核心业务，他场景化比较丰富，因此系统流程也会相对复杂些。我们针对“API收款”、“收银台收款”和“小程序收款”几种典型场景进行介绍。

（1）快捷支付（API直接支付）

快捷的API支付，首次发送短信验证码绑定开户银行卡，收单机构会提供一个协议号给商户保存；后续短信验证码可免，通过传送绑卡时的协议号就能完成免密扣款。具体流程见下图：

图7 快捷支付流程

（2）收银台支付（本地收银台支付）

收银台支付包含H5支付、SDK支付（集成在APP内），由于他可以包装比较多的支付方式在收银台上，因此又叫“聚合收银台”。我们这里介绍的场景是用户在收银台上选择本地绑定的银行卡，因此，通过快捷支付就能完成扣款，无需跳转到第三方。具体流程见下图：

图8 本地收银台支付流程

（3）小程序支付（渠道收银台支付）

以小程序支付为代表的，APP支付、微信H5支付、公众号支付、扫码支付等，都需要跳转到渠道方收银台上输入密码并完成支付。这种支付方式对客户来说比较安全，但是也比较封闭，因此在交互体验上也复杂了不少。具体流程见下图：

图9 渠道收银台支付流程

从上图可以看到以“交易”和“支付”为流程调度者的优势就出来了，他们可以任意的定制支付流程，从而满足复杂场景对于支付的处理要求。

2. 余额支付

余额支付就是以账户余额为基础的“充值、提现、转账到户、转账到卡”的交易。

（1）账户充值（充值API）

账户充值与收单流程基本类似，就是在充钱需要判断账户和绑定银行卡是实名认证后的同名账户。具体流程见下图：

图10 账户充值流程

（2）账户提现（代付API）

提现是充值的反向交易，因此他获取计费信息、校验绑卡同名与充值基本是相同的，区别在于它记账方式不一样。他采用先扣客户余额，然后发送渠道付款，这样资金处理比较安全。

图11 账户提现流程

（3）转账到银行卡（代付API）

转账到卡又称为“代付业务”，它和“提现”在支付、账务和渠道处理上是类似的，区别在于它的收款人不是本人。

图12 转账到卡付款流程

六、日终结算链路

日间实时支付交易完成后，日终清结算开始上场了。我们前面收单交易、充值交易等跨行收款交易资金还要结算给客户和商家，并且要给商家提供账单，这样一天的业务才算完成，下面我们来介绍下日终的清结算处理流程。

图13 日终清结算流程

1. 系统对账

下载渠道、支付系统、交易系统对账文件进行对账。先核对渠道账务，再对交易账务并按商家账户维度进行交易清分和手续费扣收。

2. 差错调账

完成对账后如果有差错，以渠道为准在“账户系统”内调平本方账务差错。

3. 渠道清算

当日对账无误后，根据当日的应收应付的轧差金额和渠道银存账户的期末余额，在账户系统内登记当日清算账务。

4. 商户结算

当日对账无误后，根据每个商户、客户的待结算资金进行结算，收款资金在他们账户上就可以使用了。（因为是以渠道方为准，渠道清算和商户结算没有必然的先后顺序，所以只要账务对平就可以进行）

5. 商户提现

商户结算完成后如果商户设为自动提现，系统在T+1日自动完成商户的打款操作，并生成商户结算账单。

6. 账务核算

渠道清算和商户结算完成后，账户系统的核算模块对当天的账务进行总分核算、汇总平衡，最终生成报表。当日的交易也就处理完成了。

七、总结

最后我们来总结下，支付系统架构层面的表现出来的就是“联机链路、日终链路”联调链路。由于跨行收付款时，指令和资金到账时效的不匹配，采用了日间记账的方式来记录待结算资金，通过日终清结算来给客户结算跨行资金。

联机交易通过“网关、交易、收银台、客户、支付、渠道”6个模块是了跨行收付款和账务登记。日终链路通过“支付、对账、账务、会计”这6个模式完成跨行资金的清结算。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！