起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識深度解析：什么是清算核心？
清算核心是什么？文章通過從系統業務流程、系統架構和領域模型、業務邊界分析和系統邊界分析四個方面來解析，一起來看看~
系統業務流程分析
- 第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協議
支付學院是由Ping++出品的支付知識平臺
清算指令是指什么，能具體描述下么
有質量的文章，繼續贊賞。希望還能看到更多有干貨成體系的文章
?? 多謝支持