起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識圖解支付收單平臺設計：高效為商戶收款
在支付系統的復雜世界中，收單結算扮演著至關重要的角色。本文將帶你了解收單結算的演進形態，如何在支付系統中定位收單，以及如何設計收單產品架構和系統架構。
收單結算是支付系統最重要的子域之一，行業內經常把有牌照的支付平臺稱為“收單機構”就可見一斑。
有些監管嚴格的國家地區，沒有收單牌照就不能碰收單和結算，商戶必須入駐到有收單牌照的支付機構。
不過，在我剛進入支付行業時，還沒有收單平臺的概念，那時系統還是單體應用，就只是建了一張商戶訂單表，用于保存商戶訂單信息，就是最簡單的收單系統了。
隨著業務復雜度增加，收單也早就不是一張表就能搞定。
本文主要講清楚支付系統中收單涉及的基本概念，產品架構、系統架構，以及一些核心的流程和相關領域模型、狀態機設計。
1. 收單結算概述
收單和結算結合很緊密，我們先講一下收單結算的整體概念，再單獨細講收單平臺，結算平臺，拒付平臺。
1.1. 基本概念
我們通常把收單、結算、拒付放在一起講，主要是因為這三個都是面向商戶的最核心的服務。簡要如下：
- 收單：幫商戶把錢從用戶手里收進來。
- 結算：把從用戶收進來的錢結轉給商戶。
- 拒付：在用戶發起拒付后需要從商戶待結算款里面扣除拒付的這部分錢（因為這部分錢需要退回給用戶）。在國際收單場景比較常見。
這三者緊密聯系卻又彼此各有側重點，后面分開講述。
1.2. 整體產品架構圖
從圖中可以看到，最上層是收單的產品層，負責對商戶提供直接的服務，并且封裝個性化的收銀臺產品。主要包括有：
- 收銀臺支付：需要跳轉到收銀臺進行支付；
- 二維碼支付：需要先調用碼平臺進行解碼，解碼后就和普通的支付流程是一樣的；
- 代扣/協議支付：商戶后臺發起扣款，不需要跳轉到收銀臺。
再下面是三個核心，分別為收單核心、結算核心、拒付核心。
三者的職能如下：
- 收單核心：主要負責處理商戶訂單的全生命周期管理：訂單創建、支付推進、退款、撤銷等。
- 結算核心：主要負責把商戶應收賬款算清楚，把結算款按合同約定結轉給商戶。
- 拒付核心：主要負責處理用戶的拒付和對應的抗辯以及最后的判責。
2. 收單演進形態
無收單機構模式
這就是小時候去小賣部買糖的模式，一手交錢一手交貨。
好處：足夠簡單。不足：無法完成線上交易。
行內收單模式
所謂行內收單，就是發行卡和收單是同一家銀行。
好處：手續費低，成功率高。不足：業務比較受限，以線下收單為例，商戶無法部署所有的銀行POS機。
發卡行與收單行分離模式
大部分情況下，用戶的發卡行和商戶的收單行是不同的銀行。
不過，這種情況基本也已經滅絕，因為需要發卡行和收單行兩兩對接，形成一個巨大的網狀結構，維護成本高昂。
清算機構模式
發卡行和收單行之間不再直連，而是通過清算機構。清算機構通常是央行下面的特許經營的金融機構。這樣圍繞清算機構形成一個星形架構，所有銀行只需要和清算機構對接就行。
當前銀行間的交易基本上是這種形態。比如中國的銀聯，國外的VISA，MASTERCARD等，是卡組，也是清算機構。
第三方支付（電子錢包）形態
隨著互聯網支付的興起，以第三方支付為中心形成另外一個星形結構。
上圖做了很大的簡化。在中國因為斷直連的關系，支付寶、微信支付背后的財付通等這些第三方支付機構都是對接銀聯、網聯，而不是直連銀行。但是在國外仍然是允許直連銀行的。
3. 收單在支付系統中的位置
把收單和結算再細化分拆，收單的地位如下圖所示：
如果用一句話說明收單的核心能力和定位，那就是：負責商戶收單業務的全生命周期管理。
4. 收單產品架構
前面說過，收單核心負責商戶業務單的全生命周期管理，對外提供下單、退款、撤銷、查詢等接口。
行業內對于交易模式基本有3種：
- 即時到賬模式：用戶支付完成后，錢就到商戶賬戶。注意：這個“即時”是相對概念。商戶真正拿到錢還需要看結算協議及結算進度。去小賣部拿支付寶、微信支付買零食都是這種模式。
- 預授權模式：先從用戶賬上預授權一筆錢，交易完成后再進行請款。最常見的就是酒店住宿場景，入住時先預授權一筆錢做押金，離店時根據消費情況做請款，并撤銷（Void）多余的預授權款項。
- 擔保交易模式：用戶支付完成后，錢先扣在支付平臺，用戶確認收貨后，再通知支付平臺放款給商戶。在淘寶買東西就是這種模式。
為支持對外的能力，收單需要建設很多基礎服務，包括下單、支付推進、退款、撤銷、通知、凍結解凍等。
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. 結束語
本文主要講了收單的基本概念，以及對應的產品和系統架構圖，一些核心的領域模型和狀態機設計。
本文由人人都是產品經理作者【隱墨星辰】，微信公眾號：【隱墨星辰】，原創/授權 發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
收付款方式有很大的市場需求，多開發這方面可能有意義