業(yè)務背景：
對賬模塊是支付系統(tǒng)的核心能力之一，是信息流和資金流關聯的重要依據，平臺如果只使用渠道的單邊賬單或者平臺流水訂單，出現差錯或渠道惡意扣單的風險極高。
為提高資金賬務的正確性和保障平臺的利益，需要通過平臺系統(tǒng)對賬能力與上游渠道對賬單逐筆勾兌確認，如有差異能及時解決或歸檔。
用戶畫像：
1）清結算專員：負責發(fā)起清分的操作者，首先確保信息流對平，然后確認資金流應收款和信息流平賬賬單金額一致。希望能及時發(fā)現長短款問題，并解決，保障資金清算給商戶（平臺可收款用戶）的時效性。
2）對賬異常訂單處理專員：負責核算異常訂單原因，并在平臺操作將異常訂單執(zhí)行修正、平賬。
一、必須知道的業(yè)務知識點
1. 對賬
在會計上概念：指為了保證賬簿記錄的正確性而進行的有關賬項的核對工作；做到賬證相符、賬賬相符、賬實相符。
在支付系統(tǒng)上的體現：
1）賬證核對：是將賬簿記錄與記賬憑證進行核對。這里是記賬憑證是指第三方上游提供的渠道對賬單，第三方渠道會根據對賬單金額實際結算資金，也就是常說的信息流對賬。（有的支付公司或銀行只要收到對賬單了且平賬，即使資金未實際到賬，業(yè)務也允許發(fā)起清分以提高清算時效性）
2）賬賬核對：是把有相互關系的多個賬簿記錄進行核對，有相互關系的賬簿記錄，包括總分類賬簿間核對，明細賬簿間核對等多種類型。整個支付系統(tǒng)可以被拆分成了多個子系統(tǒng)，如交易系統(tǒng)、賬戶系統(tǒng)、會計系統(tǒng)、賬戶系統(tǒng)，每個子系統(tǒng)在處理各自的業(yè)務并記錄，其實就相當于會記理論中的賬簿。系統(tǒng)間的對賬，主要用于修正內部系統(tǒng)的數據不一致。
3）賬實核對：是各項資產物資的記錄數值與實際真實數額間的核對。確認第三方匯款到銀行賬戶資金和平賬對賬單結算金額是否匹配，也就是常說的資金流對賬。
2. 軋帳
對賬系統(tǒng)主要做的是信息流的對賬，若對賬中發(fā)現有差異的訂單歸類記入對賬異常訂單表，可稱為軋帳。
3. 平帳
對賬異常訂單進入差錯流程，可以通過人工或者自動的方式，按照事先設計好的規(guī)則處理這些異常差錯，可稱為平帳。
4、渠道對賬單
上游渠道會按照平臺在其申請的渠道賬戶維度推送對賬單，渠道賬戶也就是常說的支付通道。
如果是第三方支付公司或銀行，上游渠道是微信、支付寶、銀聯二維碼（云閃付）等等。例如：支付平臺申請有微信2通道和微信6通道，則微信側會生成2份對賬單文件。
每份對賬單會包括支付成功訂單和退款成功訂單。第三方會以對賬單中的結算金額（支付訂單金額-支付訂單手續(xù)費）-（退款訂單金額-退款訂單手續(xù)費）結算匯款給到平臺資金賬戶。
5、銀聯二維碼（難點）
銀聯二維碼是銀聯平臺自主推出的支付產品，C端使用云閃付、各手機銀行APP支付，訂單底層走的都是銀聯二維碼通道。
為什么銀聯二維碼需要重點說呢？
因為它不同于微信、支付寶通道統(tǒng)一費率的原則，銀聯會根據C端用戶支付時使用的銀行卡借貸性質和交易金額是否大于1000作為費率規(guī)則，并且還會收取額外的品牌服務費，詳情參見下圖。
所以設計銀聯二維碼通道對賬時，還需考慮到多費率及品牌服務費的場景。
二、對賬流程
1. 業(yè)務流程
對賬業(yè)務可以插解為5個業(yè)務環(huán)節(jié)，本文主要說明每個環(huán)節(jié)的能力職責、常見問題和通用解決方法，具體的產品方案還需要結合讀者平臺自身的業(yè)務特點和系統(tǒng)架構設計。
三、對賬任務
對賬是一個日常操作，正常情況下上游渠道都會以D+1的周期生成渠道對賬單。
每天系統(tǒng)可以默認生成定時對賬任務，每個上游渠道生成時間不一樣，可以事前和上游確認，并結合平臺對賬的處理時效和商戶到賬需求，設計一個合理的時間執(zhí)行。
對賬任務設計前需確認，渠道對賬單推送方式、解析方法、匹配字段，并提前做好聯調適配工作；例如渠道有可能會需要申請白名單權限或提供SFTP地址信息，要謹防上線后才發(fā)現系統(tǒng)無法正常獲取對賬單的情況。
1. 創(chuàng)建任務批次
創(chuàng)建批次一方面是為了防止重復對賬，另一方面需要在對賬結束的時候將對賬的結果信息存儲到批次中。
2. 記錄任務信息
對賬任務信息，例如：通道名稱、通道編號、渠道商戶號、對賬任務批次、對賬任務狀態(tài)、交易時間、任務創(chuàng)建時間、下載開始時間、下載結束時間、下載狀態(tài)、對賬開始時間、對賬結束時間、對賬結果、對賬方式；
對賬方式為對賬處理時的對賬規(guī)則，可以根據業(yè)務實際情況分為：無需對賬、以渠道為準、以平臺為準。
以渠道為準，則若對賬訂單平臺交易狀態(tài)為支付中或支付失敗，但渠道為支付成功，則平臺狀態(tài)改為支付成功。
以平臺為準，則是若出現上述情況，對賬訂單記錄為異常訂單。
3. 重置任務機制
考慮到對賬過程中可能會遇到的來自上游渠道的問題或平臺系統(tǒng)自身問題，需要設計重置機制。
上游渠道對賬單錯誤，需求二次或多次推送，所以需要設計重新下載渠道對賬單或重新上傳渠道對賬單；有可能平臺自身數據錯誤導致出現大量的差異訂單，修復后需要重新對賬。
4. 對賬任務詳情示例
對賬信息：記錄對賬任務基本情況；
對賬結果信息：顯示關鍵對賬字段值；
掛銷賬信息：顯示是否有掛銷賬訂單及金額；
對賬異常信息：顯示是否有對賬異常訂單及金額；
備注：將系統(tǒng)自動處理的過程記錄，也可以手動修改。
四、對賬單下載
1. 獲取文件
渠道對賬單獲取方式，一般提前作為任務規(guī)則寫死。
大多數銀行都要求接入方提供ftp服務，銀行定時將對賬單推送到接入方提供的ftp服務器上面；
還有一部分銀行會提供對賬單的下載服務，通過ftp/http的都有，ftp方式居多；
另外網銀的對賬單比較特殊，一般都需要結算登錄網銀的后臺管理系統(tǒng)中，手動下載，結算下載完對賬單后在導入到對賬系統(tǒng)。
2. 判斷文件是否存在
任務自動獲取文件的情況下需要判斷任務是否存在：
自動獲取渠道對賬單：不存在需要設置輪詢，每間隔一段時間重新獲取。重試次數和間隔的設置需要小心，重試太頻繁，容易把服務器打死.；時間間隔太大，又會阻塞后續(xù)處理步驟。5～10分鐘是一個合適的重試間隔區(qū)間。
手動導入渠道對賬單：要設計導入入口，導入成功后任務狀態(tài)也要做相應的變更。
3. 下載文件
技術實現上可以做成工廠模式，不同的支付渠道有不同的下載類，如果是http接口將文件寫入到對賬單，如果是ftp服務器，將服務器中的對賬單下載到本地帶解析的目錄中。主要涉及的代碼ftp工具類、http(s)工具類，相關IO讀寫。
4. 判斷來源渠道
獲取到上游對賬單文件后，很有可能多個渠道的對賬單在同一個SFTP地址，根據文件名匹配到對應的對賬任務，文件名一般會包含賬單時間、渠道商戶號，然后再執(zhí)行下一步。
五、文件解析
1. 解析文件
解析文件主要是將下載的對賬文件解析成我們可以對賬的數據類型并且入庫。
解析的文件不同渠道有不同的類型，因此也可以設計成不同的解析模板，使用工廠模式將不同格式的文件解析成可以對賬的統(tǒng)一數據類型。
解析的文件類型一般包括：json、text、cvs、excle等，另外部分銀行會對賬單做加密或者提供zip打包的格式，這里就需要額外開發(fā)zip工具類和加解密工具類進行處理。
對賬文件中包含的主要信息有：商戶訂單號、交易流水號、交易時間、支付時間、付款方、交易金額、交易類型、交易狀態(tài)這些字段。
2. 轉換入庫
每個渠道的賬單格式都不盡相同， 在得到賬單后，下一步是對賬單做標準化處理，這樣軋帳以及后續(xù)工作就可以統(tǒng)一處理了。
標準化后的賬單數據可以放在文件系統(tǒng)或者數據庫中，這取決于交易數據量；每天百萬以上的量，還是使用文件系統(tǒng)，比較合適，數據庫操作相對比較慢，也浪費資源。
基于文件系統(tǒng)的標準化涉及如下內容:
文件格式標準化統(tǒng)一使用csv或者json或者xml格式，如果是使用hadoop或者spark來對賬，也可以使用csv。
文件存儲統(tǒng)一化文件目錄，文件名都需要遵循統(tǒng)一命名規(guī)范。
六、對賬單處理
1. 獲取對方對賬單
將事前準備的上游對賬單標準文件放入緩沖對賬池。
2. 獲取我方對賬單
本地交易記錄的準備，總的來說有如下方法:
啥都不做，直接用訂單表的原始數據：鑒于大部分系統(tǒng)使用的是MySQL，這也意味著在MySQL上做對賬。對賬時需要大量的數據查找工作，必然會影響線上業(yè)務。在數據規(guī)模較大，比如超過100萬時，就不太合適了。
使用備庫來執(zhí)行對賬：這樣既簡單，也不影響線上業(yè)務，這是典型的空間換時間的做法。
采用分表分庫對賬：如果業(yè)務大到需要分表分庫才能處理，那對賬數據準備也不一樣。
3. 逐一匹配
前文有提到對賬方式有三種，不對賬、以渠道為準、以平臺為準，大部分的情況下的對賬方式都以渠道為準，信息流的傳遞方向，支付成功結果是由上游渠道通知平臺的，平臺很有可能會因網絡或系統(tǒng)問題而沒有收到通知。
一般按照交易金額、交易狀態(tài)、手續(xù)費金額逐一匹配，對賬方式選擇以渠道為準的處理邏輯為例：
1）交易金額不匹配：記入異常訂單。
2）交易狀態(tài)不匹配：若上游為支付成功，我方為未支付或支付失敗，則以上游為準。
若我方訂單為支付成功，上游只會推送支付成功的訂單為對賬單，上游對賬單不存在的情況，將我方訂單記入為掛賬訂單；
若上游對賬單存在，我方不存在的情況，記入異常訂單。
3）手續(xù)費金額不匹配：記入異常訂單。
4. 掛銷賬處理
常會存在因日切時間點不一致或網絡延時等情況，導致我方平臺訂單時間與上游渠道時間不一致，同一個訂單在渠道交易時間是1月1號，但在平臺是1月2號。
掛賬，對賬時若上游無我方有，訂單放入掛賬訂單中。
銷賬，若匹配中掛賬訂單匹配上了，記錄為當日平臺賬單，掛銷賬狀態(tài)改為已銷賬。
七、差錯處理
關于差錯流程，每個系統(tǒng)的業(yè)務特性、運營團隊流程、公司財務管理辦法不一樣，不能生搬硬套，但原則是一樣的，所有的異常訂單的報銷賬必須有理有據，多重審核。
1. 異常原因
（1）若出現訂單金額不一致的情況，一般是平臺調用上游交易接口時，雙方字段的定義不匹配導致的。
（2）若出現手續(xù)費金額不一致的情況，一般是平臺手續(xù)費計算規(guī)則和上游不匹配導致的，差額不會太大，可以設計閥值若在可以接受的范圍類不計為異常。
（3）若出現上游對賬單存在，平臺訂單不存在的情況，通常是有第三方繞過平臺系統(tǒng)與上游系統(tǒng)發(fā)生支付或退款交易。需要及時核查是否存在交易密鑰泄露或被繞過商戶去上游系統(tǒng)平臺操作。
2. 修正
選擇以平臺為準或以上游為準，修改訂單金額、訂單狀態(tài)、手續(xù)費金額。此時寫入修正原因很重要，便于后期業(yè)務追蹤考求。
3. 平賬
將平臺異常訂單狀態(tài)改為平賬，并將平賬時的時間作為賬單時間，合入至平臺賬單。平臺會根據平臺賬單計算渠道分潤金額和商戶結算金額。
八、業(yè)務規(guī)則系統(tǒng)化
最后，每個平臺產品細節(jié)都會有其特定的業(yè)務規(guī)則，就不具體說明平臺頁面和和平臺操作功能，筆者不做詳情說明。以上業(yè)務規(guī)則系統(tǒng)化，系統(tǒng)流程圖如下，讀者可以結合自己平臺業(yè)務情況提取細化。
