大家好，我是愛畫圖的剛哥！

前面寫了央行清算、三方清算以及數幣體系，從這篇開始我們寫點落地的東西，就是如何設計一套支付系統。我會繼續用圖解的方式從支付的第一性原理出發，系統的給你串聯支付的全流程，最終告訴你支付系統設計的十套模型。

當然，本文主要做框架性的知識梳理，詳細設計的小伙伴可以通過以下方式獲取試看版的電子書。

01 支付第一性原理

在進行支付設計之前，我們先要了解支付的第一性原理是什么，這樣你才不會被紛繁復雜的場景所繞暈，從本質上建立起自己的知識框架。所以我還是要在開頭多啰嗦幾句。

1.1、支付第一性原理

支付的第一性原理就是“貨和幣的收支與交付”，這個過程分為“交易、清算、結算”三個步驟。因此人們習慣的把他稱為“信息流、賬務流和資金流”，只有這三個流程完成閉環，這筆交易才算完成。

1.2、支付的三流合一

我們每天用的支付錢包，其實里面存放的并不是真實的“錢”，而只是電子記賬信息。

要把我們銀行卡上的錢轉到錢包，就需要類似支付寶、微信這樣的持牌機構去銀行開備付金賬戶。

當用戶支付的時候，通過聯機“交易鏈路”來驅動你的發卡銀行和錢包賬戶間進行收付記賬。不過，當天你在錢包上看到的錢只是一筆待結算的“賬務信息”，真實的資金還在你的開戶銀行的過渡戶當中。

所以日終，需要銀行把錢清算到支付機構的備付金賬戶，通過“結算鏈路”把資金和電子記賬信息進行核對后你的錢才到賬，此時你就可以提現了。

三流合一，耦合鏈路

02 耦合鏈路，支付架構

要實現線上的支付，支付系統需要設計成耦合架構，通過“清算賬務”將“聯機交易信息”與“日終結算資金”串聯起來，最終在資金到賬后，由清結算和賬務系統配合完成信息和資金的最終一致。

而我要介紹的這套設計正是基于這樣的核心邏輯打造的一套價值數百萬的真實支付系統。

2.1、系統業務架構

整個支付系統按領域劃分可以簡化為“五橫一豎”，其中最重要的是交易與核心的八個模塊，支付系統對外展現出來的特性都是由這八個模塊決定的。

支付系統業務架構

從支付系統核心流程可以看到“聯機交易”和“資金結算”的兩條鏈路，而“賬務系統居中”實時記錄聯機賬務，日終結算系統對賬后，配合清結算系統完成渠道和客戶資金的結算，最終通過總賬核算來確保信息和資金的賬務平衡。

支付系統核心流程

下面我們來詳細看下兩條鏈路是如何協調工作的。

2.2、聯機聯機鏈路（信息流）

聯機交易通過訂單信息實現跨行支付和賬務處理。它從前端接收支付請求，生成交易訂單，并通過支付引擎完成跨行支付及賬務登記。最終，交易結果會通知消費者和商家，并展示賬單。

聯機交易鏈路

2.3、資金結算鏈路（資金流）

日終資金到賬后，經過對賬和差錯處理確保賬目準確，通過渠道清算確認資金到賬，然后在客資結算階段，核銷客戶在途資金為可用余額，這樣客戶就能D1提現了。

為了結算靈活，渠道清算和客資結算可以解耦并獨立運行。在異常訂單不結算的情況下，日終通過總賬平衡檢查確保賬實相符。

資金結算鏈路

整體信息和資金流程清楚了，下面我們來分模塊拆解下各個子系統如何實現的。

03 四段交互，支付收銀

收銀臺是收單能力的可視化包裝，隨著微信、支付寶的普及，收銀臺的交互方式也趨于統一，總結下來分為“下單、跳轉支付、結果回調通知、返回商家頁結果”這四個步驟。

3.1、業務架構

收銀臺四段式交互

在系統實現層面，收銀臺接收來自不同終端和網關的請求，將支付能力通過收銀臺頁面展示給用戶。其后臺整合了會員、商家、交易、賬戶等綜合能力以支付方式的形式供用戶選擇。

收銀臺的用例模型（核心流程）

3.2、最佳實踐

收銀臺的核心指標是轉化率，關鍵在于提供流暢的用戶體驗。為此，通常會設計“聚合收銀臺”來集成多種支付方式，并通過統一界面屏蔽不同支付方式的差異，將最簡潔的操作呈現給用戶，幫助他們快速完成支付。

聚合收銀臺服務能力

04 四句口訣，支付交易

用戶提交訂單后，交易系統負責按約定流程處理買賣雙方的訂單。作為聯機交易鏈路中的核心服務，交易系統將底層支付資源整合為各類支付產品，供上游商家使用。我們常見的充值、提現、收單、退款、付款等功能，均由交易系統提供支持。

4.1、業務架構

交易系統接收前端訂單請求后調用相應子服務。各子服務按流程完成訂單拆分、配置讀取、手續費計算、風控處理等操作，再通過支付引擎完成支付與記賬，最終將結果通知買賣雙方。

交易系統的集成關系

交易系統根據不同的場景可以拆分成“收單交易、余額、付款”等子服務，服務之間解耦可以支持不同交易場景擴展。

交易系統內部服務劃分

交易系統雖然采用多服務的方式進行擴展，但是依然遵守著統一的訂單模型，對整個支付過程進行全流程的記錄和跟蹤，確保每一筆交易都被安全有效的執行。

訂單領域模型

4.2、最佳實踐

交易系統的復雜性主要來源于其業務規則的邏輯。我們將其簡化為四句口訣，掌握了這些基本原則后，就能應對各種場景。

05 三級路由，支付渠道

支付渠道又稱為資金渠道，它最為人津津樂道的就是渠道路由能力，它可以動態的為用戶選擇最快、最便宜的通道完成支付。

路由因子與系統匹配關系

渠道路由通過一套可配置化的路由參數組成，這些參數在系統架構層面分別對應支付渠道的幾個子系統；

1）基礎因子：對應一條渠道的基礎信息，也是資金渠道最核心的標準參數；

2）特征因子：對應渠道特性數據，它是每條渠道的個性化信息參數。

3）質量因子：對應渠道網關，它是每條渠道運行質量，通過質量因子可以減少渠道異常對于平臺交易的影響；

5.1、業務架構

從業務架構層面上看分為三層，并且部署在不同的網段；

1）渠道管理：部署在內部網絡，它是負責管理和配置“路由服務、資金渠道、基礎服務”等，這一層的應用都是將標準化的服務能力提供給上游系統調用，以屏蔽底層渠道差異；

2）渠道網關：部署在隔離網段，負責外部渠道的適配，將不同渠道的支付方式標準化，以便上層服務可以直接調用。

3）外部渠道：這一層已經是外部網絡了，按照接入的支付產品進行網絡的通訊、安全等方面的部署和配置；

支付渠道架構

支付渠道的集成實現了“服務、路由、渠道、網關”的逐級解耦，大家都比較關注路由，其實這里最核心的還是“渠道管理”，因為只有資金渠道路由參數豐富、配置合理、接口轉換清晰，才能有靈活的路由和渠道接口適配與組裝。

支付渠道集成關系

5.2、最佳實踐 5.2.1、渠道三級路由串聯

渠道通過三級路由策略選擇支付通道：首先根據支付基本信息篩選出一批通道，然后依據各通道的個性化特點進一步篩選，最后從篩選結果中根據通道質量選出最快的渠道完成支付。

渠道三級路由邏輯串聯

5.2.2、渠道路由局限性

支付渠道主要適合API形式銀行卡產品；對于微信、支付寶（簡稱AT）這類有多種終端類型，甚至需要sdk和終端秘鑰驗證的支付產品，其實并不適合路由，因為自動切換隨時可能被AT風控，一般是通過控制收銀臺支付方式展現來進行切換。

06 三戶模型，客戶系統

客戶系統負責對客戶全生命周期的管理，所謂的三戶就是“客戶、用戶、賬戶”的簡稱，其目的是實現“身份認證、產品使用、交易權限”的靈活管理。

三戶模型

1）客戶：是個人或者企業在社會中的唯一標識，例如個人只有一個身份證，企業只有一個營業執照；

2）用戶：是產品使用者的身份，其會根據使用的產品不同有多重身份，例如多個手機號可以注冊多個用戶，一個企業有多個操作員等；

3）賬戶：用來存放用戶的資金或資產，它也是交易的載體。

4）特殊用戶：商戶是一個特殊的用戶，可以把它理解成一個用戶角色或者標簽。

6.1、業務架構

在客戶系統中，會員就是用戶。從系統架構上可以看到所有的用戶服務都是圍繞會員模塊展開的，包括“登錄、注冊、簽約、開戶、交易、結算、注銷”等用戶全生命周期的管理。

客戶系統集成關系

客戶系統以會員賬號為核心，允許用戶使用多個賬號注冊和登錄。實名認證時，系統會將這些賬號與唯一的客戶身份（區分個人或企業）關聯起來。經過申請和認證的會員可以簽約多種支付產品，并開通相應的賬戶進行交易。

客戶領域模型

6.2、最佳實踐

俗話說“三分支付，七分進件”，由此可見，在開展一個支付業務前要做大量的客戶準入與審核工作。客戶系統的復雜度在于商戶準入階段通過收集進件資料對客戶進行KYC和KYB的審核。這就需要端到端的全流程管理，以及會員模型的靈活組合能力。

6.2.1、端到端用戶服務

一個支付產品的客戶來源很多，參與角色的協作關系也較為復雜。因此要對參與的角色按不同的“端”來進行劃分，進行全生命周期的管理，確保客戶全流程的自動化、無卡點。

端到端用戶服務流程

6.2.2、靈活的模型組合

支付業務中有復雜協作關系，包括會員、商戶、平臺商、子商戶、服務商、代理商等多種模式，這些都是通過客戶的領域模型來完成各種靈活的組合。

三戶模型靈活組合

07 一戶多卡，錢包賬戶

每個互聯網公司的老板都夢想擁有類似“支付寶”一樣的商業生態，它通過為大量用戶提供支付功能來構建支付、融資和投資的閉環生態系統。雖然從零開始打造一個支付寶非常困難，但利用銀行現有的金融產品，創建一個聚合錢包還是可行的。

7.1、業務架構

錢包是會員、支付與金融服務能力的一個可視化包裝，一款好用能營銷、能賺錢的紅包需要一套多角色的商戶體系，并且底層提供不同業務之間過渡科目來實現資金的清算。

錢包支付架構

錢包應用基礎能力主要由會員、交易服務提供，通過基礎服務能力嵌入各種生活、信貸、理財等服務場景。

錢包集成架構

錢包應用并不是一個簡單的系統能力的集成，他更加注重C端的用戶體驗。從注冊登錄每一個環節都要緊密銜接，并且需要數據埋點、用戶畫像和標簽體系來分析用戶的轉化率。

錢包應用服務旅程

7.2、最佳實踐

回到做一個“支付寶”的問題，與支付寶自建整個電商+支付+金融的生態體系不同，普通商戶主要目的在營銷，因此只要基于自身的業務場景構建一套賬戶體系即可，金融生態服務可以通過外部資源來進行集成。

7.2.1、一戶多卡模式

所謂的一戶就是面向客戶的一套賬戶體系，所謂多卡是就是外部商戶或機構提供的賬戶服務。一戶構建平臺C端用戶的核心能力，外部各類金融賬戶采用綁卡的方式與賬戶進行集成。

整個模式難點就是“賬戶”與“卡”之間資金清算，這需要結合具體的活動由持牌機構來提供不同商家的清算服務。

一戶多卡賬戶模式

7.2.2、個性化賬戶能力

會員服務提供的是基本的賬戶功能，這些功能與底層賬戶系統相映射。因此，錢包需要根據具體使用場景，對不同賬戶間的余額進行適當的整合和展示。

個性化錢包能力包裝

08 內外雙驅，支付引擎 8.1、支付核心

支付核心通過中間清算賬務科目實現“信息流”和“資金流”之間的自動轉換，其中支付引擎負責聯機交易的調度，資金系統負責資金的對賬和清結算，而賬務系統記錄完整的賬務信息，最終實現錢賬一致。

支付核心的學習還是有一些門檻的，首先你就要有基本的會計知識，這個可以下載我的電子書看下有個基本了解。

支付核心系統架構

8.2、支付引擎

支付引擎的作用就是提供聯機交易的調度，通過支付訂單調用不同原子支付接口，并且匹配到提前編排好的服務流程，驅動內場的賬務系統完成記賬，外場的支付渠道進行跨行支付。支付結果會原路返回同步通知上游系統更新結果，并通知交易參與方。

支付引擎集成架構

支付引擎的核心是支付指令，它基于支付訂單生成。支付指令將“結算協議”轉化為“外部渠道支付指令”，將“清算規則”轉化為“內部記賬分錄”，從而驅動渠道和賬務系統完成支付與記賬。

支付引擎領域模型

8.3、最佳實踐 8.3.1、參數化服務路由

支付引擎向上層交易系統提供多種原子化支付接口。為了靈活管理這些接口，我們使用參數化的策略模板來解析訂單信息，并根據模板將請求發送到相應的服務入口，從而完成支付調度。

支付引擎服務路由

8.3.2、步點化流程編排

支付引擎一般都是采用步點化的組合來實現支付處理流程，流程可以按模版自定義，步點可以組件化擴展和復用。指令的組裝和狀態的控制全部實現標準化參數。這樣就能確保支付引擎高效，穩定的運行。

09 清算結算，清結算系統

清結算系統又稱為“資金系統”他負責日終核算賬務，給客戶結算資金。資金系統的復雜性在于你要有相應的賬務基礎，

9.1、業務架構

支付引擎完成了聯機交易和賬務處理的登記，清結算系統就是將結算資金與交易訂單進行核對完成客戶資金的結算。

清結算系統架構

清結算的核心流程涉及“對賬（匯總和明細）、差錯調賬、渠道清算、客資結算”幾個步驟，最終通過“總賬平衡”來完成賬務的核算。

清結算系統核心流程

9.2、最佳實踐 9.2.1、對賬三張表

設計一個對賬系統主要是三張表就能建立起整個支付系統的核心規則；

對賬三賬表

1）對賬要素表（必選）：抽取標準對賬要素和主鍵進行對賬，不同渠道的差異特性都要解析為標準對賬要素進行核對。

2）差錯策略表（必選）：按照“渠道、交易類型、本方結果、對方結果”的維度指定不同差錯情況下的調賬策略，這樣可以提高自動化程度，減少人工介入。

3）賬務核算表（可選）：根據對賬結果核對賬務明細和總賬明細，確保試算平衡。這類表格主要用于收集結算人員的報表需求，并非設計時的必要條件。

9.2.2、清算結算解耦

為了實現清算與結算的解耦來提高客戶資金結算的靈活性，因此渠道側的清算和客戶一側的結算可以單獨處理。通過差錯調賬和總賬平衡來確保資金結算準確。

1）差錯調賬：明細部分，客戶的資金可以根據D1/D0/Dn的結算周期優先結算成功訂單，而異常訂單則在差錯調賬完成后進行結算。

2）總賬平衡：總賬部分，日終時，在完成清結算后，可以核對渠道清算和客戶結算的資金是否一致，確保總金額匹配且無遺漏。

清結算解耦

10 錢賬一致，賬務核心

賬務核心負責平臺內信息和資金流轉的所有賬務處理，也是一家持牌機構最重要的業務系統，所有子系統都要以他的賬務結果為準，因此被稱為“賬務核心”。

10.1、業務架構

賬務核心從系統架構層面看主要分為賬務系統和會計系統，由于賬務處理有事務一致性要求，因此為了提高性能，兩個子系統之間通過MQ異步通訊來實現解耦。

1）賬務系統：實時處理賬務請求和賬戶資金的變動；

2）會計系統：異步處理賬務信息確保事務一致性；

賬務系統業務架構

10.1.2、核心流程

賬務系統核心流程

賬務系統的核心流程主要分為日間和日終兩部分；

1、日間聯機賬務：

實時處理聯機賬務信息的記錄，包括賬戶余額變更與復式記賬；

• 同步資金變動：根據賬務請求生成記賬憑證，同步更新付款方客戶賬戶余額；

• 異步復式記賬：為了提升性能，它采用異步方式調用會計系統來復式記賬和更新內部賬戶，并異步更新收款方的賬戶余額。

2、日終總賬核算：

日終資金系統渠道清算和客戶結算完成后，總賬系統進行匯總核算確保當日資金處理無遺漏。

10.1.3、科目結構

直接上賬務領域模型過于抽象，這里介紹下賬務系統科目結構。

1）科目編號：科目依據財政部的標準進行擴展，形成一個科目樹結構。其中，根節點代表總賬科目，葉子節點是明細科目，而分支節點則用于分類，沒有實體。

2）總賬科目：相當于賬務樹的根節點，在系統實現上是一張匯總表，它是由末級科目的明細匯總而成。

3）明細科目：相當于賬務樹的葉節點，系統通過明細賬簿和分戶余額表來實現功能。其中，明細賬簿記錄詳細的賬務信息，而分戶余額表（即客戶賬戶）則記錄余額的資金變化。

賬務科目編碼

科目與系統實現關系可以按照客戶賬戶、內部賬戶視角來看。

1）客戶賬戶：

• 自動生成賬戶

  ：客戶賬戶是在會員開通后自動生成的，因此他是按照客戶模版來生成。

• 分戶記錄資金

  ：按照模版會開通記錄在途資金的結算戶和記錄余額的基本戶。每個賬戶根據科目的余額方向生成對應的“可用與凍結”分戶來記錄資金變動；

• 賬簿記錄明細

  ：底層有對應的明細賬簿來記錄賬務信息。

2）內部賬戶：

• 內部預先設置

  ：內部賬戶由結算人員根據業務提前設置，他是用來記錄賬務過渡信息。

• 賬簿記錄明細

  ：內部賬戶有對應的明細賬簿用來記錄賬務信息。

系統與科目映射關系

10.1.4、核心賬務流程

賬務的核心流程包括了聯機、清算、結轉三部分；

1）聯機交易：是按照收單、退款、付款、來賬四個維度來設計整個賬務體系；客資結算可以按照聯機成功的訂單進行處理。

2）渠道清算：日終每條渠道對賬后會軋差計算發生金額；

3）銀存結轉：按照每條渠道的清算發生額與銀存賬戶進行結轉，銀存賬戶與銀行一側結算戶（或備付金戶）期末完成平賬。

核心賬務流程

10.2、最佳實踐

作為支付業務的“皇冠”，賬務系統知識點滿滿，這里挑兩個最常見的性能優化問題給大家介紹下；

10.2.1、緩沖記賬一致性

緩沖記賬是一種解決過渡戶瓶頸的方法，它通過實時扣除付款方的資金余額，并以異步批量的方式進行賬務處理。為確保交易的完整性，因此在緩存記賬前，會生成一個事物號，通過事物號來保障記賬順序的順序執行。

緩沖批量記賬

10.2.2、熱點賬戶拆分

支付交易中存在大量過渡戶，這在高并發場景下成為瓶頸。同構緩沖記賬只是短期內解決問題，但長期來看，需要將過渡戶分散到各個客戶下以分散熱點，并對相關聯機記賬科目進行改造。

熱點賬戶拆分

講在最后

最后我們總結下吧，其實整個支付系統記住下面這張圖就行了，通過“交易、清算、結算”我們梳理出來了“聯機”和“結算”的兩條鏈路，通過賬務系統負責聯機賬務登記，最終通過結算流程完成“信息與資金”的最終一致。

剩下來的就是按照這張圖對每個模塊進行大量實踐和積累。

按這張圖死磕每一個模塊

【加我微信入群與更多的支付老法師交流】