1 金融業務
業務模式劃分：
-
交易類業務，如掃碼支付
-
信貸類業務
掃碼支付普遍但不簡單：
-
掃碼支付是最具代表性，最常見的金融場景
-
傳統銀行業務的標誌性機構大多參與到掃碼支付過程，可透過掃碼支付了解國家金融系統運作
-
掃碼業務同時具有網際網路應用和機構應用的技術特點：既要對接網際網路使用者，也要對接金融機構
2 案例背景
掃碼支付分場景，選擇與跨境電商相關的掃碼跨境支付場景，假設：
- 付款方使用者支付人民幣
- 付款方的簽帳金融卡是國內銀行A發行，簡稱【買家開戶行】
- 第三方支付公司的備付金賬戶在國內銀行B，簡稱【第三方開戶行】
- 收款方接受的美元
- 收款方的簽帳金融卡是國外銀行C發行的，簡稱【賣家開戶行】
- 第三方公司是透過銀行D進行外幣兌換業務，簡稱【匯兌提供行】
國內對人民幣相關的外匯交易有管制，本外幣交易需滿足一定要求，如要求電商平臺有對應交易明細。假設已都合規。
支付過程：使用者掃碼支付、第三方公司進行本幣代收、外匯交易及外幣代付。
3 使用者掃碼
掃碼支付以使用者掃碼作為整個業務起點。終端使用者角度，掃碼由鑑權、支付和拉取狀態三步。
3.1 鑑權
掃碼支付最終會用買家銀行卡支付。開始掃碼支付前，第三方公司要核實你是否有卡使用權，即“綁卡”。
3.1.1 第三方公司咋驗證使用者的使用權
① 4要素驗證
- 使用者姓名
- 使用者身份證號碼
- 銀行卡號碼
- 銀行註冊的手機號
都是銀行記錄的資訊，因此雖然看起來你是在第三方支付公司的App綁卡，其實是銀行在背後進行相關資訊驗證（隱式驗證）。
都是電子資訊，可能盜用（手機號也可能轉移使用者），為安全，銀行驗證手機號時，還驗證你是否擁有這手機號：發驗證碼到你在銀行櫃檯辦簽帳金融卡時註冊的手機號。
② 鑑權過程
- 使用者填寫前3要素和手機號
- 銀行發簡訊驗證碼給使用者手機號
- 使用者將前3要素和簡訊驗證碼發給第三方支付公司
- 第三方支付公司再將所有資訊傳送給銀行確認
即驗證5個資訊：4個靜態，1個動態資訊。
使用者綁卡透過後，銀行返給第三方支付公司這個使用者的內部ID資訊（Token）。之後第三方支付公司就可拿這ID進行所有合法操作。
③ 流程示意圖
3.2 支付
鑑權完成後，就能掃碼支付。
二維碼是圖形化字串，背後是這筆交易對應的訂單。當使用者點選“確認”後，就開始整個支付流程。
3.3 拉取支付狀態
系統功能角度，使用者APP的支付確認按鈕有侷限，它只能確認後臺是否已收到支付請求，不能確認支付是否已成功。因為支付後臺需花時間和銀行溝通，期間後臺不知銀行的支付流程到哪步了。
因不知支付啥時完成，所以使用者App需每隔段時間向支付後臺拉取交易情況，即輪詢。這過程一般幾百ms結束，所以一般察覺不到延時。
3.3.1 為啥輪詢？
金融機構每天面對大量的使用者資金操作，操作時間、頻率有很大偶然性。為應對使用者操作峰值，金融機構普遍透過非同步訊息處理架構對極端流量削峰填谷。若流量突增，非同步訊息架構會快取所有請求，慢慢處理，避免核心金融系統超載。因此，使用者不會及時得到處理結果，需不斷查詢處理情況。
銀行處理完支付後：
- 銀行把支付成功訊息推給使用者、第三方支付公司
- 第三方支付公司也推給你支付成功訊息
所以掃碼支付成功後，會聽到兩個手機訊息通知的聲音。
3.3.2 獲取最新狀態
兩種方案：
- 使用者定期去拉取
- 伺服器將狀態訊息實時推給使用者
推拉結合，是非同步系統常見處理方式。
① 支付狀態獲取的流程圖
4 本幣代收
假設支付涉及外匯交易，由於買、賣家幣種不同，無法直接轉賬。需第三方支付公司這中間人幫忙。中間人要執行：
- 本幣代收
- 外匯交易
- 外幣代付
本幣代收，即第三方支付公司代收使用者資金，即將你該付錢先打到第三方支付公司賬上。
由於第三方支付公司賬號和買家銀行卡在兩家不同銀行，本幣代收需跨行轉賬。跨行轉賬涉及整個銀行系統的大小額系統和超級網銀等。
4.1 央行和清算機構
跨行轉賬時，錢在不同銀行，需考慮：
① 咋跨行搬錢？
最直接的，用汽車將錢從一家銀行金庫搬到另一家銀行。不太實用，汽車能運的錢重量有限，路上也不安全，錢最好別挪地方。
就需另一第三方機構。所有銀行都在這該新第三方機構放夠多錢：存款準備金。當兩家銀行需轉賬，第三方機構在內部搬運下即可。如美國黃金交易所，每個客戶都有自己專屬的黃金倉庫，很多小車在倉庫之間搬運黃金。
若該第三方機構夠可信，連內部搬運都不需要。第三方機構只需記錄誰的錢有多少及從哪裡搬了多少到另一個地方。信用級別最高的金融機構即國家的中央銀行-央行。所以央行解決真實資金的轉移問題。
② 轉多少
每天銀行之間的跨行交易非常多，不可能每筆都透過央行轉錢。所以銀行系統對跨行轉賬的流程最佳化：
- 白天只做記錄，不進行任何實質性的跨行轉賬
- 每天結束時，計算兩個銀行之間交易金額的差額，最後透過央行進行一筆跨行轉賬
這種計算交易差額的方式叫軋差。
記錄白天跨行轉賬細節、晚上進行交易軋差的第三方機構叫清算機構。銀聯及網聯及國外的萬事達都是清算機構。
金融系統採用非同步訊息處理架構應對支付流量。軋差則是另一種金融機構應對大流量的一種處理方式。軋差本質是實時訊息的批處理，算是延時更大的非同步處理框架。
4.2 跨行轉賬流程
- 第三方支付公司發指令給第三方開戶行，要求將錢從使用者的買家開戶行轉到第三方開戶行
- 第三方支付公司擁有使用者在買家開戶行的Token（綁卡獲得），所以可合法發起這筆轉賬。跨行轉賬流程開始
- 第三方開戶行將所有資訊交給清算機構。清算機構作為第三方負責記錄這些資訊，並通知買家開戶行、第三方開戶行記錄這筆轉賬
- 買家開戶行記錄的結果是對使用者的賬號進行扣款。扣款結束後用簡訊通知使用者
- 第三方開戶行記錄的結果是對第三方支付公司的賬號進行打款。打款結束後第三方支付公司可以透過銀行網頁看到對公賬戶金額髮生變化。白天工作結束。此時買家開戶行的賬面上的資金雖然減少，但是減少的錢並沒有實質性到達第三方開戶行
- 晚上，清算機構對白天發生的交易進行盤存，發現有一筆從買家開戶行到第三方開戶行的跨行轉賬還沒有真正完成。清算機構會將這筆未完成的跨行轉賬資訊發給央行
- 最後，央行收到資訊後，將買家開戶行在央行的存款準備金調低，並將第三方開戶行在央行的存款準備金調高。錢就真正從買家開戶行轉到第三方開戶行
5 外匯交易
轉賬交易第二步是第三方支付公司進行外匯交易。當第三方支付公司完成使用者本幣代扣，第三方支付公司賬上就有對應人民幣。
將這些人民幣變成美元，才能將美元轉給國外賣家。外匯交易過程按交易量分為：
- C端外匯零售業務
- B端外匯批發業務
5.1 C端外匯零售業務
外匯交易和電商一樣，也是買賣。第三方支付公司作為中間人，用人民幣購買美元。
美元從哪買？
人民幣有外匯管制，不能隨意買賣，需透過有資質的銀行。若外匯不涉及人民幣，則選擇面寬泛很多，銀行、投行或其他金融機構都可。
賬務原理建議一個賬號只處理同一個幣種交易。外匯交易涉及到兩個幣種，需兩個不同賬號。
假設第三方支付公司透過匯兌提供行進行外匯交易。那第三方公司要在匯兌提供行裡建兩個賬號：
- 人民幣賬號
- 美元賬號
同時，匯兌提供行內部也要有對應兩個幣種賬號，對應：
- 人民幣資金池
- 美元資金池
所以，一筆外幣購買涉及4個賬號之間的2筆支付訂單。
交易過程示意圖
外匯交易完成後，第三方支付公司在匯兌提供行的人民幣賬戶金額減少，美元賬戶金額增加。這樣第三方支付公司就有足夠的美元支付給賣家。
外匯交易有成本：
- 時間成本：當天購買的外匯可能隔天才到賬
- 交易成本：外匯交易一般按交易次數收費。為節省成本，第三方支付公司通常提前購買大量外匯以應對日間業務。只有當外匯儲備下降到警戒線，再做下一筆大額外匯購買
這就解決第三方支付公司美元賬戶不足問題，但是它用來購匯的人民幣賬戶一直在往外出錢，總有枯竭一天，咋辦。
所以還需考慮從外部調資金進來。第三方支付公司的備付金賬戶在第三方開戶行，因此要做從第三方開戶行到匯兌提供行的跨行轉賬：
但第三方公司在第三方開戶行的賬戶也在一直出錢，第三方開戶行賬戶也要有進來資金的渠道。這是由本幣代收的過程實現。把買家出資的流程補充完整：
匯兌提供行幫第三方支付公司實現外匯購買。但匯兌提供行的美元賬戶一直在出錢。這美元賬戶錢不夠咋辦？這時，匯兌提供行需從其他銀行尋求幫助。這就涉及B端外匯批發交易。
5.2 B端外匯批發業務
前面電商相關的外匯交易屬於外匯的零售業務。
銀行、投行和其他外匯提供商間形成有層級的跨國組織，專門從事外匯的批發業務。批發業務的業務量非常巨大，通常每天都有幾萬億美元規模。
外匯市場按交易量分層
- 最底層是面對終端使用者的外匯零售商。這些零售商負責給一般使用者提供小額外匯交易。這些小筆外匯交易彙集後，就形成一筆大的外匯訂單，然後繼續往上層交易
- 和底層外匯零售商一樣，上層機構將所有外匯交易彙集後，形成更大外匯訂單，再往更上層交易
- 一直往上彙集流程盡頭是全球最大的外匯做市商，一般是巨型的跨國商業銀行
這些跨國商業銀行面對全球不同國家大量的儲蓄使用者，所以它們有不同幣種鉅額存款。這些做市商之間透過交換不同幣種的大額固定利息存摺來實現外匯交易，從而決定最終匯率：
外匯交易有時間成本，當天購買外匯需隔天到賬。這一天時間間隔內，外匯市場可能巨大波動，造成金融機構賬面上的資金虧損。所以，參與外匯業務的金融機構都會處理外匯相關的市場風險，如用期貨、期權等衍生品來對沖風險。
5.3 至此的流程示意圖
6 外幣代付
和本幣代收流程在原則上一樣。不同在於外幣代付的金額是美元，流出賬號是第三方支付公司的美元賬號。由於賣家的賬號在賣家開戶行，第三方支付的美元賬號在匯兌提供行，這時要走國際的清結算過程。流程核心思想類似，只是細節更復雜。
7 總結
使用者在掃碼支付前需要證明自己合法擁有銀行卡，要給開卡行提供4要素：姓名、身份證、銀行卡號和手機號。驗證透過後便可以開始支付流程。支付完成後使用者可透過輪詢非同步獲取支付狀態。非同步處理是金融機構應對支付流量的一種架構設計。
在第三方支付公司收到支付請求後，開始進行本幣代收業務。由於賬號設立的關係，需要進行跨行轉賬。此時清算中心和央行一起提供了跨行轉賬功能。跨行轉賬一般採用了日間交易、日終軋差結算的方式進行。軋差處理是金融機構應對支付流量的另一種架構設計。
第三方支付公司在完成本幣代收業務之後，還要進行匯兌業務，具體分為外匯零售業務和批發業務。如果涉及外幣代付業務，第三方支付公司還需要藉助國際清結算組織的相關功能。
二維碼支付涉及的大多數環節都是非同步系統，比如使用者App的非同步支付狀態查詢，以及清算中心和央行及銀行之間的跨行轉賬清結算過程。非同步系統不會將結果同步返回給呼叫方。因此，我們在設計系統的時候，就需要支援狀態的查詢以及狀態訊息的推送功能。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！