2018年8月9日，微信某公眾號爆出某支付出重大事故，重複結算金額超過3億。重複結算是支付公司經常性的錯誤。該公司在2014年11月4日、2017年1月24日、2018年5月份都爆過重複結算的案件，還被銀聯點名批評了。2014年11月也有某支付公司爆發重複結算問題，涉案金額9億元，重複結算4.5億，到現在資金還沒完全追回來。重複結算給支付公司帶來巨大損失。那應該如何避免這個問題？我們邀請了雙乾支付技術總監韓偉來做了一次分享。
一、背景介紹
保障客戶備付金資金安全是每個支付公司的首要職責，所以人民銀行也下達了一系列措施和規定，需要支付公司嚴格遵守《支付機構客戶備付金存管辦法》。需要支付機構和備付金銀行能夠逐日逐筆核對客戶備付金交易明細，支付機構的公司治理規範、風險管理制度健全、客戶備付金安全保障措施有效。
支付機構每月人工和備付金銀行核對數據，並每季度需要在人行的客戶備付金信息核驗系統內進行上報以下信息：
支付機構與各備付金銀行分別就其業務系統中記載的當期出入金業務與備付金銀行賬戶出入金信息進行核對、校驗。
支付機構與備付金存管銀行法人（或其授權分支機構）就支付機構業務系統中客戶資金賬戶當期發生額、期末餘額與全部備付金銀行存款的變動及餘額進行計算和核對。
但所有支付系統都是人開發的，難免會有出錯的時候，那我們如何來保障支付機構不發生重複出款，我來簡單談下預防和治理的方法。
二、出錯場景
一般的出錯場景：
1.程序邏輯錯誤
每次出款，都等銀行返回結果後，再去保存數據庫出款成功的結果。一旦網絡異常或者數據庫繁忙，無法插入成功狀態或者其他原因導致存儲過程回滾，這時候由於最終狀態沒有更新，所以能夠重複再次出款。
2.隔日場景，或者服務器時間差
某一筆結算流水，剛好跨天了，比如23：59分提交，銀行出款在下一天。但因為未能正常異步通知成功，查詢程序卻去查詢昨日有無成功，沒有結果，則導致再次出款。有時候由於上游服務器和你生產服務器時間差幾分鐘，也會導致查詢失敗再次出款。
3.多個定時任務
一般定時任務跟隨項目工程文件一起提交，容易被部署在多臺服務器集群內，當代付的Job在多臺服務器上運行時，那必然會導致重複出款。
4.服務器異常崩潰
服務器異常崩潰、如果是windows server還會發生藍屏等，導致沒法完成數據庫的存儲，異步通知的發送，甚至redis內存狀態的丟失等，都會可能導致重複出款。
5.提交併發
一般是財務審核的按鈕提交併發，或者自動審核的話，提交的時候產生併發，就會導致重複多次出款。
作為支付機構，主要需要保障以下情況資金安全：
保障結算到結算賬戶不重複（T1，T0，D0）
保障結算到銀行賬戶或卡不重複（T1，T0，D0）
保障商戶（結算賬戶）結算款提現不重複
保障客戶（支付賬戶）提現不重複
保障代付業務不重複
按重要度分（由重要—>次要）：
代付業務不重複（因為批量業務，一旦一個批次重複，損失金額巨大）
直接結算到銀行賬戶或卡不重複（T1，T0，D0）（因為商戶結算資金一般都比較大）
客戶提現不重複、商戶結算款提現不重複（一般是單筆提現）
結算到賬戶不重複（一般對賬能否發現，可以發起衝正交易，避免損失）
三、解決思路
3.1把出款和結算，分步驟進行
把備付金出款分步驟
a.生成出款批次
b.審核
c.出款
把商戶結算分步驟
a.生成商戶結算單
b.審核
c.出款
3，把客戶提現分步驟
a.生成提現記錄
b.審核
c.出款
3.2各步驟增加風控機制
1、出款前先扣除餘額：
生成代付批次時，先扣除商戶餘額，再處理其他；
生成提現申請時，先扣商戶餘額或者支付賬戶餘額，再處理其他。
2、每一次代付請求或者提現，都需要通過一次財務審核（當兩個批次，相同金額要出款，財務一般都能看出來），如果是D0、或者系統定時的T0，T1，系統也要自動做次審核動作。
3、代付出款時，Job只處理已審核未出款的批次，但一旦進入Job，不管後續如何執行，都先標記“處理中“。所以哪怕這個批次再次進入出款隊列，或者存儲過程回滾，也不會再次觸發重複出款。
4、客戶提現，均分批定時處理。渠道只有單筆接口，也封裝成批量接口。（分批處理還能減少壓力，減少單個重複的可能性）
5、在生成結算單時，
如果是T1商戶，則一天只能生成一筆結算記錄，時間範圍就是T日。
如果是T0商戶，則看T0的場次，如果頻次也是1天一次，那也只能生成一次結算記錄。
如果T0的場次是2次及以上，則嚴格根據交易時間來劃分多個結算記錄，保證各時間段不能重疊和重複生成記錄。
如果是D0商戶，則每一筆結算記錄生成，都要嚴格匹配交易記錄。
6、為了減少出錯，系統自動處理的結算，都是嚴格按照D0，T0，T1的結算時間來處理，不會結算之前的交易。如果之前商戶有資金未結算，則必須人工審核才能增加到出款隊列。
7、財務人工審核完畢，標記已審核，或者D0進入Job，立即標記為已審核。審核完畢，會標記為“已審核出款處理中”狀態，等待出款。這裡可以加一個風控，可以判斷同一天內同一個商戶同一結算金額不允許有多個結算記錄通過審核，或者拋到結算異常中，等待財務人工再次確認。
8、出款只保留4個狀態：處理中，成功，已退回，異常。處理中、已退回和成功的出款，無法修改任何狀態，只有“異常“狀態的，可以人工再次出款或者標記為”已退回“。除了明確的”成功“標記，其他任何異常返回碼對應的都是異常，這是為了防止上游渠道增加返回碼，導致重複出款。所有的異常都拋到異常菜單，由財務人工後續處理。
9、對於存在於異常的訂單，1小時內由專門的查詢服務器進行查詢，財務人工只能處理1小時後的訂單（系統人為鎖定1小時，主要防止1小時內渠道變交易成功），如果想優化這個等待時間的話，建議把收款人信息錯誤的那些失敗，單獨篩選出來，可以讓財務或者自動退回。
10、在前端、後臺都用上防重複提交的校驗，杜絕提交併發的產生.一般採取的措施是：
禁掉提交按鈕
在數據庫中加約束
redis加鎖
提交表單內生成一個令牌，服務器校驗。
可以參考以下鏈接：
防止form表單重複提交的八種方法
因併發造成創建了2條相同訂單解決的方法
11、出款需要接入人行規定的電信防詐騙前置機和建議接入過濾下銀聯的黑名單庫。
3.3增加系統和財務人工核賬步驟
【系統自動+財務人工複核】支付公司需要做到每日進行備付金自動校驗，至少隔日能夠發現系統是否發生了異常。我們大約花了3個月做了備付金自動校驗系統。
【系統自動校驗】對於D0結算到銀行卡，可以檢測出款記錄中是否已經存在該筆訂單號；
【系統自動校驗】對於普通商戶結算到賬戶餘額，可以檢測收支記錄中，是否一天內有多筆相同金額入賬，結算金額和前日交易金額是否匹配等。
【財務人工複核】財務每天至少核對3次各備付金銀行出款情況，與系統出款記錄進行比對。
對於異常單，財務處理時，必須先核對對賬文件後，才能進行再次出款或者退回操作。（網聯一般2小時，銀聯實時獲取，部分直連銀行需要隔日）。如果當日得不到退款對賬文件的，一般建議隔日再給客戶退款或者再次出款。
3.4其他一些規則
規定23:50-0:10分之間不能出款，以避免代付服務器與上游服務器有時間差，從而導致無法準確查詢得到出款指令。也避免有些銀行隔日原因導致重複出款。
相同定時任務只在一臺服務器上執行，一旦服務器掛掉，就在另外一臺人工起，不允許自動在多臺服務器上開啟定時任務。
定時自動檢查已審核，但實際未成功出款的訂單。因為程序異常，藍屏，數據庫停止響應而沒有出款的記錄，都會以“已審核，處理中“的狀態存在，而不是重複出款。雖然這個檢查跟重複出款沒有關係，但為了增加客戶體驗，建議這麼做。
四、總原則
1、控制出款風險的總原則：
2、先扣款，再生成處理訂單，寧可長款也不能短款，寬進嚴出。
3、自動校驗商戶的結算記錄和客戶出款記錄，不允許同一天同一金額的結算記錄產生多條。如果同一客戶相同金額的多筆出款，建議列入異常，由人工複核。
4、只要進入處理流程，先標記“處理中”，對於“處理中”的訂單，不能再重複自動發起
5、除了成功之外，所有的其他通知的，都列為異常，需要人工處理
6、異常的交易，需要定時器主動查詢1小時後，再放給財務重新處理出款
7、需要有一套系統自動備付金校驗系統，每日深夜自動與備付金銀行核對，並次日財務人工確認。
8、不允許同一付款的定時器在多臺服務器開啟。
9、出款跳過23：50-0：10這一時間段，避免上游服務器和你服務器之間的時間差，產生隔日出款。
10、審核提交等，加上前後端的防併發處理，防範http的retry。
本文檔來自“支付產品架構交流群”的聊天記錄整理，由志願者整理併發布到本網站。如需要及時收到來自“支付產品架構交流群”的最新消息，請掃碼關注“鳳凰牌老熊”的微信公眾號。
本文為作者授權發佈，不代表移動支付網立場，轉載請註明作者及來源，未按照規範轉載者，移動支付網保留追究相應責任的權利。
閱讀更多 移動支付網 的文章
