一
本篇文章，我們主要來拆解下一般電商公司【支付中心】的產品架構圖。
在我們開始正式講解之前，大家先描述下自己對支付中心的認知。我想可能對於大部分普通用戶，對支付中心的理解可能更多就是付款頁面了，即收銀臺，用戶選擇不同支付方式進行付款。甚至連訂單申請的退款到賬，用戶也基本不會聯想到支付中心身上。
支付中心作為交易三流向中的資金流支持體系，是最為重要核心的部分，搞不好對公司就會產生不可估量的損失。接下來，我們就來系統性地瞭解下經典B2C電商的【支付中心】究竟有哪些模塊，每個模塊又有什麼職能？各模塊之間又是如何聯動的。
二、正文
說到底，支付中心的原子能力就是收、退、打，其他所有的一切，幾乎都是圍繞這幾個基礎能力搭建出來的應用產品。
支付中心對內的上游主要是業務訂單系統（本文主要描述經典場景），訂單會傳入支付結算所需要的核心信息，支付中心接收後轉化為系統內的收退打相關指令，並進行信息的回執；
支付中心對外是跟三方支付公司/銀行系統進行互動，支付中心將平臺的收退打指令轉為三方真實資金的收退打指令，三方產生信息回執；
而支付中心內部，主要包含收單系統與清結算系統。前者主要負責收款，後者主要負責退款與打款。
一圖一文，以下這張圖片就是本篇文章描述的核心：
簡單描述此圖的結構：
- 最上邊的訂單系統，就是觸發指令給支付中心的上游，一般就是公司的各個業務訂單系統；
- 橙色背景區域內，就是支付中心的內部系統模塊組成；
- 左側的模塊，是三方支付機構內部的大概邏輯（不再引入銀行，主要為了描述支付中心對外的資金信息交互）；
- 粗的線條，表示比較大的系統模塊或實體之間的交互邏輯；
- 細的線條，表示系統模塊內的指令與模塊之間的交互邏輯；
- 箭頭指向只是表明大邏輯上有關聯或順序，但僅限於宏觀層面，不開展到非常細節的產品設計層次；
接下來，我們從【收單】【清結算】【賬戶】【對賬】【交易安全】5個部分來展開：
1. 收單系統
收單系統的主要職責就是收款，對業務要保證下單支付轉化率，對系統要保證安全穩定、精準無誤；
我們用大概的時間順序來串聯描述各個環節：
1）訂單調用支付中心：
上游創建訂單後，會發起付款請求，比較常見的就是：
- 普通支付（原子層：父訂單：支付單=1：1，子訂單邏輯訂單體系內處理）
- 合單支付（原子層，訂單：支付單=N：N，支付中心還有一個父支付單與N支付單進行同步）
- 補差支付（原子層，訂單：支付單=N：N，支付中心根據N個原始支付單合併一個總支付單與訂單進行同步）
我們就拿比較經典的普通支付來說明，訂單創建後，獲取到業務、用戶和商品相關信息，然後創建支付單實體，支付單包含了支付收單所必須的上游信息。
2）支付單與收銀臺
支付單創建之後，上游訂單維持“待支付”狀態，用戶可以在限定時間內發起支付行為，即吊起收銀臺。
這裡注意，收銀臺本質上就是收款通道的整體邏輯控制，不同終端、不同業務可選擇支付通道的不同，例如：微信內是不可能用競品支付方式的、有的業務壞賬率高無法使用分期產品、信用卡手續費誰承擔、哪個收款通道默認選中/展示排序等等。這些本質上就是結合業務不同情況，為支付轉化率和交易安全作保障。
收銀臺支付通道也分以下幾種常見類型：
- 當前主流電商基本都是三方支付，如微信、支付寶、京東支付，也有部分銀行支付，還有花唄、白條等消費分期通道
- 另外，部分平臺也提供平臺賬戶餘額支付，即錢包業務
- 還有一些會把不同支付通道進行組合，如分期與非分期支付組合，方便額度不夠或想減少消費分期額的用戶。
3）收銀臺調用三方支付系統
當用戶選擇某種特定支付通道之後，收銀臺就會用sdk或內嵌M頁吊起支付通道，用戶放棄某個通道之後，大部分場景可以更換其他支付通道繼續支付。
在三方支付的體系內，在使用餘額或綁卡支付成功後，真實資金會從用戶在三方的用戶賬戶餘額轉往平臺在三方的商戶賬戶餘額（有賬期的暫不展開）；同時，三方告訴平臺的支付中心用戶已完成付款，平臺的支付單可以變更已付款狀態，並回執給訂單變更訂單狀態。
2. 清結算系統
清結算系統分為清分系統、結算系統組成。
1）清分系統
清分系統職責：處理上游業務單的分賬請求，並轉換成為標準的清分記錄，進而在業務結算時機調用結算系統產生結算記錄；
一條清分記錄，會被拆分為N條結算記錄。清分記錄可以理解為業務一筆訂單的完整分賬信息，可能包含很多目標賬戶，結算的時機也可能不同，經過清分系統之後，會轉化為一條條格式化的結算原始記錄，主要是出資賬戶和單個目標賬戶、結算金額、結算時間等核心信息；
2）結算系統
結算系統職責：將清分系統產生的結算記錄，按照賬期產生結算單，進而按照商戶系統合同打款信息進行轉賬打款操作（包含欠款扣款邏輯）；
結算系統，將待結算的結算記錄按照結算週期和結算對象，分別進行合併運算，生成結算單（如果是負值結算單可能涉及到滾動生成結算單）。結算記錄：結算單=N：1。
結算單如果是正值，則生成打款單/提現單，然後將錢款進行打出，也有可能是多批次打出。結算單：打款單=1：N；
商戶會按照結算單與自己在平臺經營的訂單信息進行對賬，看是否有誤差，以及關注結算單的打款進度。
3. 賬戶系統
賬戶基礎原子能力有：充、提、凍、轉（支付、轉賬、扣罰）。支付單、結算單/提現單、凍結/解凍、轉賬等都會產生賬戶流水。
賬戶分類一般分為3大類：平臺類賬戶、用戶類賬戶、映射賬戶。
- 平臺類賬戶根據不同財務用途會劃分很多種，例如代收代付、預收、應收、成本、資金等等。
- 用戶類賬戶，體現在用戶端就是餘額錢包的場景，可以充值、提現、凍結等操作。
- 映射類賬戶，主要用來映射平臺在三方的資金情況，便於平臺實時瞭解平臺的各渠道資金情況，便於調撥等用途；
4. 對賬系統
標準的對賬系統，大概分為以下4種對賬：
- 賬證：業務層-賬務層，即業務訂單與支付中心賬務進行對賬；
- 賬賬：賬務層-會計層，總賬與總賬、明細賬、日記賬、明細賬之間相互核對的過程；
- 賬實：內部-外部，即支付中心與三方及銀行進行對賬；
- 賬表：會計報表-會計科目，跟本系統層面關聯較弱。
5. 支付安全
支付中心的天職就是為平臺交易安全提供保證。不僅要關注交易的雙方角色，還要核心關注錢款的流向，尤其是收、打這2個節點。
- 第一方面，支付中心包保證合規、合法。首先支付中心設計要滿足監管部門的要求，同時還要結合業務上游和支付中心聯動，積極反詐騙、洗錢、信用卡套現等違規違法行為。
- 第二方面，要做到系統健壯。從系統設計、系統實施、系統運營，都需要非常嚴謹，兜底也要建立完備的預警機制、熔斷機制，為公司業務上游提供安全可信賴的支付服務。
三、結尾
本文聚焦在支付中心的框架內，比較宏觀介紹了部分系統的定義和職責，另外有些模塊也都還在探索摸索階段，並非標準答案。
支付中心繫統底層設計比較固定，最關鍵是能夠結合企業自己的業務做好對應的架構設計和運行支撐。跟著業務變化而迭代系統，這樣才能做出一個有靈魂的支付中心。
一圖一文系列，第2篇，收~
作者：六小藝，轉轉交易中臺產品負責人。
