支付系統對賬設計

對賬系統作為支付系統中的基石系統,處於整個支付環節中的最後一層，主要用來保證我方支付資料與第三方支付渠道或銀行的資料一致性。

在沒有對賬系統之前，財務在第二日手工核對前一日的應收與實收。倘若不一致，這就需要一一核對資料，找出不一致的資料。對賬系統出現之後，就可減少以這種繁瑣手工操作，財務只需要每天關注系統的對賬記錄，釋放了生產力。

本文主要結合實際的專案經驗，聊聊對賬系統的設計方案。

對賬系統設計主要分為以下四個模組：

模組呼叫順序層次圖如下。

下面先來介紹渠道資料處理模組。

第三方渠道對賬檔案裡面字段數量以及欄位名稱也存在不同。

這一層開發難度不大，只要根據對賬檔案格式相應解析檔案即可。一般需要提取對賬檔案裡面資訊如下：

商戶號商戶訂單號渠道流水號交易日期交易金額手續費退款原訂單號複製**

下面說一下開發這一層需要注意的一些細節。

講完對賬檔案處理模組，我們來看資料處理模組。

這個模組主要用來提取我方前一日所有支付成功的流水資料以及上一模組入庫的前一日對賬單的流水資料。為了減少資料庫的壓力，提取的資料只需要包括必要字段即可，無需將整行資料資訊都提取出來。一般來說只要需要提取交易時間，金額，交易訂單號，渠道返回流水號。

這乙個模組我們使用上一模組提取出來的資料，核對訂單號與金額是否完全一致。核對模組偽**如下。

這個過程可能產生三類差異資料。

第一種情況為本端資料存在，對端資料不存在，我們稱為本端多賬。

第二種情況為對端資料存在，本端資料不存在，我們稱為對端多賬。

第三種情況為金額不一致。

三者如圖所示。

這裡產生的差異資料存入一張差異表中，以便下個模組使用。

這個模組主要用來處理上個模組產生的差異資料。

上面三類差異資料中，金額不一致相當少見，這種情況需要人工判斷。

我們先討論本端多賬的情況。

本端多賬是對賬系統最常見的一種情況。這種情況可能由於交易的時候發生日切問題，導致雙方記賬日期不一致,從而發生不平賬。

我們先解釋日切的概念。

日切，通俗的來說就是更換系統記賬的時間，系統從當前工作日切換到下一工作日。這個過程中，若我方的交易訂單剛好發生在 t 日 23:59:59，那麼我方的記賬時間為 t 日。第三方渠道接收到訂單的時間為 t+1 日 00:00:01，這樣第三方渠道該筆的交易的對賬日期為 t+1 日。

第三方渠道 t 日對賬檔案將缺少這筆，但是我方 t 日資料卻存在這筆，這就導致了核對過程中產生一筆本端多賬差異資料。

對於這類差異資料，我們可以選擇將這筆資料掛賬，等待 t+1 工作日對賬。t+1 日對賬的時候，對賬單會相應多出資料，這樣在核對過程就會產生對端多賬的差異資料。

然後在 t+1 日差異處理模組將前幾日差異資料都提取出來，逐筆核對本端多賬資料與對端多賬資料。若核對一致，將兩筆差異狀態都更新成處理完成。最後若無剩餘差異資料，當天賬單平賬。

偽**如下：

對端多賬的產生情況可能可能有兩種情況.

第一種情況測試環境與生產環境共用乙份第三方渠道引數，這就導致測試環境交易訂單也會出現在對賬單中。若是這種情況，我們確認測試環境存在這批資料之後，我們忽略這批差異資料即可。

第二種情況，本端交易訂單存在，但是狀態不是成功狀態。這種情況下，需要呼叫第三方渠道提供的查詢介面，查詢訂單最終狀態。若查詢成功，更新訂單狀態，然後將差異資料狀態更改為處理成功。

若第三方渠道無法查詢到訂單的狀態。這種若與渠道確認訂單最終支付成功，我們需要將支付訂單改為支付成功，並修改差異賬的狀態。

最後我們再次重新對賬，由於對端多賬的資料會有對應的本端資料，將不會產生差異資料，這次對賬完成且平賬。

目前系統的對賬系統定時任務採用 spring 定時功能。後期優化準備接入 elasticjob 這種分布式定時排程程式，可以做到快速修改定時任務的時間，而無需重啟程式。以及可以快速觸發定時任務。

總之，對賬系統工作不難，就是細節比較繁瑣，前期很難將所有細節都考慮完全，這個過程需要我們不斷改進。