0 前言
金融業務都很複雜。我們有可能複用第三方支付既有經驗，解決其他金融業務問題嗎？
和解數學應用題一樣，應對第三方支付這類複雜業務：
- 先分析它裡面的核心原理
- 再嘗試透過核心原理推算出可能規律。這些規律就決定系統架構的演進規律
掌握這些分析問題的方法，碰到其他金融業務問題時就能遊刃有餘。
先搞懂支付涉及核心金融原理，按架構由簡到難，逐步學習點券系統、支付系統和第三方支付公司的支付系統。就能理解支付系統咋遵循核心金融原理，一步步從簡單元件發展到完善系統架構。
1 分離的資訊流與資金流
架構設計要確保架構原理和業務原理一致。
業務原理，支付業務中最核心概念是資訊流與資金流分離：
- 資訊流，想象中錢的流轉過程
- 資金流，錢的實際流轉過程
1.1 案例
假設你（使用者 A）和你朋友（使用者 B）做生意。你銀行賬戶有1塊錢。白天你給朋友轉1塊錢。但你並沒把錢實際轉你朋友，而是給朋友一張字條，記下你轉給你朋友一塊錢。同樣的，你朋友過一會兒也透過字條轉給你一塊錢。在白天你們倆就這麼來回轉來轉去。
到晚上，你和你朋友對白天所有交易，發現你共轉給朋友 51 元，而朋友共需轉50元。
顯然你倆這 50 元可互相抵消。抵消後，你只需給你朋友轉1塊錢。於是你透過銀行將這一塊錢轉給朋友。
1.2 過程示意圖
1.3 分析
你賬上1塊錢在白天一直沒動，這是真實資金，你在白天一直都有這1塊錢所有權。
但白天你和朋友透過紙條將這1塊錢轉來轉去，其實轉移的是這1塊錢的使用權。這種資金使用權的轉移過程就是資訊流。
只有晚上你倆對完賬，並透過銀行轉完賬，這1塊錢所有權才真正屬你朋友。這種資金所有權的轉移過程就是資金流。
本例中用字條轉賬過程就是清算中心每天做的事，最後透過銀行轉賬的過程就是央行在做的事情。
原理只是說資訊流和資金流可分離，通常這兩者也是處在分離態。但它倆不一定需要分離，如實時清算概念，可實時保證資訊流和資金流一致。
現代支付系統普遍採用資訊流和資金流分離，系統架構角度分析會發現：
- 實時清結算對軟體系統吞吐量和延時要求很高
- 同時要求所有參與的支付公司都具有實時清結算能力，任何一家達不到都不行
這就得整個國內和國際金融系統都重新設計系統底層的核心架構。這技術投資並無相應規模的經濟收益支撐，可能也就量化交易能做得起了。
所以，目前支付系統架構設計假設這兩者分離。
1.4 架構設計影響
① 非銀行參與者只產生資訊流
支付環節的非銀行參與者只產生資訊流，不能產生資金流。因大多金融機構並沒有物理現金，紙鈔都放在銀行。
雖資訊流和資金流分開，但它倆最終還是需要同步。同步過程需再次和銀行系統對接，即支付系統需要透過閘道器的形式與外部支付系統進行狀態同步。
② 不同主體分開流轉
資金流和資訊流分開後，這兩者將以不同速度在不同時間的不同主體分開流轉
即支付系統本質是非同步處理系統，資金流和資訊流的統一具有最終一致性（Eventual Consistency）。所以，掃碼支付狀態拉取時，銀行對接是非同步訊息處理的。
③ 資金流和資訊流最終需要同步
即需要一個核算系統來確認同步過程準確無誤。
至此，支付系統架構的核心原理就是內部資訊流系統與外部資金流系統的非同步互動。
咋把原理轉成技術架構？
2 點券系統
點券系統裡，資金流和資訊流是一致的。金融業務最簡單的情況，也是所有相關架構基礎。
點券系統，管理點券的系統。假設只有代金券這一種點券，而且你只能使用代金券來購買產品。
2.1 購買流程
業務系統發起一筆交易單：使用者A用 10 元代金券從使用者 B 購買一支筆。
交易單接著會變成支付單。支付單隻記錄使用者賬號的變動關係，不包含物品交換的關係。即：
- 交易單包括財產交換和物品交換兩種資訊
- 支付訂單隻包含財產交換的資訊
該支付單發給支付系統。支付系統收到後，要對使用者 A 及使用者 B 的代金券賬號處理。
假設最開始使用者 A 持 100 元代金券，使用者 B 持 10 元代金券。購買後，使用者 A 的代金券賬號需減少 10 元代金券，同時使用者 B 的代金券賬號需增加 10 元代金券。
可見，支付過程至少需 3 個系統：
- 業務系統，生成交易單和支付單
- 支付閘道器，負責處理支付單
- 賬務系統，負責維護使用者賬戶情況
2.2 系統架構圖
點券支付：
查詢系統：用代金券支付完成後，使用者可能需要檢查自己的代金券餘額，以及與代金券相關的賬單。
產品體驗角度的不足：使用者 B 不知道自己賬戶收到點券。這時及時通知使用者 B 可能是更合適的產品設計。這時還需一個賬戶變動的通知系統。
假設所有和使用者相關的系統都在業務系統內。更新之後的架構圖：
賬務系統、查詢系統及訊息系統處理的都是使用者的點券資料。資料傳輸除了上圖基於服務的實現，還可直接透過資料庫，即基於資料庫的：
3 電商的支付系統
3.1 背景
現實絕大多數支付業務場景是資金流和資訊流不一致。所以重點是啥樣架構系統，能處理好資訊流與資金流不一致。
電商公司一般無第三方支付牌照，需透過支付系統對接第三方支付公司。我們以支付系統中透過第三方支付完成的銀行卡支付業務為例。
使用者 A 用 10 元錢從使用者 B 那裡購買一支筆。但這次使用者 A 用銀行卡付款，而非點券。
3.2 業務分析
銀行卡是屬於使用者所有的資產，電商公司無權處理。所以銀行卡這資產只能透過第三方支付公司進行操作（其實是透過第三方公司背後的銀行及卡組織）。
第三方公司提供 API 介面都是非同步。非同步介面除成功、失敗態，還有不確定狀態，即點券系統到支付系統的架構演進其實是從同步系統到非同步系統的演進。
按業務流程逐步分析，看基礎的 4 個系統之上，還缺啥功能，要增加啥元件。
業務系統發起一筆支付訂單給支付閘道器：使用者 A 將銀行卡上的 10 元轉給使用者 B。不同在於，支付閘道器收到這筆支付訂單後，需判斷支付系統能否獨立完成資產轉移：
- 點券這種內部資產可內部解決
- 但銀行卡屬使用者，是外部資產，支付系統不能自主解決
所以支付閘道器要實現路由能力，將內部資產和外部資產兩種操作，分發給不同資產處理元件。因此，新增內部、外部資產管理系統元件：
外部資產管理系統需對接第三方支付公司來完成銀行卡轉賬業務。這個對接任務透過金融閘道器來實現。金融閘道器主要是實現二進位制協議的對接，如證書籤名、加解密、協議傳輸、資料校驗等。
金融閘道器會對接多家第三方支付公司或銀：
- 當一家支付公司臨時連線不上，可切換到下一家
- 或當一家支付公司費率相對較優時，可臨時切換
選擇哪家支付公司對接的過程也叫路由，透過當前情況智慧選擇路由的過程叫智慧路由。因此，架構圖新增金融閘道器服務：
金融閘道器和第三方支付公司之間是非同步通訊協議。非同步通訊有額外的不確定狀態，架構上咋處理？不確定狀態處理方法分兩步：
- 規定時間內重複查詢支付狀態，一般把這種行為叫作輪詢。如使用者 App 透過輪詢來獲取支付狀態
- 規定時間內輪詢若失敗，支付過程並不一定失敗，有補救機會。每天晚上電商公司會有一個與第三方機構進行對賬機會，在這時雙方會對白天所有互動明細進行對比，查漏補缺
這就是非同步系統對接時的架構設計原則，需將同步系統的一次呼叫拆分成三個步驟：非同步呼叫、輪詢和對賬。
- 電商支付系統的外部資產管理系統處理的是資訊流
- 金融閘道器對接的第三方支付公司處理的是資金流
資訊流和資金流分離後，兩者狀態就不再一致。
所以從資訊流系統角度，資金流系統會存在不確定狀態，這就是為啥除了成功和失敗，會出現第三種狀態。資訊流和資金流雖分開，最終還是需要同步，因此要透過輪詢、對賬兩種方式實現同步。
這就是由支付業務原理所推匯出的系統架構設計原理。
最後還要把剩下的一些關鍵元件補充完整。發現架構圖無法儲存資訊流相關資訊，所以也無法處理和資金流的同步。
資訊流是透過記賬儲存，因此要加回賬務系統。這賬務系統和點券系統的賬務系統功能類似，但覆蓋面不同。
3.3 更新後架構圖
如輪詢失敗，需在晚上與第三方支付公司對賬。對賬任務一般由核算系統完成。除了和第三方公司進行對賬，核算系統還要核對賬務系統與業務系統之間的一致性關係。
新增核算系統的架構圖：
至此，基本滿足電商公司日常支付需求。
4 第三方支付系統
第三方支付系統和電商公司的支付系統的核心元件都差不多，主要因為它倆都不能管理實際資金，因此都是資訊流的處理系統。
電商公司透過支付系統，將資訊流交給第三方支付系統處理。第三方支付系統會將這資訊流再轉交給銀行處理。在做跨境交易的時候我們甚至還能看到不同國家第三方支付公司之間的彼此合作。
相同地方不復述，這重點講三點不同：流量支援、資金池和清算系統。
4.1 系統的流量支援
第三方支付公司有很多家客戶，可能面臨非常大的支付流量，如：
- 第三方支付公司負責代發工資或代繳水電費，一到月底就面臨大流量
- 除了可預測的高流量，第三方支付公司還面臨電商大促這種突然高支付流量
所以第三方支付公司要有能力處理這種常見的網際網路應用高併發問題。這就是金融系統架構和網際網路架構結合好的地方。應對高併發場景，網際網路有成熟解決方案。如非同步訊息處理，就能削峰填谷，降低峰值流量壓力。
如流量再高，還可選擇熔斷降流等手段進行服務降級。如儲存能力支撐不了這麼高流量，還可用各種不同快取技術降低查詢操作對資料庫的壓力或分庫分表進一步降低每個資料庫的壓力。
4.2 備付金資金池
第三方支付公司在呼叫銀行介面的時候會產生費用。咋利用備付金資金池：
- 減少交易費用
- 同時提高使用者體驗
資金池，一種常見的使用者資金管理手段，將屬於使用者的錢都放在一個大池子。池子裡的錢不分你我，你是將資金池看作一個整體來操作。但你還留個賬本，上面記載每個人原來在資金池裡放多少錢。這樣雖然錢混在一起，但賬面上清楚。
資金池有很大的資金挪用風險，因此金融業對資金池設立有嚴格監管。有支付牌照，第三方公司才可建立使用者的備付金資金池，一種新的金融產品，因此也需要新的系統元件支援。
例
第三方支付公司 App 時常見的餘額或錢包。你可將銀行卡里的錢轉到餘額賬戶。之後就可直接使用餘額裡的錢。但第三方支付公司並不一定會將你和我的餘額分開儲存，很可能放在一個資金池。
如下圖展示一種資金池管理方式。ABCD 四個使用者在第三方支付公司都有自己的餘額賬戶。但是這 4 個餘額賬戶並不是實際存在的，只是 4 個虛擬賬戶而已。真正的錢其實還是存在第三方支付公司在銀行的賬號裡。
第二個例子是第一個例子的升級版。外匯市場是一個個有層級的市場。資金池也一樣，多個資金池也可拼成一個更大資金池。於是第三方支付公司可在多家銀行開設很多資金池賬戶，所有這些資金池賬戶的錢形成更大的資金池（監管機構正在逐步限制這種行為）。
當把資金池分散在多家銀行之後，第三方支付公司就不再受制於單獨某家銀行。這樣就可以利用不同銀行的費率情況來進一步降低運營成本。
如跨行轉賬需要多家銀行之間配合，還可能需要支付一定的跨行交易費用。但是如果第三方支付公司在每家銀行都有資金池，就可以直接在兩家銀行內部完成使用者資金和資金池資金之間的操作了。
利用資金池來最佳化跨行轉賬的例子也有升級版。在進行跨境貿易的時候也可以使用多個資金池來降低交易成本，但這不是主要原因。跨境轉賬一個不太友好的問題是時間非常久，需要好幾天才能到賬。這時候如果你在每家銀行都有資金池賬號，跨境轉賬問題就變成多個銀行內部轉賬的問題了，這樣就能實時到賬，大幅提升使用者體驗。
備付金資金池要求賬務系統有層級式的賬戶體系，並且有相應的賬戶和資金操作。升級版的資金池看起來是下圖這個樣子：
4.3 清結算能力
清結算中心處理的是多家銀行之間的跨行轉賬。當第三方支付公司有了多個資金池之後，這些資金池之間的轉賬關係其實和跨行轉賬一樣。既然是一樣的，那麼第三方支付公司有沒有可能做一些清算公司的事情，從而進一步降低交易成本呢？
的確如此。所以成熟的第三方支付公司內部都會有一個自己的清算中心。這個清算中心把自己當作一個外人，對資金池之間的轉賬交易進行清結算工作。這裡要注意清算中心的結算過程涉及到資金流操作，需要透過內部支付閘道器來操作外部資金。
這樣我們就把第三方支付公司最後一個元件補完了。現在架構圖：
跨銀行備付金和清算中心合在一起後，第三方支付機構就具備了跨行清算的能力。由於這種業務模式不容易監管，容易出現洗錢等非法行為，國家已經逐步取消了這種資金管理模式。
但是清算中心這個元件還是保留了下來。儘管不能再進行跨行清算，不過有了清算中心之後就有了清算的概念，這讓一些常見的內部資訊流和資金流處理的方式變得更加清晰。
該例表明，由於監管條例完善，支付業務和系統架構也要改變。如你在歐洲從事第三方支付業務，很可能會碰到歐盟制定的“通用資料保護條例”，要求你對系統架構的資訊儲存做進一步劃分。因此設計支付系統要根據當地監管條例合理選擇架構。
5 總結
本文梳理支付業務邏輯，最終推匯出 C 端支付核心元件。
C 端支付需解決核心問題是資訊流與資金流分離。先分析最簡單點券系統，這種系統資訊流與資金流不分離。點券系統需要賬務系統來對點券這種資產進行管理，使用者需要透過支付閘道器來對接點券系統。
資金流與資訊流分離的系統又是啥樣？電商的支付系統就很有啟發性。點券系統需要處理的同步訊息，支付系統則需要處理非同步訊息。所以支付系統除了需要複用點券系統的核心元件外，還需要核算系統來保證非同步訊息的正確處理。
有前面基礎，再分析第三方支付系統的核心元件就容易。第三方支付在業務上需要用資金池來降低業務成本，因此在架構上需要有核心元件來對資金池進行操作，同時也需要用清算中心來簡化資金池操作的最佳化管理。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！