在支付系统的复杂世界中，收单结算扮演着至关重要的角色。本文将带你了解收单结算的演进形态，如何在支付系统中定位收单，以及如何设计收单产品架构和系统架构。

收单结算是支付系统最重要的子域之一，行业内经常把有牌照的支付平台称为“收单机构”就可见一斑。

有些监管严格的国家地区，没有收单牌照就不能碰收单和结算，商户必须入驻到有收单牌照的支付机构。

不过，在我刚进入支付行业时，还没有收单平台的概念，那时系统还是单体应用，就只是建了一张商户订单表，用于保存商户订单信息，就是最简单的收单系统了。

随着业务复杂度增加，收单也早就不是一张表就能搞定。

本文主要讲清楚支付系统中收单涉及的基本概念，产品架构、系统架构，以及一些核心的流程和相关领域模型、状态机设计。

1. 收单结算概述

收单和结算结合很紧密，我们先讲一下收单结算的整体概念，再单独细讲收单平台，结算平台，拒付平台。

1.1. 基本概念

我们通常把收单、结算、拒付放在一起讲，主要是因为这三个都是面向商户的最核心的服务。简要如下：

• 收单：帮商户把钱从用户手里收进来。
• 结算：把从用户收进来的钱结转给商户。
• 拒付：在用户发起拒付后需要从商户待结算款里面扣除拒付的这部分钱（因为这部分钱需要退回给用户）。在国际收单场景比较常见。

这三者紧密联系却又彼此各有侧重点，后面分开讲述。

1.2. 整体产品架构图

从图中可以看到，最上层是收单的产品层，负责对商户提供直接的服务，并且封装个性化的收银台产品。主要包括有：

• 收银台支付：需要跳转到收银台进行支付；
• 二维码支付：需要先调用码平台进行解码，解码后就和普通的支付流程是一样的；
• 代扣/协议支付：商户后台发起扣款，不需要跳转到收银台。

再下面是三个核心，分别为收单核心、结算核心、拒付核心。

三者的职能如下：

1. 收单核心：主要负责处理商户订单的全生命周期管理：订单创建、支付推进、退款、撤销等。
2. 结算核心：主要负责把商户应收账款算清楚，把结算款按合同约定结转给商户。
3. 拒付核心：主要负责处理用户的拒付和对应的抗辩以及最后的判责。

2. 收单演进形态

无收单机构模式

这就是小时候去小卖部买糖的模式，一手交钱一手交货。

好处：足够简单。不足：无法完成线上交易。

行内收单模式

所谓行内收单，就是发行卡和收单是同一家银行。

好处：手续费低，成功率高。不足：业务比较受限，以线下收单为例，商户无法部署所有的银行POS机。

发卡行与收单行分离模式

大部分情况下，用户的发卡行和商户的收单行是不同的银行。

不过，这种情况基本也已经灭绝，因为需要发卡行和收单行两两对接，形成一个巨大的网状结构，维护成本高昂。

清算机构模式

发卡行和收单行之间不再直连，而是通过清算机构。清算机构通常是央行下面的特许经营的金融机构。这样围绕清算机构形成一个星形架构，所有银行只需要和清算机构对接就行。

当前银行间的交易基本上是这种形态。比如中国的银联，国外的VISA，MASTERCARD等，是卡组，也是清算机构。

第三方支付（电子钱包）形态

随着互联网支付的兴起，以第三方支付为中心形成另外一个星形结构。

上图做了很大的简化。在中国因为断直连的关系，支付宝、微信支付背后的财付通等这些第三方支付机构都是对接银联、网联，而不是直连银行。但是在国外仍然是允许直连银行的。

3. 收单在支付系统中的位置

把收单和结算再细化分拆，收单的地位如下图所示：

如果用一句话说明收单的核心能力和定位，那就是：负责商户收单业务的全生命周期管理。

4. 收单产品架构

前面说过，收单核心负责商户业务单的全生命周期管理，对外提供下单、退款、撤销、查询等接口。

行业内对于交易模式基本有3种：

1. 即时到账模式：用户支付完成后，钱就到商户账户。注意：这个“即时”是相对概念。商户真正拿到钱还需要看结算协议及结算进度。去小卖部拿支付宝、微信支付买零食都是这种模式。
2. 预授权模式：先从用户账上预授权一笔钱，交易完成后再进行请款。最常见的就是酒店住宿场景，入住时先预授权一笔钱做押金，离店时根据消费情况做请款，并撤销（Void）多余的预授权款项。
3. 担保交易模式：用户支付完成后，钱先扣在支付平台，用户确认收货后，再通知支付平台放款给商户。在淘宝买东西就是这种模式。

为支持对外的能力，收单需要建设很多基础服务，包括下单、支付推进、退款、撤销、通知、冻结解冻等。

5. 收单系统架构

这个系统架构图中包含了收单最基本的能力。

收单在收到商户的请求后，需要调用会员、商户等域校验合法性，还会调用合约中心等校验商户的权限，全部通过后，就会创建收单单据。

如果只是预下单，收单单据创建完成后就直接返回给商户订单创建成功，并返回收银台地址，供用户跳转到收单台继续支付。

如果是下单并支付（比如代扣），收单单据创建完成后，调用收银支付域进行支付扣款流程。

6. 收单核心流程

6.1. 极简支付流程

上面的时序图已经清楚说明支付整体的流程，以及各子域之间的交互。部分子域没有画出来，比如支付过程中需要调用风控、卡中心、额度中心等，这些在后面讲收银支付域时重点说明，本次聚集在收单领域。

另外，这里只画了类似代扣场景的支付流程，现实中的预授权、请款，担保交易、预付款（多次支付）等模式会复杂很多，后面有机会再单独开章节讲。

6.2. 极简退款流程

用户发起退款后，在商户侧会进行校验，校验通过后就会给用户展示退款已提交之类的提示。

收单接收到商户的退款请求后，需要先查询历史合约，检查合约是否支持退款，是否过了退款有效期，是否满足最小退款金额，全部通过后，就创建退款单并保存。

接下来会进入退款资金准备阶段，因为从资损防控的角度，除非另有合约约定，否则支付平台一般是不会做垫资退款的。在退款资金准备阶段，需要实时扣减商户待结算户的钱，这是与支付流程很大不同的点。当然，有些支付公司可能和商户约定从独立的退款账户进行扣款，那也需要保证这个退款账户余额充足。

上面最后一步的记账只写到了充退待清算户，之后等到清算文件过来后，会再继续推进充退待清算户到渠道应收的记账。

7. 收单领域模型设计

这是精简后的模型，对于说清楚收单的核心能力建设已经足够。真实场景下还需要增加很多必要的字段，比如产品码，合约号，冻结标识等。在做详细设计时根据业务诉求去增加就行。

从图中也可以看出，最核心是交易主单，所有其它单据都与交易主单关联。

比较特别的是里面有普通支付单和预授权单。正常都是普通支付单，只有预授权产品才会有预授权单，对应的还有请款单和预授权撤销单。

8. 收单状态机设计

下面以交易主单、普通支付单、退款单、预授权和请款单等常见的单据状态机做说明。

特别需要说明的是，状态机的推进一定要设计好，不能使用if else来写，要牢记“终态不可变更”的原则，否则容易出问题。具体怎么使用代码实现状态机，以及为什么“终态不可变更”，后面单独开章节来详细论述。

8.1. 交易主单状态机

交易主单创建初始入库就是INIT。

如果是下单并支付场景（比如代扣），就先推进到PAYING，然后调用收银支付进行扣款操作。如果是部分请款，也是支付中，全额请款完成或未请款部分撤销了预授权，就推进到SUCCESS。

如果是预下单，那停留在INIT，然后等支付域支付成功回执回来，推进到SUCCSSS。

如果订单关闭，就推进到CLOSE。

需要特别说明一点的是，一些经验不足的同学在交易主单耦合了很多不应该放在交易主单的状态，比如退款成功，撤销成功等。这导致交易主单的状态机特别复杂，非常容易出错。比较好的经验就是，交易主单、支付单、退款单、撤销单等全部只管自己的状态机。

8.2. 支付单状态机

支付单创建初始状态就是INIT。

收到支付域的支付成功回执，更新为SUCCESS。

交易超时关闭，推进到CLOSE。

8.3. 退款单状态机

退款单初始为INIT。

然后推进退款资金准备，这个过程把要退款的钱从商户待结算户或指定账户扣到退款过渡户，如果收单合约中还要求退款退费，还需要从收费账户把手续费扣出来。

退款资金准备成功后，推进到PREPARE_CUSS。

然后向支付域发起退款，支付受理成功后，推进到SUCCESS。

8.4. 预授权状态机

预授权单初始为INIT。

预授权失败回执推进到CLOSE。预授权成功后，用户全额撤销，也推进到CLOSE。

成功回执推进到AUTHED。

开始请款为CAPTURING，部分请款成功仍然为CAPTURING。

全额请款完成推进SUCCESS，或部分请款后，剩下额度被撤销，也推进到SUCCESS。

8.5. 请款状态机

请款单初始为INIT。

请款失败回执推进到CLOSE。

请款成功回执推进到SUCCESS。

9. 资金流

9.1. 即时到账

即时到账比较简单，支付过程，从支付网关过滤户到商户待结算户，再到商户余额。

退款则相反，在退款资金准备阶段需要从商户待结算户到退款网关过渡户。

9.2. 担保交易

担保交易模式比即时到账多了一个担保户。

9.3. 预授权模式

预授权模式比即时到账模式多了一个请款过渡户。

10. 结束语

本文主要讲了收单的基本概念，以及对应的产品和系统架构图，一些核心的领域模型和状态机设计。