作者：李艷鵬，現任螞蟻金服高級技術專家，著有《分布式服務架構：原理、設計與實戰》和《可伸縮服務架構：框架與中間件》，曾經在易寶支付、花旗銀行、甲骨文、新浪微博、路透社等大型IT互聯網公司擔任技術負責人和首席架構師的工作，現專註於區塊鏈平臺的研發與推廣，擅長大規模高並發的線上與線下相結合的第三方支付平臺的架構規劃與實施。

在金融支付行業，資金底線的打法是至關重要的，保證資金不發生損失是任何一家金融支付行業的第一要務，這也是最困難的一個任務之一，一家支付公司每天的支付流水就有幾億、十幾億，甚至幾十億到上百億、上千億都屢見不鮮，在這樣大的資金流水面前，我們應該如何保證資金萬無一失呢？

大家應該都聽過騎士資本（Knight Capital）的故事，這家美國股市經紀商因為錯誤的交易頭寸造成4.4億美元的稅前損失，後來騎士資本的股價下跌63%至2.58美元，使得其市值縮水至2.53億美元，只有幾天前的四分之一，隨後股價再次下跌17%至2.14美元。而這一事件是由騎士資本一個小小的“技術問題”所引起，致使它向交易所發出了錯誤的股票交易指令。

因此，如果我們做的是金融的交易系統，保證資金安全是底線，保證了資金安全，我們才能謀取利潤，謀取利潤能夠讓我們的公司活下去，接下來要讓我們的盈利模型進入批量模式，我們才能將公司做大、做強。

資金損失和資金底線

我們如何來定義資金損失呢？凡是從事金融支付的活動的過程中，由於人為或者系統導致的資金虧損，都叫做資金損失。例如，在一筆電商交易過程中，發生了平臺單邊，支付未成功，但是通知用戶訂單成功，並發貨，這是一個典型的由於平臺單邊引起的資金損失。

采取的客觀的和主觀的方法來保證不發生資金損失，就是資金底線防火墻，我們把這些方法稱為保證資金底線的方法。資金底線是一個非常專業化的非主流概念，從百科或者其他的渠道是找不到官方定義的，我們通過舉例來說明幫助讀者理解資金底線，例如，我們通過對比支付成功通知和原支付信息中的ID和金額來保證不發生單邊，就是保證資金底線的一個典型案例。

在本文後面部分，我們會聚焦在第三方支付行業的資金損失的風險和資金底線防火墻的建設。

從支付業務劃分資金底線風險

在第三方支付行業，通常通過資金的流向把業務分成收單和出款，這裏我們分享可能存在的收單和出款的資金底線風險的場景。

收單的資金底線風險

收單業務是第三方支付的主要業務之一，由於收單業務可以結合多種交易場景，因此，也是最賺錢的一種業務，具有交易量大、風險性高的特點。

單邊是收單業務中最典型的資金底線風險，單邊這個詞匯來自於財務行業，在收單的結算流程中，很容易出現一種“單邊賬”的情況，單邊賬：即一方的賬目發生變化，而另一方沒有，那麽隨之而來的問題就是，錢去哪兒了？

這個場景又進而分為長款和短款兩個情況。

1. 長款：上遊給我的款項比我給下遊的多。
2. 短款：上遊給我的款項比我給下遊的少。

我們看到長款實際上是我們的資金比賬目多了，實際上沒有資金損失，單邊賬有百分之九十九點九九是長款，如果出現了短款情況，那就是災難，也是最嚴重的資金底線風險，是我們應該要堅決杜絕的。那麽我們在第三方支付平臺上，所說的單邊通常指的是財務行業裏單邊賬的短款，也就是導致了我們有資金損失的那個情況，因為工作在第三方支付的小夥伴們都不是財務專業或者對財務不熟悉的，所以，大家都把單邊賬的短款成為單邊，這裏我們也按照這個習慣來講解。

下面是一個典型的第三方支付收單的示意圖。

第三方支付的系統上接商戶系統，下接銀行系統。由於其處在承上啟下的位置，因此，是最容易產生收單單邊的資金底線風險。

簡單的來說，產生收單單邊資金底線風險的情況都是下遊系統失敗了，但是由於某種原因，典型的就是系統bug，返回給上遊系統成功，如果上遊系統是商戶的電商系統，有可能已經發貨了，這就導致了資金損失。

我們從系統層次上將單邊分成以下3種類型。

1. 第三方支付的系統與銀行之間的單邊。

   這種單邊發生在第三方支付系統與銀行之間，由於某種原因銀行系統支付失敗，但是第三方支付系統支付成功。

2. 第三方支付的系統內部的單邊。

   這種單邊發生在第三方支付內部的系統之間，由於某種原因第三方支付的底層系統支付失敗，但是上層系統支付成功。

3. 第三方支付的系統與商戶之間的單邊。

   這種單邊發生在第三方支付與商戶系統之間，由於某種原因第三方支付的系統支付失敗，但是商戶得到了支付成功的通知。

對於以上3種情況，都是我們要堅決避免，或者及時發現進行止損的。

另外，還有兩種特殊的單邊場景，一個叫做金額單邊，一個叫做訂單號重復單邊。

1. 金額單邊

   訂單在銀行實際支付金額小於第三方支付的訂單金額。

2. 訂單號重復單邊

   上層交易系統的多個訂單對應銀行子系統同一個訂單。

出款的資金底線風險

出款業務也是第三方支付的重要業務之一，具有體量大、單筆交易額高的特點，出款業務更容易產生資金底線風險，如果不加以防控，發生重復出款、多出款、出錯款也是家常便飯。

具體的資金損失的場景如下。

1. 重復出款

   一筆訂單出款多次，造成了成倍的資金損失。

2. 多出款

   一筆訂單總共出款金額大於訂單金額，大於部分的資金就是資金損失。

3. 出錯款

   一筆訂單出款給其他商戶。

4. 未扣賬出款

   沒有從商戶賬戶扣賬，資金直接從備付金賬戶扣除並轉出給商戶賬戶或者對公銀行卡。

從時間上劃分避免資金底線風險的方法

我們從發生資金底線的時序上總結避免資金底線的風險的方法，這些方法放在一起構成了資金底線防火墻。

事前避免

根據經驗，分析發生資金底線的風險的場景，阻斷場景發生的必要條件，避免這種場景的發生。這種方案是最好的方案，也是最難實現的一種，一般都是通過總結歷史線上事故，找出發生的典型的資金風險場景，針對場景的特點設計避免方案。

例如：在一筆支付做完後，將資金入賬，入賬的時候通過渠道查詢支付是否成功，如果不成功，講拒絕入賬。

事中攔截

事中攔截是一個非常重要的避免資金損失的方案，就是在支付過程中，通過支付的特點來識別是否發生了資金底線風險，如果識別到了，則可以及時攔截，不讓事情進一步惡化。

例如：渠道在收到銀行返回的支付成功通知的時候，會檢查返回通知裏面的成功支付金額是否與支付訂單一致，如果一致再向上通知。

事後止損

對於某些場景，我們通常沒有辦法完全事前避免和事中攔截，在這種情況下，我們通常通過對賬、監控等手段發現問題，並且事前預設止損的運營功能，一旦發現問題即使止損。

例如：我們通過監控手段得知某個渠道的成功率偏低或者偏高，然後進行報警，通過運營決策可以關掉某個渠道。

主觀方面避免資金損失

很多時候一次比較大的資金底線事故都是人為因素導致的，經常是用人來把關的多個階段都被忽略了才導致最終的“慘案”，這也難怪，我們是人，不是神，每天都收到生活、家庭、工資、心受傷的程度等各種因素的影響，偶爾開個小差是不可避免的。

主觀方面避免資金損失主要是通過對人的分析和采取策略，來避免資金損失。在筆者工作的幾年裏，一直負責資金底線風險的任務，筆者通過兩個重要的主管上的方案來避免資金損失。

1. 定期的對小夥伴宣講資金底線保護的重要性

   筆者多次對新員工、小夥伴們進行資金底線的培訓，一方面匯報資金底線項目的進展，之前發生的資金底線的事故的案例分析，並提醒小夥伴在設計中首要考慮資金底線的事情，我常常對小夥伴說：一個業務或者功能上線，可以不好用，可以不賺錢，但是不能損失錢。

2. 設計評審中要增加一項資金底線的評審項

   筆者在過去的幾年裏一直評審支付平臺的架構設計，凡事經過筆者評審的方案，筆者都會引導小夥伴來思考是否有資金風險，對可能的資金風險怎麽應對，經過筆者評審的方案，鮮有有資金風險發生。

客觀方面避免資金損失

盡管我們可以通過主觀方面的培訓、設計評審提醒大家要有資金底線保護的意識，但是，由於我們每個人員包括測試人員每天的狀態不一樣，情緒不一樣，那麽表現也不一樣，因此，我們不能完全仰仗人來保證資金底線，我們應該尋找能搞保障資金底線的客觀規律，把這些客觀規律做到系統中，這樣就能保證系統的資金是無法撼動的。

我們總結有一下多種方法。

1. 支付、渠道和賬務的三角校驗

   前面提到一個案例，在一筆支付做完後，將資金入賬，入賬的時候通過渠道查詢支付是否成功，如果不成功，講拒絕入賬，通過這樣的一個客觀的支付、賬務、渠道三個系統的三角閉環校驗可以避免資金損失。

   三角校驗如下圖所示。

   

2. 通知和渠道的首尾核對

   第三方支付系統與商戶交互的系統是通知系統，與銀行交互的系統是渠道，通知和渠道是系統上下的兩個邊界，把控住兩個邊界不產生單邊是非常重要的任務，這可以通過首尾核對來保障。

   首尾核對的示意圖如下。

   

3. 渠道與銀行的核對

   支付成功銀行通知第三方支付後，第三方支付的渠道系統實時反查銀行比對狀態和金額的查詢。有些銀行由於設計問題不支持實時查詢，則可以退而求其次，增加一個分鐘級異步核對與銀行之間的核查機制。

4. 渠道成功率監控

   對於渠道的成功率太高或者太低的情況進行監控，能夠防止系統bug導致的不該成功的支付都被認為成功了的情況，這個監控也是至關重要的。

5. 自動化的底線防火墻

   人總是受到各種環境的影響，完全靠人來保證代碼質量並不是萬無一失的，所以，我們應該尋求自動化測試方案，實際上第三方支付的產品形態主要是API產品，非常適合進行自動化測試，因此，我們要尋求兩個方面的自動化，一個是測試用例要自動化管理，不斷的積累測試用例，對測試用例進行分級，哪些是業務測試用例，哪些是資金底線測試用例，資金底線測試用例要在上生產環境之前的內側環境進行測試，而且應該由系統自動觸發，最好集成在devops的上線流程中，不可跳過，如果這部分的自動化的資金底線測試失敗，不允許上線。

   下圖中，我們看到內側環境我們構建了一個自動化的底線測試防火墻。

   

6. 渠道的試運營

   通常資金底線風險放生在渠道系統，因為渠道系統總是要對接新的銀行渠道，常在河邊走，哪有不濕鞋，因此，在新渠道上線的過程中，一定要保證有試運營的階段，是運營要認真觀察支付的結果，並且要有足夠的時間，至少要到第二天看到銀行的清算文件和對賬文件，與真實發起的交易一致，才能認為新渠道上線是成功的。

7. 萬無一失的資金對賬

   資金對賬是第三方支付必不可少的一個保證資金安全的方式，主要是通過第三方支付的信息與銀行之間的對賬，通常銀行回提供清算文件和對賬文件，清算文件記錄的是第三方支付做過的所有交易名氣，對賬文件是銀行提供的備付金賬戶資金的日初和日末的賬戶余額，通過這兩個對賬文件，一個代表信息流，一個代表資金流，就可以講所有的資金對清楚。

8. 具體到責任人的底線驗收

   對於重要功能上線，一定要制定負責人，負責人要對資金底線負責，功能上線之前要驗收，這裏一定要秉著負責到底的原則，不要大家都負責，結果大家都不負責，除了問題大家都帥鍋，誰負責，誰做底線驗收，上線成功誰獲得最高的回報，只有這樣才能保持一個良性循環，才能激勵大家對事情的負責態度。

9. 系統間一致性核對

   在第三方支付系統中，由於業務復雜，通常會使用分布式架構或者微服務架構來實現系統，一個流程依據功能被分散在多個系統中來實現，那麽每個系統中都有自己的支付狀態，各個系統之間如何協調一致呢？這就需要系統間一致性核對，也就是系統內的任何兩個相鄰的系統都需要進行核對支付訂單狀態。

執行資金底線保護任務的方法論

如果你足夠幸運在你所在的支付公司裏負責資金底線保護的任務，那麽恭喜你，只有關鍵核心的人才能做這份工作，但是，還有另外一個說法，這個工作其實是費力不討好的，做好了是應該做的，做不好那都是你的責任，不管怎麽樣，事情還是要做好。

如果你接到了這個任務，感覺無從下手，那麽請看下面的方法論。

1. 回顧以前發生的所有資金風險的案例。
2. 梳理可能發生資金風險的所有場景。
3. 根據發生資金風險的案例和場景，形成避免、攔截和止損的方案。
4. 做計劃和跟進方案的實施。

解密支付平臺建設資金底線防火墻的殺手級設計方案