清算核心是什麼？文章通過從系統業務流程、系統架構和領域模型、業務邊界分析和系統邊界分析四個方面來解析，一起來看看~
系統業務流程分析
第0步由產品層來實現各種接受提現請求的場景。第1-1.2步驟歸為支付層處理，支付層的核心是支付協議，前面講支付核心時已經分析過，簡單點說：一個支付協議可以=一個帳務指令+一個清算指令。其中帳務指令和清算指令，都是可以進行運行的最小單位。第1-2.4步，本講中稱作清算平臺，其中2.2和2.3承擔的工作叫做通信前置，負責指令的發送，和接受指令的返回，在物理部署上他們將會是獨立的通信前置機器。像使用文件這種人工提交的方式處理的指令2.2和2.3步驟則分別會被影射到文件生成器，和文件解析器上，也是清算系統和外部進行批量交互的核心組件。第3步是清算層處理完畢後的收尾工作，讓支付層知道最後的處理結果，對於先扣款的交易來說，這一步的影響僅僅在於兩邊記錄的清算指令最終狀態的一致性，對於以後可能出現的其他交易來說，這個狀態可能會決定後續帳務處理。
系統架構和領域模型
邏輯視圖
部署視圖
這裡的mix系統職責是兩塊，一塊是作為複雜支付渠道的業務產品，包括（網點支付、代金卡、COD、MotoPay），一塊是劃入支付層職責的轉帳和分潤業務。之所以要提出這個系統，是因為這些複雜支付渠道的業務邏輯被分散在多個系統中（支付系統、開發平臺、銀行網關），而這些在系統中的定位是通信前置，不應該包含這些邏輯。所以統一遷到mix系統中。Mix系統的使用者有外部前置系統和收銀臺，外部前置系統提出複雜支付渠道請求時，外部前置做了基本的接口校驗之後，所有邏輯處理由mix來負責。收銀臺是支付渠道的發起者，如果發起複雜支付渠道請求，也先轉給mix來處理。Mix系統作為複雜支付渠道的業務產品，但完成支付，最終還是調用支付核心來完成。與mix後端交互系統，目前只有支付核心。發起支付請求時，mix調用支付核心。支付核心支付完畢之後，業務分流給mix系統。清算核心負責整體清算模型的運轉，所有跟外部機構有清算需求的業務，都經過清算核心，包括前面提到的複雜支付渠道。支付核心和清算之間的關係非常明確，支付核心調用清算核心進行清算請求，清算核心清算完畢之後，反饋給支付核心。清算核心是負責整體清算模型，具體的清算指令發送，是由幾個通信前置來完成的。
模型總覽：
清算實體通用模型：
清算指令和清算文件是多對一的關係，核對並處理過的清算指令和清算文件處理結果是多對一的關係。以上都和清算通道接口是一對一的關係、即不論文件或者指令只有一個清算通道接口。
渠道類型：
渠道類型和其中一個維度通信類型是密切相關的。
渠道類型可以這樣來劃分：快捷、線下、信用卡、人工、銀企互聯、B2B、B2C、VISA，MIGS（國際支付）、COD、代金卡等
清算的各種模式也是和渠道類型分不開的，例如：渠道類型為快捷的，統統是使用的實時接口，銀企互聯則採用批量數據通過接口提交的模式，而線下類型則是批量數據生成文件來進行提交的。
支付機構內部渠道劃分為以下幾類：
銀行卡類型：
清算類型：
清算指令的狀態：
清算指令的通信狀態（文件類狀態）：指令類狀態。
批量的指令有兩種發送的實現模式：
落地為文件供結算人工下載，人工發送提交。直接通過和銀行交互的接口批量或者單筆發送出去。
核心的業務邏輯
充值文件內清算指令總筆數=充值清算文件處理結果總筆數；充值文件內每筆清算指令金額和狀態=充值清算文件處理結果內每筆清算指令金額和狀態；充退文件內清算指令總筆數=充退清算文件處理結果的總筆數；充退文件內每筆清算指令金額和狀態=充退清算文件處理結果內每筆清算指令金額和狀態。
業務邊界分析
用例總圖：
清算文件處理：
充值回導文件獲取。
充值回導文件有兩種獲取方式：
一種是人工去銀行網銀系統去下載，並保存到本地硬碟，然後通過工作平臺提供的上傳功能進行上傳。第二種是人工或系統觸發（系統自動觸發會是固定時間點，或者有規律的時間段）並由系統通信前置與銀行伺服器進行交互拿到回導文件。
我們這裡主要指的是第二種。
如上圖，我們將會通過標準接口和通信前置交互獲取到文件，實際保存動作由通信前置完成，保存完成後將文件路徑返回給清算文件處理模塊。通信前置獲取到文件後，要把純文件信息保存到資料庫中。在文件被解析成功後將數據導入SETTLE_BANK_RETURN表，同時將文件摘要信息保存到SETTLE_BANK_RETURN_BATCH表。通信前置需要一定的緩存功能，比如：一些銀行多種業務一個文件返回的，那麼通信前置需要能區分出來，不要去請求銀行多次。
清算文件處理
充值回導文件解析：
見上圖，我們要把解析腳本內容保存到資料庫，直接讀取資料庫中的內容，這樣方便管理和更新。每一個文件解析腳本和文件模板都需要仔細開發。
充值回導文件導入：文件解析完成後，需要把數據對象存儲到資料庫中，對於充值來說業務關鍵欄位和提現一樣：充值訂單號和充值金額。
充值回導文件對帳：
對帳需要在導入後進行觸發，可以是人工觸發，也可以是系統自動觸發，也可以在導入後立即系統自動觸發對帳。系統將提供接口供工作平臺調用或者系統自己調用。系統觸發可以配置成一個定時執行任務，這樣可以把實時要做的事情變成異步確保會做的事情，將使用到定時預約的系統功能，在定時查詢中有講這個工具。
通用的對帳流程如下圖：
銀行通信前置：主要涉及到的工作是網銀對指令的籤名、校驗籤名以及報文服務費與清算核心的對接，還有獲取對帳文件的對接。
清算指令處理：
指令的清算結果狀態：
清算指令的通信狀態（文件類狀態）：
指令類狀態：批量的指令有兩種發送的實現模式。
內部服務管理：
指令處理時序圖：
系統邊界分析
經過前期對業務上的一些認識，目前產品可以分為三大類：網銀異步模式、直連模式、其它個性化模式。
網銀異步模式包含：B2B、B2C、VISA、MIGS這些有支付機構和銀行頁面展示的，銀行端需要用戶輸入帳號密碼進行支付的業務。直連模式包含：網匯E、快捷這些通過某種協議只需要在網站確認就可以進行支付的業務。其它個性化模式包含：MOTO、線下網點金融機構、信用卡還款、COD貨到付款、代金卡、電話支付這些屬於清算但是模型很複雜的業務。
直連模式：
網銀異步模式：
本文由 @支付學院 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議