起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識圖解：支付系統產品架構
在支付行業，系統架構的設計對于確保交易的安全、高效和穩定至關重要。本文將通過圖解的方式，詳細介紹支付系統的產品架構，包括耦合架構、產品架構、交易系統、客戶系統、錢包賬戶、支付渠道、支付核心、支付引擎、清結算系統和賬務核心等關鍵組成部分。
關于產品架構和業務架構的區別，一直存在爭議。由于產品架構沒有固定的標準，許多產品架構借鑒了TOGAF的4A架構理論中的業務架構方法。如果非要區分技術和產品，可以這樣理解：產品主要關注用戶使用的功能和內在關系的展示，而技術則更側重于功能實現和技術棧的支持。
畫的產品架構一般遵循三圖兩表的規范（業務架構圖、集成架構圖、業務時序圖、功能清單、要素清單），限于篇幅我們清單就不羅列了，重點用前面三張圖來進行介紹。
01 兩條鏈路，支付架構
支付流程從行業內定義上來說，主要是“交易、清分、結算”這三個過程。
這三個過程在支付系統上就表現為“交易與結算”相結合的耦合架構。
1.1、耦合架構
為了支持買賣雙方在線交易，清結算系統采用了耦合架構的設計方案。
鑒于資金無法如同訂單一般直接通過互聯網進行流轉，本系統結合了交易鏈路和結算鏈路，形成了一種獨特的清結算模式。
在此模式中，聯機鏈路負責信息流的傳遞，而結算鏈路則承擔資金流的轉移任務。最終，賬務系統通過執行相應的賬務處理流程，實現了信息與資金之間的有效轉換。
1.2、產品架構
支付的產品架構問四橫一豎，四橫代表了“網關層、產品層、交易層、核心層、渠道層”以及相關的基礎服務。一豎則是業務支撐系統，包括“客戶應用、運營管理、風控管理”等系統。
在我們的討論中，最為關鍵的部分是交易處理與核心層的八個模塊。這些模塊構成了整個支付系統的核心功能，并且是本文重點介紹的內容。
1.3、兩條鏈路
這八個核心模塊共同協作，通過聯機交易鏈路和結算交易交易鏈路，完成了線上的交易和資金流轉。
1、聯機交易鏈路
用戶在前端業務系統操作后，訂單被發送到交易系統，經過計費和風控檢查，再由支付引擎調度，完成內部賬務登記和外部渠道支付。
支付完成后，結果通過回調返回，更新賬務和訂單信息，并將入賬流水推送到清結算系統，最終通知商戶支付成功。
2、日終結算鏈路
日終結算鏈路，由資金系統和賬務系統共同組成。
資金系統按預設批次處理當天的聯機交易，與各渠道對賬并清算，然后將待結算款項轉入客戶賬戶。
會計系統匯總這些交易和清算數據，進行總賬校驗，確保賬目準確一致。完成后，系統結束當日的會計日切。
了解這兩條鏈路和八個模塊之后，下面我們就把最核心的7個模塊來進行逐一介紹。
02 四段交互、支付收銀
用戶對支付最多的感知來源于收銀臺。收銀臺隨著移動支付的推廣，以及微信/支付寶的長期的市場教育，收銀臺形成了四段式標準化的交互流程，只要缺少任何一個步驟，交互體驗都會出現問題。
1）交易下單
用戶選擇支付方式后提交，系統需要先向支付系統下單提交商品交易信息，同時系統也會上傳回調地址作為支付結果的通知。
2）調用收銀臺
下單成功后渠道按照支付方式返回對應的收銀臺參數到支付系統內，支付系統調用收銀臺引導用戶跳轉到渠道側進行支付。我們平時所看到的各種掃碼、小程序的聚合支付就是在這里包裝的。
3）回調通知
用戶在渠道側支付成功后，渠道側根據上傳的回調地址將支付結果通知到支付系統后臺，完成訂單的更新。
4）跳轉返回
客戶支付完成后點選返回，渠道根據商家申請的支付產品或者入網時配置的結果頁面地址跳回商家收銀臺完成支付。返回時的跳轉方式與下單時的需要匹配，否則就會出現無法跳轉回商家收銀臺的情況。
03 四句口訣、交易系統
3.1、四句口訣
交易系統為買家和賣家提供支付功能，根據不同的支付場景，它支持收單、充值和付款三類服務。所有交易最終會通過資金系統進行日終對賬，并為客戶結算資金。雖然交易系統有很多功能，但簡單來說可以用四句話概括。
1、兩個范式
為了保障交易的安全，交易系統采用了收款和付款兩種模式，他們分別負責控制支付的流程。
1）收款范式：先完成渠道扣款，然后再更新本地狀態。
2）付款范式：先扣減客戶余額，然后再向渠道完成付款，付款失敗則沖回余額。
2、三態控制
交易過程有大量的交易節點組成，“成功、失敗、處理中”這三類狀態來控制每個節點交易的處理。其中成功、失敗又被稱為終態，而處理中則被稱為運行態。
3、查退合一
交易過程中有很多的異常情況發生，影響了訂單進入終態，因此需要用查詢和退款的方式保證本地訂單和渠道訂單的最終一致。
4、差錯三賬
如果訂單在聯機交易階段還沒有進入終態，就需要通過日終對賬來確認結果。對于賬務差錯采用了補賬、沖正和掛賬這三種差錯處理方式
3.2、交易系統
在支付系統中，交易系統起到了承上啟下的作用。他內部包含了“交易、充值、付款”三個主要服務，每個服務分別面向不同的交易場景，其中以交易服務場景最為復雜。
3.3、功能劃分
雖然從產品使用上來說會劃分出“收單、分賬、余額、付款”等多種場景，但是他們都是對“交易、充值、付款”的二次包裝而已。
1）交易服務：除了收單、分賬以外，還包含了轉賬和凍結解凍；
2）充值服務：相對簡單主要是充值、代充和充值退款
3）付款服務：對賬戶的出金服務，包含了單筆付款、批量付款以及付款的逆向交易退匯。
3.4、訂單模型
交易的訂單模型核心主鏈路是”交易訂單、支付訂單”，交易訂單負責記錄交易信息，而支付訂單把訂單信息轉化成支付請求，最終通過支付引擎的指令完成內部記賬，渠道流水完成跨行支付。
交易訂單記錄的信息比較豐富包含了正向的交易訂單、逆向的退款訂單，以及支持多層級商戶分賬訂單。同時交易訂單和支付訂單分別對應的商戶手續費和渠道成本，這樣的方式收入和成本可以記錄的更加清晰。
3.5、支付狀態
支付狀態按照收支分離的方式分為收款狀態機和付款狀態機，他們遵守著三態合一的規范，運行態控制著每個節點，終態負責記錄最終的結果。
1）收單狀態：收款狀態機包含了收單、充值的兩類交易，同時兼具退款功能。針對收單功能還延展出了分賬狀態。
2）付款狀態：付款狀態機對應著付款交易，他沒有收款狀態那么復雜只要處理付款的三態和退匯結果即可。
詳情參考支付小鋼炮，公眾號：剛說產品四句口訣，搞懂支付交易設計
04 三戶模型、客戶系統
4.1、三戶模型
所謂的三戶就是“客戶、用戶、賬戶”的簡稱，其中客戶擁有唯一的身份，但是他可以通過不同賬號來開通多個用戶身份，通過不同的用戶身份來使用產品并且開出對應的賬戶進行交易。
1）客戶：個人或者企業的唯一身份
2）用戶：使用者的登錄賬號，每個賬號都有不同的權限來使用產品。其中商戶就是一種特殊身份的用戶。
3）賬戶：給用戶提供存放和支取資金、債務和權益的實體。
他與組織、渠道、交易、產品共同構成了以客戶為中心的服務體系。
4.2、會員類賬戶模型
客戶模型按照支付業務類型分為，銀行卡收單的商戶類模型和移動支付的會員類模型，我們這套系統采用的是面向互聯網的會員類模型。
互聯網支付類場景他們天然認為平臺內所有的客戶都是他們的用戶，因此他們采用會員制，通過線上來開展業務。用戶的身份通過開展的業務不同而在會員和商戶之間轉化。雖然會員系統結構簡單，但是他的缺點就是擴展性差，做多只能支持兩級商戶體系。
4.3、產品架構
而我們這里給大家介紹的客戶系統采用的是適合于互聯網的會員模型體系。
1）對外端到端
一個客戶系統一般包含多類角色，每一類角色都可以是看做一個用戶端，這里就包括了面向個人的消費者端、面向企業的商家端、面向技術人員的開發這端，以及負責客戶審核與服務的運營端。
2）對內全流程
整個客戶服務流程包含了“注冊、登錄、實名、審核、簽約、開戶、對接”等多個節點，這些節點有貫穿了系統內部的“網關、渠道、認證、產品、交易”等多個系統。每個節點與多個流程有效銜接才能保障客戶體驗的流程。
4.4、集成關系
客戶系統與內外部多個系統關聯來保障客戶的服務流程的順暢，其中會員管理是核心服務，他通過會員號來管理商戶和客戶信息。
4.5、數據模型
客戶數據模型采用了三戶模型的結構，并且加上其關聯的“產品、綁卡、認證等服務”
在這個客戶領域模型中以會員模型代替了用戶模型，但是他依然遵循了統一客戶身份，會員多角色、賬戶與產品關聯授權的三戶模型關系。
05 一戶多卡，錢包賬戶
要做個像支付寶一樣的即能存放零錢，又能購買理財，消費時還能先享后付。這類錢包突破了傳統的支付賬戶范疇，需要與更多的金融機構合作。因此需要從采用一戶多卡的錢包賬戶模式。
5.1、錢包業務架構
錢包應用通過對網關和收銀臺的包裝為用戶提供了從注冊、登錄、商業應用、金融產品等一系列的服務。
5.1.1、錢包應用
為了構建這樣的錢包體系，分為C端和B端都需要在支付體系內開戶。
1）C端應用：用戶提供賬戶和錢包支付能力。
2）B端應用：為場景提供方，為用戶提供營銷卡券、生活類應用和金融服務。
5.1.2、賬戶體系
為了實現資金在平臺內的流動，就需要開出對應的中間科目。通過這些中間科目清算不同商業主體之間資金流轉。
當然這里的賬戶之間的清算在我國是監管很嚴的。現在普遍通過收銀臺跳轉到持牌機構的方式為用戶提供金融服務。這樣賬務中心也就逐步減少這些中間科目了。
5.2、一戶多卡，數據模型
如果要實現一個支付寶一樣兼具銀行卡、賬戶、理財、分期支付功能的錢包產品呢？這里就要介紹到一戶多卡的模式了。
所謂的一戶多卡，定義如下
1）一戶：
內部的余額賬戶為“戶”，通過一個主賬戶來保障消費者與平臺內商戶基本的消費交易。
2）多卡：
外部合作賬戶被稱為“卡”，當主賬戶余額不足時，系統會自動通過已綁定的銀行卡進行支付。理財賬戶和分期賬戶同樣采用綁定銀行卡的方式進行管理，并且在支付時會跳轉至合作機構的收銀臺以完成交易。
3）兩種清算方式中間科目清算：持牌機構一般通過購買一系列的牌照，實現賬戶、銀行卡、理財、分期產品的合作，需要支付平臺開通多個中間科目來實現金融產品間的清算。合作機構直清：非持牌機構一般與銀行的Ⅱ/Ⅲ類戶、理財賬戶、信貸分期產品合作，銀行給商家提供給直接清算的服務。由于這種模式需要平臺內的商戶去銀行開戶，因此這種模式普遍用于營銷活動當中。
06 三級路由、支付渠道
支付渠道作為外部接入系統，承擔著與銀行及第三方支付平臺進行接口對接的任務。而支付路由則負責通過三級路由機制來選擇最優的支付通道，以確保用戶支付請求能夠順利完成。
6.1、渠道路由因子
渠道的路由因子就是對渠道參數的拆分，通過因子的組合可以形成不同的渠道路由規則，最終來確定一條通道。路由因子主要分為以下三類。
1）基礎因子：對應的是渠道基本信息，通過支付訂單的拆解匹配產品形態和目標機構符合要求的銀行。
2）特性因子：對應渠道的特殊參數，例如維護、交易限額、黑白名單等需要單獨配置的參數，這些因子需要深度的特性匹配，匹配到的渠道實際已經可以支付了。
3）質量因子：對應的是渠道網關，他主要是匹配渠道的運行狀態是否正常，防止渠道異常造成大量的訂單積累。
6.2、渠道集成關系
渠道整體的集成關系由“渠道服務、渠道路由、渠道管理、渠道網關”四部分組成，渠道服務接收來自支付引擎的請求，并將支付請求拆解成路由因子傳遞給“渠道路由”系統，經過三級路由計算后，選中一條支付通道，通過調用渠道網關完成接口的組裝并完成支付。最終支付結果以回調的形式返回，并通知上游系統。
6.3、三級路由流程
分析完渠道設計后，下面我們就把流程、參數和模型進行串聯，以此來了解其上下游的對應關系。
①解析支付訂單，提取路由因子，準備路由。
②判斷路由模式：動態路由則自動篩選渠道；直接路由則獲取渠道號后直接進行第三級路由。
③一級渠道匹配：基于基礎因子篩選符合條件的支付渠道，存入一級列表。
私二級特性匹配：遍歷一級列表中的渠道，檢查其限額、維護期、商戶白名單等特性，符合條件的存入二級列表。
⑤三級網關檢查：檢查支付網關的服務質量（QoS），選擇成功率高且速度快的渠道。
⑥組裝接口并支付：根據選定的渠道組裝接口，完成支付。
07 支付核心
支付核心是支付系統的一組核心服務，他由“支付引擎、賬務核心、資金系統”三部分共同組成，將聯機交易指令、跨行清算資金和本地賬務三者融合，實現信息與資金的轉換。
1）支付引擎：
支付引擎負責提供原子化的支付接口，將交易系統的支付請求轉換支付指令，根據清結算規則，推動信息流的內場記賬和外場清算。
2）賬務核心：
負責內場的記賬和會計賬務處理，賬務核心為了提升性能采用了異步賬務處理的方式，先單邊更新客戶余額，然后異步復試記賬，最后通過內外部客戶賬同步實現一筆聯機賬務的處理。
3）資金系統：
資金系統也叫清結算系統，負責渠道和內部系統的對賬、差錯處理與資金的清算與結轉，驅動賬務核心進行客資結算和總賬核算，實現信息流與資金流的最終一致。
08、內外雙驅、支付引擎
8.1、支付引擎
支付引擎是支付系統的核心驅動器，他對內提供原子化的支付服務，接收來自交易、收銀臺的支付請求；內部通過流程編排、清算協議、清分規則來執行支付指令，并驅動內場賬務核心記賬和外場支付渠道支付。
8.2、支付模型
支付引擎接收來自交易系統的請求，根據接口和產品編碼找到支付入口，按照加載的清算協議和清算規則，并生成支付指令。然后執行設定的服務編排流程，驅動內場的記賬和外場的支付。
- 服務配置：用來設置服務入口和流程配置。
- 清算協議：清算參與的對象和設定單筆或者匯總清算的周期。
- 結算周期：用來設定清算協議按照實時逐筆，還是按照定時匯總的方式進行清算。
- 參與方：用來設定參與方的默認賬號和角色，用以統一配置賬務記賬規則。
- 資金渠道：用來配置不同資金渠道對應的記賬科目。
- 內場規則：按賬套設置賬務核心記賬的賬套和對于的記賬規則。
- 外場規則：設置賬套設置支付渠道請求的支付處理參與。
- 清算場次：一個定時任務，用來設置什么時候開始對賬和清算處理。
8.3、核心流程
支付引擎按照支付模式來編排流程，其中包含了“入款、入款退款、出款、出款退匯”等幾組交易模式。我們這里主要介紹入款和出款兩個核心流程。
1、入款結算流程
收單為入款交易，因此他實時聯機交易先發送到渠道上，支付成功后完成賬務處理。
日終對賬后，根據明細文件更新商戶訂單后給商戶進行軋差結算（收單金額扣減退款金額），根據清算文件進行渠道清算，實現銀存與備付金的平衡。
2、出款結算流程
付款和提現為出款交易，出款交易的特點就是先扣減客戶余額，然后發送渠道。如果成功就將資金結算到渠道清算賬戶；如果失敗則沖正回到客戶賬戶。
日終對賬后，由于付款即結算，因此不需要給客戶結算資金，直接做渠道的付款結轉即可（由于出款是錢離開系統，因此這里要做出款核銷，即渠道清算賬戶和渠道銀存賬戶都扣減掉資金）
09 清算結轉，清結算
9.1、清結算流程
清結算系統主要由資金系統來負責進行對賬和結算處理，他是個業務作業系統，產品架構上本身沒有特別的復雜度，復雜度還是在對賬和清結算的賬務處理。
整個日終流程主要包含三個階段
1）資金對賬：從備付金銀行下載資金清算文件，將其與賬務發生金額進行匯總核對，如果對平做銀存結轉，保障銀存賬戶與備付金期末余額一致。如果沒有對平就下載明細對賬文件進行業務對賬。
2）業務對賬：從每條渠道下載明細對賬文件與入賬明細進行核對，不同則進行差錯處理。渠道全部對平則給客戶結算資金。
3）客資結算：核對每個客戶當日收單與退款的交易明細，跟進成功的訂單將客戶待結算資金轉為可用。
9.2、差錯策略
在清結算對賬中，其實清算、結賬與客資結算是比較固定的，日常維護和新增渠道比較常見的問題是差錯處理。差錯處理跟進訂單中的差錯因子來找到對應的差錯策略。
10 最終一致，賬務核心
賬務核心是支付平臺的賬務的基準。他日間與支付引擎配合記錄聯機交易清算賬務，日終與對賬中心配合處理期末的總賬核算。
10.1、緩沖記賬
日間聯機交易分為內場結算和外場清算，賬務核心負責內場結算賬務的處理。為了實現支付高性能賬務核心采，通過單邊記賬來更新客戶余額，通過異步和緩沖記賬的方式來更新內部戶和客戶月。
其中緩沖記賬是針對集中操作內部戶，或者涉及批量更新客戶賬戶的情況，比如分賬、擔保交易、組合支付等。
這里以即時分賬為例，首先通過單邊記賬扣減付款方余額，然后異步將記賬分錄推送到會計系統保持到分錄流水表，并設置緩存記賬任務。系統定時的根據緩沖任務來進行賬簿的登記和內部戶的更新，同時將結果推送外部客戶賬戶來更新分賬方的余額。
10.2、總賬核算
我們在資金系統中已經介紹了清算結轉，這里我們就介紹期末的總賬核算。
總賬核算是明細賬簿的核算，通過明細賬簿發生額核對，生成賬簿的期末余額，并將明細賬簿按照科目匯總到對應的總賬賬簿上并更新總賬的科目余額。
最后對總賬進行平衡檢查，然后講當日的期末余額更新到歷史表作為下個會計日的期初余額。
最后系統完成會計日切。
本文由人人都是產品經理作者【剛哥】，微信公眾號：【剛哥白話】，原創/授權 發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
- 目前還沒評論，等你發揮！
