二、架構實戰——支付流程詳解

一、掃碼支付

  1. 掃碼

(1) 用戶掃碼

    掃二維碼支付顯然是以用戶掃碼作爲整個業務的起點。從終端用戶的角度來看，掃碼由鑑權、支付和拉取狀態三個步驟組成。

(2) 鑑權

    掃碼支付最終會用買家的銀行卡進行支付。在你開始掃碼支付之前，第三方公司需要覈實你是否有這張卡的使用權，俗稱 “綁卡”。那第三方公司是怎麼驗證用戶的使用權呢？在國內，一般採用下面這 4 個要素來進行驗證：

    這 4 個要素都是銀行記錄的信息，因此雖然看起來你是在第三方支付公司的 App 上進行綁卡操作，其實是銀行在背後進行相關信息的驗證工作。由於這 4 個要素都是電子信息，可能會被人盜用，所以爲了進一步增強安全性，銀行在驗證手機號碼的時候還需要驗證你是否擁有這個手機號碼。具體的方式是發一條驗證碼給在你在銀行櫃檯辦借記卡時註冊的手機號碼。結合前面的內容，我們可以把鑑權的過程分爲 4 步：

所以鑑權的過程其實是驗證了 5 個信息，其中 4 個是靜態信息，1 個是動態信息。在用戶綁卡通過之後，銀行會返回給第三方支付公司這個用戶的內部 ID 信息（也叫 Token）。之後第三方支付公司就可以拿這個 ID 進行所有合法的操作。

(3) 支付

    鑑權完成之後，就可以掃二維碼，進行支付了。二維碼其實是一個圖形化的字符串，背後是這筆交易對應的訂單。當用戶點擊 “確認” 之後，就會開始整個支付流程。

(4) 拉取支付狀態

    那爲什麼需要拉取支付狀態呢？用戶 App 的支付確認按鈕是有侷限的，它只能確認後臺是否已經收到了支付請求，並不能確認支付是否已經成功。這是因爲支付後臺需要花一些時間和銀行溝通，在這個期間後臺並不知道銀行的支付流程進行到了哪一步。由於不知道支付什麼時候才能完成，用戶 App 需要每隔一段時間就向支付後臺拉取交易情況，通常會把這個過程叫作輪詢。這個過程一般在幾百毫秒內就能結束，所以你一般察覺不到延時。 

    那爲什麼會出現輪詢這種系統對接方式呢？金融機構每天會面對大量的用戶資金操作，這些操作的時間和頻率有很大的偶然性。爲了應對用戶操作的峯值情況，金融機構普遍通過異步消息處理的架構來對極端流量進行削峯填谷。如果流量突然增大，異步消息架構會緩存所有請求，慢慢處理。這樣就能避免核心金融系統超載。異步消息架構的結果就是用戶不會及時得到處理結果，需要自己不斷地去查詢處理情況。

    當銀行處理完支付後，銀行會把支付成功的消息推送給用戶和第三方支付公司。第三方支付公司也會推送給你支付成功的消息。所以你在掃碼支付成功後，通常還能聽到兩個手機消息通知的聲音。到這裏我們看到了兩種不同的獲取最新狀態的方式。一種是用戶定期去拉取狀態，另一種是服務器將狀態消息實時推送給用戶。這種推拉結合的消息通知方式，其實是架構設計中常見的異步系統處理方式。

  1. 跨行本幣代收

    本幣代收，也就是第三方支付公司代收用戶資金。簡單來說本幣代收就是將你該付的錢先打到第三方支付公司賬上。由於第三方支付公司的賬號和買家的銀行卡在兩家不同的銀行，本幣代收需要進行跨行轉賬。跨行轉賬會涉及到整個銀行系統的大小額系統和超級網銀等。

(1) 央行和清算機構 

    跨行轉賬的時候，錢是在不同的銀行。因此想要實現跨行轉賬，就需要解決兩個問題。第一個問題是怎麼將錢在兩家銀行之間轉來轉去，另一個問題是轉的金額是多少。先看第一個問題，那就是怎麼跨行搬錢。最直接的方法是用汽車將錢從一家銀行的金庫搬到另一家銀行。但這個方法其實不太實用，汽車能運的錢重量有限，路上也不太安全。所以錢最好不要挪動地方。 

    這時候又需要另一個第三方機構出馬了。所有銀行都在這個新的第三方機構裏放足夠多的錢，一般叫做存款準備金。當兩家銀行之間需要轉賬的時候，第三方機構在內部搬運一下就好。比如美國的黃金交易所就是這種工作模式，每個客戶都有自己專屬的黃金倉庫，很多小車在倉庫之間搬運黃金。 

    如果這個第三方機構足夠可信，那麼連內部搬運都不需要。這個第三方機構只需要記錄一下誰的錢有多少，以及從哪裏搬了多少到另一個地方就行。信用級別最高的金融機構就是國家的中央銀行，簡稱央行。所以央行解決了真實資金的轉移問題。 

    再來看另一個問題，那就是怎麼知道轉移的金額有多少。會有這個問題的原因是每天銀行之間的跨行交易非常多，不可能每一筆都通過央行轉一次錢。所以銀行系統對跨行轉賬的流程進行了優化。那就是在白天只做記錄，不進行任何實質性的跨行轉賬。等每天結束的時候計算一下兩個銀行之間交易金額的差額是多少，最後通過央行進行一筆跨行轉賬就可以了。這種計算交易差額的方式叫做軋差。這個記錄白天跨行轉賬細節和晚上進行交易軋差的第三方機構叫作清算機構。你熟悉的銀聯及網聯，以及國外的萬事達，它們都是清算機構。

    軋差是另一種金融機構應對大流量的一種處理方式。軋差的本質是實時消息的批量處理，從某種程度來講是延時更大的異步處理框架。

(2) 跨行轉賬流程

二、支付涉及的核心金融原理

  1. 信息流與資金流分離

    在支付業務中最核心的概念是信息流與資金流分離。用一句話來概括，信息流指的是想象中錢的流轉過程，資金流指的是錢的實際流轉過程。

假設你（用戶 A）和你的朋友（用戶 B）做生意。你的銀行賬戶裏有一塊錢。白天的時候，你給你朋友轉了一塊錢。但是你並沒有把錢實際轉給你朋友，而是給你朋友一張字條，上面記下了你轉給你朋友一塊錢。同樣的，你朋友過了一會兒也通過字條轉回給了你一塊錢。在白天你們倆就這麼來回轉來轉去。到了晚上你和你朋友對了一下白天所有的交易，發現你一共要轉給你朋友 51 元，而你朋友一共需要轉給你 50 元。顯然你們倆之間的這 50 元是可以互相抵消掉的。抵消之後，你只需要給你朋友轉一塊錢就行。於是你通過銀行將這一塊錢轉給了你朋友。過程示意圖如下

    你賬上的一塊錢在白天的時候一直沒動。這一塊錢是真實的資金，你在白天的時候一直都有這一塊錢的所有權。但是在白天你和朋友通過紙條的形式將這一塊錢來回轉來轉去，這個過程其實轉移的是這一塊錢的使用權。這種資金使用權的轉移過程就是信息流。只有晚上你們倆對完賬，並通過銀行轉完賬之後，這一塊錢的所有權才真正屬於你朋友。這種資金所有權的轉移過程就是資金流。 

    這個例子中用字條轉賬的過程就是清算中心每天做的事情，最後通過銀行轉賬的過程就是央行在做的事情。當然了，原理只是說信息流和資金流可以分離，通常這兩者也是處在分離的狀態。但是它 們倆不一定需要分離，比如有個實時清算的概念，可以實時保證信息流和資金流一致。現代支付系統中普遍採用了信息流和資金流分離的做法，這裏的原因有很多。如果從系統架構的角度分析，會發現，實時清結算對軟件系統的吞吐量和延時要求非常高，同時還要求所有參與的支付公司都具有實時清結算能力，任何一家達不到都不行。 

    這樣一來，就需要整個國內和國際金融系統都重新設計系統底層的核心架構。短期來說，這麼巨大的技術投資並沒有相應規模的經濟收益作爲支撐。所以，目前在支付系統架構設計中需要假設這兩者是分離的。再來看看它會給架構設計帶來哪些影響。主要有以下三點：

  1. 點券系統

    在點券系統裏資金流和信息流是一致的。這是金融業務最簡單的情況，也是所有相關架構的基礎。顧名思義，點券系統就是管理點券的系統。在這裏對點券業務和系統做一些簡化。現在假設只有代金券這一種點券，而且只能使用代金券來購買產品。 

    具體的購買流程是這樣的。首先，業務系統需要發起一筆交易訂單：用戶 A 用 10 元的代金券從用戶 B 購買一支筆。交易訂單接下來會變成支付訂單。支付訂單隻記錄了用戶賬號的變動關係，不包含物品交換的關係。簡單來說，交易訂單包括財產交換和物品交換兩種信息，支付訂單隻包含財產交換的信息。 

    這筆支付訂單會發給支付系統。支付系統在收到這筆支付訂單後，需要對用戶 A 及用戶 B 的代金券賬號進行處理。假設最開始用戶 A 擁有 100 元代金券，用戶 B 擁有 10 元代金券。那麼在購買後，用戶 A 的代金券賬號需要減少 10 元的代金券，同時用戶 B 的代金券賬號需要增加 10 元的代金券。 到目前爲止可以看到，支付過程至少需要 3 個系統：

    在用代金券支付完成後，用戶可能需要檢查自己的代金券餘額，以及與代金券相關的賬單。所以還需要一個查詢系統來完成相關的查詢。另外從產品體驗角度看，現在的系統還有一點不足：用戶 B 並不知道自己賬戶收到了點券。這時候及時通知用戶 B 可能是一個更合適的產品設計。這時還需要一個賬戶變動的通知系統。通知系統通常採用異步通知的方式。

    賬務系統、查詢系統以及消息系統處理的都是用戶的點券數據。很顯然，數據傳輸除了上圖這種基於服務的實現方式外，還可以直接通過數據庫。所以在實現的時候有兩種不同選擇，如下圖所示：

  1. 支付系統

    現實中，絕大多數支付業務場景是資金流和信息流不一致的情況。所以必須知道，什麼樣的架構系統，才能處理好信息流與資金流不一致的情況。 信息流是通過記賬方式來保存的，因此還要加回賬務系統。這個賬務系統和點券系統的賬務系統功能類似，但是覆蓋面不同。更新後的架構圖如下：

    如果輪詢失敗，需要在晚上與第三方支付公司進行對賬。這個對賬的任務一般是由覈算系統來完成的。除了和第三方公司進行對賬之外，覈算系統還需要覈對賬務系統與業務系統之間的一致性關係。添加了覈算系統的架構圖如下：

  1. 第三方支付系統

    第三方支付系統和電商公司的支付系統的核心組件都差不多，主要是因爲它們倆都不能管理實際資金，因此都是信息流的處理系統。電商公司會通過支付系統將信息流交給第三方支付系統處理。第三方支付系統會將這個信息流再轉交給銀行處理。在做跨境交易的時候我們甚至還能看到不同國家第三方支付公司之間的彼此合作。有三點不同，分別是流量支持、資金池和清算系統。

(1) 系統的流量支持

    第三方支付公司有很多家客戶，有可能會面臨非常大的支付流量。舉個例子，比如第三方支付公司負責代發工資或者代繳水電費，一到月底就會面臨非常大的流量。除了這些可以預測的高流量外，第三方支付公司還可能會面臨電商促銷這種非常突然的高支付流量。所以第三方支付公司需要有能力處理這種常見的互聯網應用高併發問題。

(2) 備付金資金池

    第三方支付公司在調用銀行接口的時候會產生費用。如何利用備付金資金池減少一些交易費用，同時還能提高用戶體驗。資金池是一種常見的用戶資金管理手段。

    資金池就是將屬於用戶的錢都放在一個大的池子裏。池子裏的錢不分你我，你是將資金池看作一個整體來操作的。但是你還留着一個賬本，上面記載了每個人原來在資金池裏放了多少錢。這樣雖然錢是混在一起，但是賬面上是清楚的。 資金池有很大的資金挪用風險，因此金融業對資金池的設立有很嚴格的監管。一般有了支付牌照之後，第三方公司纔可以建立用戶的備付金資金池。備付金資金池是一種新的金融產品，因此也需要新的系統組件來支持。下面舉兩個簡單的例子。 

    你在用第三方支付公司 App 的時候應該見過一種叫作餘額或者錢包的東西。你可以將銀行卡里的錢轉到餘額賬戶。之後就可以直接使用餘額裏的錢。但是第三方支付公司並不一定會將你和我的餘額分開存儲，很有可能是放在一個資金池裏處理。

    比如下圖展示了一種資金池的管理方式。ABCD 四個用戶在第三方支付公司都有自己的餘額賬戶。但是這 4 個餘額賬戶並不是實際存在的，只是 4 個虛擬賬戶而已。真正的錢其實還是存在第三方支付公司在銀行的賬號裏。

    第二個例子是第一個例子的升級版。多個資金池也可以拼成一個更大的資金池。於是第三方支付公司可以在多家銀行開設很多資金池賬戶，所有這些資金池賬戶的錢形成更大的資金池（監管機構正在逐步限制這種行爲）。當把資金池分散在多家銀行之後，第三方支付公司就不再受制於單獨某家銀行。這樣就可以利用不同銀行的費率情況來進一步降低運營成本。 

    舉個例子，比如跨行轉賬需要多家銀行之間配合，還可能需要支付一定的跨行交易費用。但是如果第三方支付公司在每家銀行都有資金池，就可以直接在兩家銀行內部完成用戶資金和資金池資金之間的操作了。

利用資金池來優化跨行轉賬的例子也有升級版。在進行跨境貿易的時候也可以使用多個資金池來降低交易成本，但這不是主要原因。跨境轉賬一個不太友好的問題是時間非常久，需要好幾天才能到賬。這時候如果你在每家銀行都有資金池賬號，跨境轉賬問題就變成多個銀行內部轉賬的問題了，這樣就能實時到賬，大幅提升用戶體驗。備付金資金池要求賬務系統有層級式的賬戶體系，並且有相應的賬戶和資金操作。升級版的資金池看起來是下圖這個樣子：

(3) 清結算能力

    清結算中心處理的是多家銀行之間的跨行轉賬。當第三方支付公司有了多個資金池之後，這些資金池之間的轉賬關係其實和跨行轉賬一樣。既然是一樣的，那麼第三方支付公司有沒有可能做一些清算公司的事情，從而進一步降低交易成本呢？ 成熟的第三方支付公司內部都會有一個自己的清算中心。這個清算中心把自己當作一個外人，對資金池之間的轉賬交易進行清結算工作。這裏要注意清算中心的結算過程涉及到資金流操作，需要通過內部支付網關來操作外部資金。

    跨銀行備付金和清算中心合在一起後，第三方支付機構就具備了跨行清算的能力。由於這種業務模式不容易監管，容易出現洗錢等非法行爲，國家已經逐步取消了這種資金管理模式。 但是清算中心這個組件還是保留了下來。儘管不能再進行跨行清算，不過有了清算中心之後就有了清算的概念，這讓一些常見的內部信息流和資金流處理的方式變得更加清晰。由於監管條例在不斷完善，支付業務和系統架構也要隨之改變。比如你在歐洲從事第三方支付業務的時候，很有可能會碰到歐盟制定的 “通用數據保護條例”，這就要求你對系統架構的信息存儲做進一步的劃分。因此我們在設計支付系統的時候，需要根據當時當地的監管條例合理選擇架構。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3A80iAvlg4Ig8fIS-7VGnQ

猜你喜歡