編輯導讀：合規對於電商平臺來說並不陌生，和“錢”有關的支付都需要符合監管要求。本文作者參與了一個公司內部“清結算”專案，從中總結了一些經驗與你分享，一起來看看吧。
筆者作為一個支付清結算小白，經過一個公司內部“清結算”專案，初步對支付合規有了一定的認識，若小夥伴剛好做電商，要對接第三方支付公司的話，可以透過本文粗淺的初步瞭解一下。本文內容為個人實踐總結，若有不對之處，煩請留言友好指出，感謝。
一、實踐背景
初入公司，老大拋了一個作業給我，告知我公司要做合規，避免兩清，所以需要做清結算。我人好懵，合規是什麼？兩清是什麼？清結算是什麼？帶著這些對我而言陌生的詞彙，先開始了我的學習之旅，因為這些應該都是基本概念，不可能讓老大一一解釋給我，然而，要寫好這個作業，搞清楚這些術語，就明白作業目標是什麼了。下面從我個人理解角度，結合我們平臺（平臺模式為非自營業務，商品歸商家所有）現存的問題，說明一下這幾個關鍵詞彙。
合規其實就是電商平臺和“錢”有關的支付需要符合監管要求，而監管要求目標是保障平臺使用者的資金安全，避免平臺卷錢跑路，就像之前的P2P。我們公司存在的合規風險是因為平臺在中間做了代收代付的業務，違反監管要求，具體如下圖（平臺現狀圖）所示：
看本文的小夥伴，想一想你們的電商平臺是不是也有類似的問題？
二、我的“清結算”作業
下我上網看了不少清結算的介紹，還特意買了一本支付系統架構有關的書籍，發現清結算一般都是支付機構、銀行之間的交易記賬、資金清算，涉及的機構中國人民銀行、網聯、銀聯等，系統也設計中國人員銀行的大小額系統，和我們平臺貌似沒什麼關係，因為我們平臺只是對接第三方支付公司，清結算到底應該做什麼呢？其實做什麼，還是基於問題現狀去分析，就像第一部分的平臺現狀圖描述，平臺清結算主要解決的是平臺面臨的風險，經過思考，對平臺清結算重點應該做的內容有了比較清晰的認知：
- 建立虛擬戶體系
- 梳理平臺和錢有關的業務：充值、提現、消費業務1、消費業務2…（消費業務即使用者需要付款的業務）
- 做好資訊流記賬，包括賬戶緯度記賬（支出、收入等）、交易記錄緯度的記賬（交易金額、交易雙方、交易時間等）
具體，詳見下文。
三、清結算設計的重點方案設計
3.1 虛擬戶的賬戶設計
這裡需要先區分一下“賬號”、“賬戶”概念區別，之所以作區分，是因為有的人會把二者認為是一個概念，實則不同。賬號可以理解為就是電商平臺使用者的登入賬號，賬戶主要是和充值、提現、消費等業務有關的一個概念，賬戶是一個統稱，可以有不同的分類，例如支付寶的餘額理解成“餘額賬戶”，支付寶積分理解為“積分賬戶”，還有紅包，可以理解為“紅包賬戶”或“營銷賬戶”。我們平臺這次對接第三方支付公司，引入虛擬戶方案，就是為了賬戶而生。
虛擬戶方案則基於原有系統的賬號體系，建立1V1的虛擬戶，說明一下，我們平臺賬號與虛擬戶為一一對應的關係，實質上，我們對接這個第三方公司，1個賬號可對應三個虛擬戶。這次對接過程中梳理了對接第三方的開戶流程，具體如下：
1）個人開戶：即以個人主體作為認證依據
2）企業認證：即以企業為主體進行實名認證
如上所示，認證成功後，平臺使用者即可繫結銀行卡，也可順利開展充值、提現等業務。當然，賬戶體系管理後臺，會同步記錄賬戶的開戶資訊，如下圖所示：
特別說明一下狀態機，若賬戶狀態為凍結狀態，則需要梳理相關受到限制的業務，例如充值業務、提現業務、其他消費業務等，在使用者操作相關業務時，給予一定的友好提示；
3.2 梳理平臺的支付業務
主要是把平臺中和賬戶餘額有關的業務窮舉，需要根據業務，判斷應該呼叫第三方哪些介面實現資金流轉或賬戶餘額變動。比較常見的支付業務包括充值、提現、支付。具體如下：
3.2.1 充值
充值業務，我們財務比較關注的避免信用卡套現，故在對接場景的渠道例如使用支付寶掃碼/微信掃碼時，對接第三方支付，有個支付限制欄位，需要在傳參的時候，遮蔽非貸記卡。還有一個關鍵點，平臺獲得的所有支付結果，均從所對接的第三方廠商獲取，無需單獨獲取各個渠道（例如微信、支付寶等）的支付結果。
充值業務時序圖：
3.2.2 提現
3.2.3 支付
這裡講的支付，是狹義的支付，針對使用者購買商品進行付款的支付場景進行說明。
這裡的支付比較特殊，基本有三種方案：
第一種：直接使用賬戶餘額支付
使用餘額支付，顧名思義就是用虛擬戶的餘額進行支付，例如淘寶買東西，使用支付寶餘額進行支付。
第二種：透過賬戶餘額之外的渠道進行付款，例如銀行卡支付。
這個方案有2個層面的理解：
- 理解為充值即消費，先充值到餘額，再立即消費的流程，和餘額變動有關；
- 理解為使用其他渠道入金的方式進行支付，和餘額變動無關;
重點看業務需要的記賬規則，我們平臺在虛擬戶方案之前，是“充值即消費”的記賬思路，故此，對接虛擬戶方案後，依然是採用這種記賬思路。舉例子如下：
例如王一博賬戶餘額100，購買商品需要支付100元，在支付收銀臺，使用者選擇銀行卡123支付成功，則該使用者的賬戶流水如下：
但是，一些平臺會按照第二種思路記錄交易，例如使用微信支付時，支付方式若選擇的是銀行卡，微信“零錢-零錢明細”不會產生入金流水，而“微信支付”的對話方塊中，則會記錄支付方式為銀行卡；
第三種：使用組合支付
組合支付即使用多種方式結合進行支付，是主流購物場景常用的方式，例如餘額+銀行卡、餘額+優惠券等。
關於組合支付，和如下三種情況有關：
支付方式：不同支付方式，對組合支付的支援情況不同，但是大多數支付方式是支援組合支付的。我們對接的第三方支付公司，入金支付方式多達10多種支付方式，例如訂單POS、微信支付（APP 支付、掃碼支付、刷卡支付、公眾號支付、小程式支付、H5 支付）、支付寶支付（掃碼支付、刷卡支付、生活號支付、手機網站支付）、收銀寶快捷、銀聯（掃碼支付、被掃支付、JS支付）等。
業務需求：充值提現業務場景，一般是不支援組合支付。但是有的提現業務場景，積分可抵扣交易手續費，因此，提現訂單可能涉及組合支付，具體需結合業務訴求。
第三方支付公司的業務限制：例如我們平臺所對接的第三方支付公司不允許充值提現訂單的組合支付。
以上，不管哪種支付方式，都涉及交易驗證方式，一方面需要根據自己的業務判斷，交易驗證方式應該採用無驗證（類似免密支付）、還是採用密碼或簡訊驗證碼等；另外一方面，需要根據第三方支付公司對接渠道的要求，確定所採用的交易驗證方式。
3.3 交易記錄設計
就像上述內容中，充值訂單、提現訂單都會在相關環節生成交易記錄，也就是系統需要根據業務訂單進行記錄的資訊，交易記錄的設計意圖是基於平臺的業務，記錄賬戶相關的交易資訊，其實就是記清楚付款方、收款方，交易金額，相關商品或服務等，以便和第三方提供的商戶對賬檔案對賬使用。例如微信支付的記錄：
重點需記錄的欄位資訊如下：
前臺呈現層面，均為交易狀態=交易成功/交易成功-發生退款的記錄，便於財務和第三方下載的對賬檔案對賬。
四、總結
以上內容，是我認為電商平臺對接第三方支付平臺要覆蓋的基本內容。其實我們本次清結算專案裡面，還多了一些其他的業務輔助功能，例如基於交易記錄，定時統計賬戶餘額，同時獲取第三方的賬戶餘額，方便及時發現兩邊賬戶餘額不一致的異常賬戶；另外也做了關於日切統計，同步不同業務型別訂單的數量、交易金額等，為和第三方統計的結果做對賬使用。
總之，從0-1做一個專案，從無知小白，到專案投入研發，方案也被來來回回推翻了很多次，但是每一次推翻，讓我們的目標都更加清晰，我在這個過程也收穫頗多，希望大家遇到完全不懂的新專案，不要氣餒，擼起袖子幹就可以了～喜歡我的小夥伴可以關注我哇，我會持續分享自己的工作心得，可能有的是層面比較淺，希望大家支援～
本文由 @Tania 原創釋出於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議
