圖解支付收單平臺設計：高效爲商戶收款

大家好，我是隱墨星辰，深耕境內 / 跨境支付架構設計十餘年。今天介紹收單平臺。

收單結算是支付系統最重要的子域之一，行業內經常把有牌照的支付平臺稱爲 “收單機構” 就可見一斑。

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

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

隨着業務複雜度增加，收單也早就不是一張表就能搞定。

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

1. 收單結算概述

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

1.1. 基本概念

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

收單： 幫商戶把錢從用戶手裏收進來。

結算： 把從用戶收進來的錢結轉給商戶。

拒付： 在用戶發起拒付後需要從商戶待結算款裏面扣除拒付的這部分錢（因爲這部分錢需要退回給用戶）。在國際收單場景比較常見。

這三者緊密聯繫卻又彼此各有側重點，後面分開講述。

1.2. 整體產品架構圖

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

收銀臺支付：需要跳轉到收銀臺進行支付；

二維碼支付：需要先調用碼平臺進行解碼，解碼後就和普通的支付流程是一樣的；

代扣 / 協議支付：商戶後臺發起扣款，不需要跳轉到收銀臺。

再下面是三個核心，分別爲收單核心、結算核心、拒付核心。三者的職能如下：

收單核心： 主要負責處理商戶訂單的全生命週期管理：訂單創建、支付推進、退款、撤銷等。

結算核心： 主要負責把商戶應收賬款算清楚，把結算款按合同約定結轉給商戶。

拒付核心： 主要負責處理用戶的拒付和對應的抗辯以及最後的判責。

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. 結束語

本文主要講了收單的基本概念，以及對應的產品和系統架構圖，一些核心的領域模型和狀態機設計。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5OmOfuVuDJHJWK8VP1ndPA