在支付系統(tǒng)的復雜世界中，收單結算扮演著至關重要的角色。本文將帶你了解收單結算的演進形態(tài)，如何在支付系統(tǒng)中定位收單，以及如何設計收單產(chǎn)品架構和系統(tǒng)架構。

收單結算是支付系統(tǒng)最重要的子域之一，行業(yè)內(nèi)經(jīng)常把有牌照的支付平臺稱為“收單機構”就可見一斑。

有些監(jiān)管嚴格的國家地區(qū)，沒有收單牌照就不能碰收單和結算，商戶必須入駐到有收單牌照的支付機構。

不過，在我剛進入支付行業(yè)時，還沒有收單平臺的概念，那時系統(tǒng)還是單體應用，就只是建了一張商戶訂單表，用于保存商戶訂單信息，就是最簡單的收單系統(tǒng)了。

隨著業(yè)務復雜度增加，收單也早就不是一張表就能搞定。

本文主要講清楚支付系統(tǒng)中收單涉及的基本概念，產(chǎn)品架構、系統(tǒng)架構，以及一些核心的流程和相關領域模型、狀態(tài)機設計。

1. 收單結算概述

收單和結算結合很緊密，我們先講一下收單結算的整體概念，再單獨細講收單平臺，結算平臺，拒付平臺。

1.1. 基本概念

我們通常把收單、結算、拒付放在一起講，主要是因為這三個都是面向商戶的最核心的服務。簡要如下：

• 收單：幫商戶把錢從用戶手里收進來。
• 結算：把從用戶收進來的錢結轉給商戶。
• 拒付：在用戶發(fā)起拒付后需要從商戶待結算款里面扣除拒付的這部分錢（因為這部分錢需要退回給用戶）。在國際收單場景比較常見。

這三者緊密聯(lián)系卻又彼此各有側重點，后面分開講述。

1.2. 整體產(chǎn)品架構圖

從圖中可以看到，最上層是收單的產(chǎn)品層，負責對商戶提供直接的服務，并且封裝個性化的收銀臺產(chǎn)品。主要包括有：

• 收銀臺支付：需要跳轉到收銀臺進行支付；
• 二維碼支付：需要先調(diào)用碼平臺進行解碼，解碼后就和普通的支付流程是一樣的；
• 代扣/協(xié)議支付：商戶后臺發(fā)起扣款，不需要跳轉到收銀臺。

再下面是三個核心，分別為收單核心、結算核心、拒付核心。

三者的職能如下：

1. 收單核心：主要負責處理商戶訂單的全生命周期管理：訂單創(chuàng)建、支付推進、退款、撤銷等。
2. 結算核心：主要負責把商戶應收賬款算清楚，把結算款按合同約定結轉給商戶。
3. 拒付核心：主要負責處理用戶的拒付和對應的抗辯以及最后的判責。

2. 收單演進形態(tài)

無收單機構模式

這就是小時候去小賣部買糖的模式，一手交錢一手交貨。

好處：足夠簡單。不足：無法完成線上交易。

行內(nèi)收單模式

所謂行內(nèi)收單，就是發(fā)行卡和收單是同一家銀行。

好處：手續(xù)費低，成功率高。不足：業(yè)務比較受限，以線下收單為例，商戶無法部署所有的銀行POS機。

發(fā)卡行與收單行分離模式

大部分情況下，用戶的發(fā)卡行和商戶的收單行是不同的銀行。

不過，這種情況基本也已經(jīng)滅絕，因為需要發(fā)卡行和收單行兩兩對接，形成一個巨大的網(wǎng)狀結構，維護成本高昂。

清算機構模式

發(fā)卡行和收單行之間不再直連，而是通過清算機構。清算機構通常是央行下面的特許經(jīng)營的金融機構。這樣圍繞清算機構形成一個星形架構，所有銀行只需要和清算機構對接就行。

當前銀行間的交易基本上是這種形態(tài)。比如中國的銀聯(lián)，國外的VISA，MASTERCARD等，是卡組，也是清算機構。

第三方支付（電子錢包）形態(tài)

隨著互聯(lián)網(wǎng)支付的興起，以第三方支付為中心形成另外一個星形結構。

上圖做了很大的簡化。在中國因為斷直連的關系，支付寶、微信支付背后的財付通等這些第三方支付機構都是對接銀聯(lián)、網(wǎng)聯(lián)，而不是直連銀行。但是在國外仍然是允許直連銀行的。

3. 收單在支付系統(tǒng)中的位置

把收單和結算再細化分拆，收單的地位如下圖所示：

如果用一句話說明收單的核心能力和定位，那就是：負責商戶收單業(yè)務的全生命周期管理。

4. 收單產(chǎn)品架構

前面說過，收單核心負責商戶業(yè)務單的全生命周期管理，對外提供下單、退款、撤銷、查詢等接口。

行業(yè)內(nèi)對于交易模式基本有3種：

1. 即時到賬模式：用戶支付完成后，錢就到商戶賬戶。注意：這個“即時”是相對概念。商戶真正拿到錢還需要看結算協(xié)議及結算進度。去小賣部拿支付寶、微信支付買零食都是這種模式。
2. 預授權模式：先從用戶賬上預授權一筆錢，交易完成后再進行請款。最常見的就是酒店住宿場景，入住時先預授權一筆錢做押金，離店時根據(jù)消費情況做請款，并撤銷（Void）多余的預授權款項。
3. 擔保交易模式：用戶支付完成后，錢先扣在支付平臺，用戶確認收貨后，再通知支付平臺放款給商戶。在淘寶買東西就是這種模式。

為支持對外的能力，收單需要建設很多基礎服務，包括下單、支付推進、退款、撤銷、通知、凍結解凍等。

5. 收單系統(tǒng)架構

這個系統(tǒng)架構圖中包含了收單最基本的能力。

收單在收到商戶的請求后，需要調(diào)用會員、商戶等域校驗合法性，還會調(diào)用合約中心等校驗商戶的權限，全部通過后，就會創(chuàng)建收單單據(jù)。

如果只是預下單，收單單據(jù)創(chuàng)建完成后就直接返回給商戶訂單創(chuàng)建成功，并返回收銀臺地址，供用戶跳轉到收單臺繼續(xù)支付。

如果是下單并支付（比如代扣），收單單據(jù)創(chuàng)建完成后，調(diào)用收銀支付域進行支付扣款流程。

6. 收單核心流程

6.1. 極簡支付流程

上面的時序圖已經(jīng)清楚說明支付整體的流程，以及各子域之間的交互。部分子域沒有畫出來，比如支付過程中需要調(diào)用風控、卡中心、額度中心等，這些在后面講收銀支付域時重點說明，本次聚集在收單領域。

另外，這里只畫了類似代扣場景的支付流程，現(xiàn)實中的預授權、請款，擔保交易、預付款（多次支付）等模式會復雜很多，后面有機會再單獨開章節(jié)講。

6.2. 極簡退款流程

用戶發(fā)起退款后，在商戶側會進行校驗，校驗通過后就會給用戶展示退款已提交之類的提示。

收單接收到商戶的退款請求后，需要先查詢歷史合約，檢查合約是否支持退款，是否過了退款有效期，是否滿足最小退款金額，全部通過后，就創(chuàng)建退款單并保存。

接下來會進入退款資金準備階段，因為從資損防控的角度，除非另有合約約定，否則支付平臺一般是不會做墊資退款的。在退款資金準備階段，需要實時扣減商戶待結算戶的錢，這是與支付流程很大不同的點。當然，有些支付公司可能和商戶約定從獨立的退款賬戶進行扣款，那也需要保證這個退款賬戶余額充足。

上面最后一步的記賬只寫到了充退待清算戶，之后等到清算文件過來后，會再繼續(xù)推進充退待清算戶到渠道應收的記賬。

7. 收單領域模型設計

這是精簡后的模型，對于說清楚收單的核心能力建設已經(jīng)足夠。真實場景下還需要增加很多必要的字段，比如產(chǎn)品碼，合約號，凍結標識等。在做詳細設計時根據(jù)業(yè)務訴求去增加就行。

從圖中也可以看出，最核心是交易主單，所有其它單據(jù)都與交易主單關聯(lián)。

比較特別的是里面有普通支付單和預授權單。正常都是普通支付單，只有預授權產(chǎn)品才會有預授權單，對應的還有請款單和預授權撤銷單。

8. 收單狀態(tài)機設計

下面以交易主單、普通支付單、退款單、預授權和請款單等常見的單據(jù)狀態(tài)機做說明。

特別需要說明的是，狀態(tài)機的推進一定要設計好，不能使用if else來寫，要牢記“終態(tài)不可變更”的原則，否則容易出問題。具體怎么使用代碼實現(xiàn)狀態(tài)機，以及為什么“終態(tài)不可變更”，后面單獨開章節(jié)來詳細論述。

8.1. 交易主單狀態(tài)機

交易主單創(chuàng)建初始入庫就是INIT。

如果是下單并支付場景（比如代扣），就先推進到PAYING，然后調(diào)用收銀支付進行扣款操作。如果是部分請款，也是支付中，全額請款完成或未請款部分撤銷了預授權，就推進到SUCCESS。

如果是預下單，那停留在INIT，然后等支付域支付成功回執(zhí)回來，推進到SUCCSSS。

如果訂單關閉，就推進到CLOSE。

需要特別說明一點的是，一些經(jīng)驗不足的同學在交易主單耦合了很多不應該放在交易主單的狀態(tài)，比如退款成功，撤銷成功等。這導致交易主單的狀態(tài)機特別復雜，非常容易出錯。比較好的經(jīng)驗就是，交易主單、支付單、退款單、撤銷單等全部只管自己的狀態(tài)機。

8.2. 支付單狀態(tài)機

支付單創(chuàng)建初始狀態(tài)就是INIT。

收到支付域的支付成功回執(zhí)，更新為SUCCESS。

交易超時關閉，推進到CLOSE。

8.3. 退款單狀態(tài)機

退款單初始為INIT。

然后推進退款資金準備，這個過程把要退款的錢從商戶待結算戶或指定賬戶扣到退款過渡戶，如果收單合約中還要求退款退費，還需要從收費賬戶把手續(xù)費扣出來。

退款資金準備成功后，推進到PREPARE_CUSS。

然后向支付域發(fā)起退款，支付受理成功后，推進到SUCCESS。

8.4. 預授權狀態(tài)機

預授權單初始為INIT。

預授權失敗回執(zhí)推進到CLOSE。預授權成功后，用戶全額撤銷，也推進到CLOSE。

成功回執(zhí)推進到AUTHED。

開始請款為CAPTURING，部分請款成功仍然為CAPTURING。

全額請款完成推進SUCCESS，或部分請款后，剩下額度被撤銷，也推進到SUCCESS。

8.5. 請款狀態(tài)機

請款單初始為INIT。

請款失敗回執(zhí)推進到CLOSE。

請款成功回執(zhí)推進到SUCCESS。

9. 資金流

9.1. 即時到賬

即時到賬比較簡單，支付過程，從支付網(wǎng)關過濾戶到商戶待結算戶，再到商戶余額。

退款則相反，在退款資金準備階段需要從商戶待結算戶到退款網(wǎng)關過渡戶。

9.2. 擔保交易

擔保交易模式比即時到賬多了一個擔保戶。

9.3. 預授權模式

預授權模式比即時到賬模式多了一個請款過渡戶。

10. 結束語

本文主要講了收單的基本概念，以及對應的產(chǎn)品和系統(tǒng)架構圖，一些核心的領域模型和狀態(tài)機設計。