聊聊對賬系統(tǒng)的設(shè)計方案
前言
對賬系統(tǒng)作為支付系統(tǒng)中的基石系統(tǒng),處于整個支付環(huán)節(jié)中的最后一層，主要用來保證我方支付數(shù)據(jù)與第三方支付渠道或銀行的數(shù)據(jù)一致性。
在沒有對賬系統(tǒng)之前，財務(wù)在第二日手工核對前一日的應(yīng)收與實收。倘若不一致，這就需要一一核對數(shù)據(jù)，找出不一致的數(shù)據(jù)。對賬系統(tǒng)出現(xiàn)之后，就可減少以這種繁瑣手工操作，財務(wù)只需要每天關(guān)注系統(tǒng)的對賬記錄，釋放了生產(chǎn)力。
本文主要結(jié)合實際的項目經(jīng)驗，聊聊對賬系統(tǒng)的設(shè)計方案。
系統(tǒng)整體設(shè)計
對賬系統(tǒng)設(shè)計主要分為以下四個模塊：
渠道數(shù)據(jù)處理模塊
數(shù)據(jù)處理模塊
數(shù)據(jù)核對模塊
差異數(shù)據(jù)處理模塊
模塊調(diào)用順序?qū)哟螆D如下。
下面先來介紹渠道數(shù)據(jù)處理模塊。
渠道數(shù)據(jù)處理模塊
這個模塊主要負責(zé)渠道對賬文件的下載，解析，以及數(shù)據(jù)落庫。
目前市面上第三方支付渠道對賬文件下載方式主要分為以下幾類：
第三方渠道定時推送到 SFTP/FTP。這種模式比較簡單，我們定時從 SFTP/FTP 取對賬文件。
調(diào)用第三方渠道對賬文件下載接口。這種模式需要對接渠道下載對賬文件接口，定時調(diào)用下載。支付寶與微信為該模式。
手動在支付渠道網(wǎng)站下載對賬文件。這種模式最不友好，需要我們花費人力下載文件。
除了下載方式，對賬文件的格式也會存在一些區(qū)別。比如支付寶對賬文件格式為 csv，而微信的對賬文件格式為 txt，另外有些渠道為 xml,xls。
第三方渠道對賬文件里面字段數(shù)量以及字段名稱也存在不同。
一般這一層每接入一個渠道需要專門根據(jù)這個渠道特性開發(fā)。這一層可以抽象化接口，對外暴露下載與解析接口。每次接入渠道，實現(xiàn)該接口相應(yīng)方法即可。
這一層開發(fā)難度不大，只要根據(jù)對賬文件格式相應(yīng)解析文件即可。一般需要提取對賬文件里面信息如下：
商戶號
商戶訂單號
渠道流水號
交易日期
交易金額
手續(xù)費
退款原訂單號
下面說一下開發(fā)這一層需要注意的一些細節(jié)。
1、同一渠道若申請了多個商戶號。這種情況下，每個商戶號若前一日都存在交易，第三方渠道會為每個商戶號都會產(chǎn)生一份對賬文件。所以這里系統(tǒng)設(shè)計時候需要考慮到多份對賬文件處理的情況。2、對賬文件需要考慮重復(fù)下載的情況。一般情況下，渠道的對賬文件一旦生成，就不會改變。但是第三方渠道也可能發(fā)生異常，導(dǎo)致我方收到對賬文件數(shù)據(jù)不完整。這種情況下，需要有機制重新下載解析入庫。3、每個第三方渠道下載文件時間都不一樣。
數(shù)據(jù)處理模塊
講完對賬文件處理模塊，我們來看數(shù)據(jù)處理模塊。
這個模塊主要用來提取我方前一日所有支付成功的流水?dāng)?shù)據(jù)以及上一模塊入庫的前一日對賬單的流水?dāng)?shù)據(jù)。為了減少數(shù)據(jù)庫的壓力，提取的數(shù)據(jù)只需要包括必要字段即可，無需將整行數(shù)數(shù)據(jù)信息都提取出來。一般來說只要需要提取交易時間，金額，交易訂單號，渠道返回流水號。
這一層主要就是數(shù)據(jù)庫的查詢行為。最好使用備庫進行數(shù)據(jù)查詢。因為這里我們需要提取前一日全量的支付成功的數(shù)據(jù)，數(shù)據(jù)量大的情況下，可能會拖慢主庫，影響在線的支付交易。
核對模塊
這一個模塊我們使用上一模塊提取出來的數(shù)據(jù)，核對訂單號與金額是否完全一致。核對模塊偽代碼如下。
這個過程可能產(chǎn)生三類差異數(shù)據(jù)。
第一種情況為本端數(shù)據(jù)存在，對端數(shù)據(jù)不存在，我們稱為本端多賬。
第二種情況為對端數(shù)據(jù)存在，本端數(shù)據(jù)不存在，我們稱為對端多賬。
第三種情況為金額不一致。
三者如圖所示。
這里產(chǎn)生的差異數(shù)據(jù)存入一張差異表中，以便下個模塊使用。
差異數(shù)據(jù)處理模塊
這個模塊主要用來處理上個模塊產(chǎn)生的差異數(shù)據(jù)。
上面三類差異數(shù)據(jù)中，金額不一致相當(dāng)少見，這種情況需要人工判斷。
我們先討論本端多賬的情況。
本端多賬是對賬系統(tǒng)最常見的一種情況。這種情況可能由于交易的時候發(fā)生日切問題，導(dǎo)致雙方記賬日期不一致,從而發(fā)生不平賬。
我們先解釋日切的概念。
日切，通俗的來說就是更換系統(tǒng)記賬的時間，系統(tǒng)從當(dāng)前工作日切換到下一工作日。這個過程中，若我方的交易訂單剛好發(fā)生在 T 日 23:59:59，那么我方的記賬時間為 T 日。第三方渠道接收到訂單的時間為 T+1 日 00:00:01，這樣第三方渠道該筆的交易的對賬日期為 T+1 日。
第三方渠道 T 日對賬文件將缺少這筆，但是我方 T 日數(shù)據(jù)卻存在這筆，這就導(dǎo)致了核對過程中產(chǎn)生一筆本端多賬差異數(shù)據(jù)。
對于這類差異數(shù)據(jù)，我們可以選擇將這筆數(shù)據(jù)掛賬，等待 T+1 工作日對賬。T+1 日對賬的時候，對賬單會相應(yīng)多出數(shù)據(jù)，這樣在核對過程就會產(chǎn)生對端多賬的差異數(shù)據(jù)。
然后在 T+1 日差異處理模塊將前幾日差異數(shù)據(jù)都提取出來，逐筆核對本端多賬數(shù)據(jù)與對端多賬數(shù)據(jù)。若核對一致，將兩筆差異狀態(tài)都更新成處理完成。最后若無剩余差異數(shù)據(jù)，當(dāng)天賬單平賬。
偽代碼如下：
對端多賬的產(chǎn)生情況可能可能有兩種情況.
第一種情況測試環(huán)境與生產(chǎn)環(huán)境共用一份第三方渠道參數(shù)，這就導(dǎo)致測試環(huán)境交易訂單也會出現(xiàn)在對賬單中。若是這種情況，我們確認測試環(huán)境存在這批數(shù)據(jù)之后，我們忽略這批差異數(shù)據(jù)即可。
第二種情況，本端交易訂單存在，但是狀態(tài)不是成功狀態(tài)。這種情況下，需要調(diào)用第三方渠道提供的查詢接口，查詢訂單最終狀態(tài)。若查詢成功，更新訂單狀態(tài)，然后將差異數(shù)據(jù)狀態(tài)更改為處理成功。
若第三方渠道無法查詢到訂單的狀態(tài)。這種若與渠道確認訂單最終支付成功，我們需要將支付訂單改為支付成功，并修改差異賬的狀態(tài)。
最后我們再次重新對賬，由于對端多賬的數(shù)據(jù)會有對應(yīng)的本端數(shù)據(jù)，將不會產(chǎn)生差異數(shù)據(jù)，這次對賬完成且平賬。
系統(tǒng)優(yōu)化
目前系統(tǒng)的對賬系統(tǒng)定時任務(wù)采用 Spring 定時功能。后期優(yōu)化準備接入 elasticjob 這種分布式定時調(diào)度程序，可以做到快速修改定時任務(wù)的時間，而無需重啟程序。以及可以快速觸發(fā)定時任務(wù)。
總之，對賬系統(tǒng)工作不難，就是細節(jié)比較繁瑣，前期很難將所有細節(jié)都考慮完全，這個過程需要我們不斷改進。
