解密支付平臺建設(shè)資金底線防火墻的殺手級設(shè)計方案
在金融支付行業(yè),資金底線的打法是至關(guān)重要的,保證資金不發(fā)生損失是任何一家金融支付行業(yè)的***要務(wù),這也是最困難的一個任務(wù)之一,一家支付公司每天的支付流水就有幾億、十幾億,甚至幾十億到上百億、上千億都屢見不鮮,在這樣大的資金流水面前,我們應(yīng)該如何保證資金萬無一失呢?
大家應(yīng)該都聽過騎士資本(Knight Capital)的故事,這家美國股市經(jīng)紀商因為錯誤的交易頭寸造成4.4億美元的稅前損失,后來騎士資本的股價下跌63%至2.58美元,使得其市值縮水至2.53億美元,只有幾天前的四分之一,隨后股價再次下跌17%至2.14美元。而這一事件是由騎士資本一個小小的“技術(shù)問題”所引起,致使它向交易所發(fā)出了錯誤的股票交易指令。
因此,如果我們做的是金融的交易系統(tǒng),保證資金安全是底線,保證了資金安全,我們才能謀取利潤,謀取利潤能夠讓我們的公司活下去,接下來要讓我們的盈利模型進入批量模式,我們才能將公司做大、做強。
資金損失和資金底線
我們?nèi)绾蝸矶x資金損失呢?凡是從事金融支付的活動的過程中,由于人為或者系統(tǒng)導(dǎo)致的資金虧損,都叫做資金損失。例如,在一筆電商交易過程中,發(fā)生了平臺單邊,支付未成功,但是通知用戶訂單成功,并發(fā)貨,這是一個典型的由于平臺單邊引起的資金損失。
采取的客觀的和主觀的方法來保證不發(fā)生資金損失,就是資金底線防火墻,我們把這些方法稱為保證資金底線的方法。資金底線是一個非常專業(yè)化的非主流概念,從百科或者其他的渠道是找不到官方定義的,我們通過舉例來說明幫助讀者理解資金底線,例如,我們通過對比支付成功通知和原支付信息中的ID和金額來保證不發(fā)生單邊,就是保證資金底線的一個典型案例。
在本文后面部分,我們會聚焦在第三方支付行業(yè)的資金損失的風(fēng)險和資金底線防火墻的建設(shè)。
從支付業(yè)務(wù)劃分資金底線風(fēng)險
在第三方支付行業(yè),通常通過資金的流向把業(yè)務(wù)分成收單和出款,這里我們分享可能存在的收單和出款的資金底線風(fēng)險的場景。
收單的資金底線風(fēng)險
收單業(yè)務(wù)是第三方支付的主要業(yè)務(wù)之一,由于收單業(yè)務(wù)可以結(jié)合多種交易場景,因此,也是***錢的一種業(yè)務(wù),具有交易量大、風(fēng)險性高的特點。
單邊是收單業(yè)務(wù)中最典型的資金底線風(fēng)險,單邊這個詞匯來自于財務(wù)行業(yè),在收單的結(jié)算流程中,很容易出現(xiàn)一種“單邊賬”的情況,單邊賬:即一方的賬目發(fā)生變化,而另一方?jīng)]有,那么隨之而來的問題就是,錢去哪兒了?
這個場景又進而分為長款和短款兩個情況。
- 長款:上游給我的款項比我給下游的多。
- 短款:上游給我的款項比我給下游的少。
我們看到長款實際上是我們的資金比賬目多了,實際上沒有資金損失,單邊賬有百分之九十九點九九是長款,如果出現(xiàn)了短款情況,那就是災(zāi)難,也是最嚴重的資金底線風(fēng)險,是我們應(yīng)該要堅決杜絕的。那么我們在第三方支付平臺上,所說的單邊通常指的是財務(wù)行業(yè)里單邊賬的短款,也就是導(dǎo)致了我們有資金損失的那個情況,因為工作在第三方支付的小伙伴們都不是財務(wù)專業(yè)或者對財務(wù)不熟悉的,所以,大家都把單邊賬的短款成為單邊,這里我們也按照這個習(xí)慣來講解。
下面是一個典型的第三方支付收單的示意圖。
第三方支付的系統(tǒng)上接商戶系統(tǒng),下接銀行系統(tǒng)。由于其處在承上啟下的位置,因此,是最容易產(chǎn)生收單單邊的資金底線風(fēng)險。
簡單的來說,產(chǎn)生收單單邊資金底線風(fēng)險的情況都是下游系統(tǒng)失敗了,但是由于某種原因,典型的就是系統(tǒng)bug,返回給上游系統(tǒng)成功,如果上游系統(tǒng)是商戶的電商系統(tǒng),有可能已經(jīng)發(fā)貨了,這就導(dǎo)致了資金損失。
我們從系統(tǒng)層次上將單邊分成以下3種類型。
1.第三方支付的系統(tǒng)與銀行之間的單邊。
這種單邊發(fā)生在第三方支付系統(tǒng)與銀行之間,由于某種原因銀行系統(tǒng)支付失敗,但是第三方支付系統(tǒng)支付成功。
2.第三方支付的系統(tǒng)內(nèi)部的單邊。
這種單邊發(fā)生在第三方支付內(nèi)部的系統(tǒng)之間,由于某種原因第三方支付的底層系統(tǒng)支付失敗,但是上層系統(tǒng)支付成功。
3.第三方支付的系統(tǒng)與商戶之間的單邊。
這種單邊發(fā)生在第三方支付與商戶系統(tǒng)之間,由于某種原因第三方支付的系統(tǒng)支付失敗,但是商戶得到了支付成功的通知。
對于以上3種情況,都是我們要堅決避免,或者及時發(fā)現(xiàn)進行止損的。
另外,還有兩種特殊的單邊場景,一個叫做金額單邊,一個叫做訂單號重復(fù)單邊。
1.金額單邊
訂單在銀行實際支付金額小于第三方支付的訂單金額。
2.訂單號重復(fù)單邊
上層交易系統(tǒng)的多個訂單對應(yīng)銀行子系統(tǒng)同一個訂單。
出款的資金底線風(fēng)險
出款業(yè)務(wù)也是第三方支付的重要業(yè)務(wù)之一,具有體量大、單筆交易額高的特點,出款業(yè)務(wù)更容易產(chǎn)生資金底線風(fēng)險,如果不加以防控,發(fā)生重復(fù)出款、多出款、出錯款也是家常便飯。
具體的資金損失的場景如下。
1.重復(fù)出款
一筆訂單出款多次,造成了成倍的資金損失。
2.多出款
一筆訂單總共出款金額大于訂單金額,大于部分的資金就是資金損失。
3.出錯款
一筆訂單出款給其他商戶。
4.未扣賬出款
沒有從商戶賬戶扣賬,資金直接從備付金賬戶扣除并轉(zhuǎn)出給商戶賬戶或者對公銀行卡。
從時間上劃分避免資金底線風(fēng)險的方法
我們從發(fā)生資金底線的時序上總結(jié)避免資金底線的風(fēng)險的方法,這些方法放在一起構(gòu)成了資金底線防火墻。
事前避免
根據(jù)經(jīng)驗,分析發(fā)生資金底線的風(fēng)險的場景,阻斷場景發(fā)生的必要條件,避免這種場景的發(fā)生。這種方案是***的方案,也是最難實現(xiàn)的一種,一般都是通過總結(jié)歷史線上事故,找出發(fā)生的典型的資金風(fēng)險場景,針對場景的特點設(shè)計避免方案。
例如:在一筆支付做完后,將資金入賬,入賬的時候通過渠道查詢支付是否成功,如果不成功,講拒絕入賬。
事中攔截
事中攔截是一個非常重要的避免資金損失的方案,就是在支付過程中,通過支付的特點來識別是否發(fā)生了資金底線風(fēng)險,如果識別到了,則可以及時攔截,不讓事情進一步惡化。
例如:渠道在收到銀行返回的支付成功通知的時候,會檢查返回通知里面的成功支付金額是否與支付訂單一致,如果一致再向上通知。
事后止損
對于某些場景,我們通常沒有辦法完全事前避免和事中攔截,在這種情況下,我們通常通過對賬、監(jiān)控等手段發(fā)現(xiàn)問題,并且事前預(yù)設(shè)止損的運營功能,一旦發(fā)現(xiàn)問題即使止損。
例如:我們通過監(jiān)控手段得知某個渠道的成功率偏低或者偏高,然后進行報警,通過運營決策可以關(guān)掉某個渠道。
主觀方面避免資金損失
很多時候一次比較大的資金底線事故都是人為因素導(dǎo)致的,經(jīng)常是用人來把關(guān)的多個階段都被忽略了才導(dǎo)致最終的“慘案”,這也難怪,我們是人,不是神,每天都收到生活、家庭、工資、心受傷的程度等各種因素的影響,偶爾開個小差是不可避免的。
主觀方面避免資金損失主要是通過對人的分析和采取策略,來避免資金損失。在筆者工作的幾年里,一直負責(zé)資金底線風(fēng)險的任務(wù),筆者通過兩個重要的主管上的方案來避免資金損失。
1.定期的對小伙伴宣講資金底線保護的重要性
筆者多次對新員工、小伙伴們進行資金底線的培訓(xùn),一方面匯報資金底線項目的進展,之前發(fā)生的資金底線的事故的案例分析,并提醒小伙伴在設(shè)計中首要考慮資金底線的事情,我常常對小伙伴說:一個業(yè)務(wù)或者功能上線,可以不好用,可以不賺錢,但是不能損失錢。
2.設(shè)計評審中要增加一項資金底線的評審項
筆者在過去的幾年里一直評審支付平臺的架構(gòu)設(shè)計,凡事經(jīng)過筆者評審的方案,筆者都會引導(dǎo)小伙伴來思考是否有資金風(fēng)險,對可能的資金風(fēng)險怎么應(yīng)對,經(jīng)過筆者評審的方案,鮮有有資金風(fēng)險發(fā)生。
客觀方面避免資金損失
盡管我們可以通過主觀方面的培訓(xùn)、設(shè)計評審提醒大家要有資金底線保護的意識,但是,由于我們每個人員包括測試人員每天的狀態(tài)不一樣,情緒不一樣,那么表現(xiàn)也不一樣,因此,我們不能完全仰仗人來保證資金底線,我們應(yīng)該尋找能搞保障資金底線的客觀規(guī)律,把這些客觀規(guī)律做到系統(tǒng)中,這樣就能保證系統(tǒng)的資金是無法撼動的。
我們總結(jié)有一下多種方法。
1.支付、渠道和賬務(wù)的三角校驗
前面提到一個案例,在一筆支付做完后,將資金入賬,入賬的時候通過渠道查詢支付是否成功,如果不成功,講拒絕入賬,通過這樣的一個客觀的支付、賬務(wù)、渠道三個系統(tǒng)的三角閉環(huán)校驗可以避免資金損失。
三角校驗如下圖所示。
1).通知和渠道的首尾核對
第三方支付系統(tǒng)與商戶交互的系統(tǒng)是通知系統(tǒng),與銀行交互的系統(tǒng)是渠道,通知和渠道是系統(tǒng)上下的兩個邊界,把控住兩個邊界不產(chǎn)生單邊是非常重要的任務(wù),這可以通過首尾核對來保障。
首尾核對的示意圖如下。
2)渠道與銀行的核對
支付成功銀行通知第三方支付后,第三方支付的渠道系統(tǒng)實時反查銀行比對狀態(tài)和金額的查詢。有些銀行由于設(shè)計問題不支持實時查詢,則可以退而求其次,增加一個分鐘級異步核對與銀行之間的核查機制。
3)渠道成功率監(jiān)控
對于渠道的成功率太高或者太低的情況進行監(jiān)控,能夠防止系統(tǒng)bug導(dǎo)致的不該成功的支付都被認為成功了的情況,這個監(jiān)控也是至關(guān)重要的。
4)自動化的底線防火墻
人總是受到各種環(huán)境的影響,完全靠人來保證代碼質(zhì)量并不是萬無一失的,所以,我們應(yīng)該尋求自動化測試方案,實際上第三方支付的產(chǎn)品形態(tài)主要是API產(chǎn)品,非常適合進行自動化測試,因此,我們要尋求兩個方面的自動化,一個是測試用例要自動化管理,不斷的積累測試用例,對測試用例進行分級,哪些是業(yè)務(wù)測試用例,哪些是資金底線測試用例,資金底線測試用例要在上生產(chǎn)環(huán)境之前的內(nèi)側(cè)環(huán)境進行測試,而且應(yīng)該由系統(tǒng)自動觸發(fā),***集成在devops的上線流程中,不可跳過,如果這部分的自動化的資金底線測試失敗,不允許上線。
下圖中,我們看到內(nèi)側(cè)環(huán)境我們構(gòu)建了一個自動化的底線測試防火墻。
1)渠道的試運營
通常資金底線風(fēng)險放生在渠道系統(tǒng),因為渠道系統(tǒng)總是要對接新的銀行渠道,常在河邊走,哪有不濕鞋,因此,在新渠道上線的過程中,一定要保證有試運營的階段,是運營要認真觀察支付的結(jié)果,并且要有足夠的時間,至少要到第二天看到銀行的清算文件和對賬文件,與真實發(fā)起的交易一致,才能認為新渠道上線是成功的。
2)萬無一失的資金對賬
資金對賬是第三方支付必不可少的一個保證資金安全的方式,主要是通過第三方支付的信息與銀行之間的對賬,通常銀行回提供清算文件和對賬文件,清算文件記錄的是第三方支付做過的所有交易名氣,對賬文件是銀行提供的備付金賬戶資金的日初和日末的賬戶余額,通過這兩個對賬文件,一個代表信息流,一個代表資金流,就可以講所有的資金對清楚。
3)具體到責(zé)任人的底線驗收
對于重要功能上線,一定要制定負責(zé)人,負責(zé)人要對資金底線負責(zé),功能上線之前要驗收,這里一定要秉著負責(zé)到底的原則,不要大家都負責(zé),結(jié)果大家都不負責(zé),除了問題大家都帥鍋,誰負責(zé),誰做底線驗收,上線成功誰獲得***的回報,只有這樣才能保持一個良性循環(huán),才能激勵大家對事情的負責(zé)態(tài)度。
4)系統(tǒng)間一致性核對
在第三方支付系統(tǒng)中,由于業(yè)務(wù)復(fù)雜,通常會使用分布式架構(gòu)或者微服務(wù)架構(gòu)來實現(xiàn)系統(tǒng),一個流程依據(jù)功能被分散在多個系統(tǒng)中來實現(xiàn),那么每個系統(tǒng)中都有自己的支付狀態(tài),各個系統(tǒng)之間如何協(xié)調(diào)一致呢?這就需要系統(tǒng)間一致性核對,也就是系統(tǒng)內(nèi)的任何兩個相鄰的系統(tǒng)都需要進行核對支付訂單狀態(tài)。
執(zhí)行資金底線保護任務(wù)的方法論
如果你足夠幸運在你所在的支付公司里負責(zé)資金底線保護的任務(wù),那么恭喜你,只有關(guān)鍵核心的人才能做這份工作,但是,還有另外一個說法,這個工作其實是費力不討好的,做好了是應(yīng)該做的,做不好那都是你的責(zé)任,不管怎么樣,事情還是要做好。
如果你接到了這個任務(wù),感覺無從下手,那么請看下面的方法論。
- 回顧以前發(fā)生的所有資金風(fēng)險的案例。
- 梳理可能發(fā)生資金風(fēng)險的所有場景。
- 根據(jù)發(fā)生資金風(fēng)險的案例和場景,形成避免、攔截和止損的方案。
- 做計劃和跟進方案的實施。
【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件,轉(zhuǎn)載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】