在现代数字化经济中，第三方支付结算系统扮演着至关重要的角色，为线上交易提供便捷、高效的清分和结算服务。本文将深入探讨支付结算系统的架构设计，特别是其核心的两条耦合链路——联机交易链路和日终核算链路，以及它们如何共同支撑起整个支付生态系统的稳定运行。通过详细解析支付系统的分层架构、业务架构和处理流程，读者将获得对支付系统工作原理的全面了解。
我们这里说介绍的支付就是三方支付使用的支付结算系统，他能够为买卖双方进行线上的交易、清分和结算功能。很多人觉得支付架构不好画，其实还是因为不得要领，因为支付系统做的是清结算业务，因此在架构表现上就是以账务为核心的两条耦合链路。
一、两条耦合链路之所以要设计成耦合的交易链路，是因为资金不能像指令一样在网络上传输，因此我们跨行线上交易都是采用的待结算方式。
待结算就是先实时让指令传输，并以记账的形式登记处理结果，此时客户看到的资金是待结。资金到账后支付系统根据银行清算文件，把账务信息转化成给客户结算的资金，此时客户看到的资金可用。
图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个模式完成跨行资金的清结算。
