清算核心是什么？文章通過(guò)從系統(tǒng)業(yè)務(wù)流程、系統(tǒng)架構(gòu)和領(lǐng)域模型、業(yè)務(wù)邊界分析和系統(tǒng)邊界分析四個(gè)方面來(lái)解析，一起來(lái)看看~

系統(tǒng)業(yè)務(wù)流程分析

• 第0步由產(chǎn)品層來(lái)實(shí)現(xiàn)各種接受提現(xiàn)請(qǐng)求的場(chǎng)景。
• 第1-1.2步驟歸為支付層處理，支付層的核心是支付協(xié)議，前面講支付核心時(shí)已經(jīng)分析過(guò)，簡(jiǎn)單點(diǎn)說(shuō)：一個(gè)支付協(xié)議可以=一個(gè)賬務(wù)指令+一個(gè)清算指令。其中賬務(wù)指令和清算指令，都是可以進(jìn)行運(yùn)行的最小單位。
• 第1-2.4步，本講中稱作清算平臺(tái)，其中2.2和2.3承擔(dān)的工作叫做通信前置，負(fù)責(zé)指令的發(fā)送，和接受指令的返回，在物理部署上他們將會(huì)是獨(dú)立的通信前置機(jī)器。像使用文件這種人工提交的方式處理的指令2.2和2.3步驟則分別會(huì)被影射到文件生成器，和文件解析器上，也是清算系統(tǒng)和外部進(jìn)行批量交互的核心組件。
• 第3步是清算層處理完畢后的收尾工作，讓支付層知道最后的處理結(jié)果，對(duì)于先扣款的交易來(lái)說(shuō)，這一步的影響僅僅在于兩邊記錄的清算指令最終狀態(tài)的一致性，對(duì)于以后可能出現(xiàn)的其他交易來(lái)說(shuō)，這個(gè)狀態(tài)可能會(huì)決定后續(xù)賬務(wù)處理。

系統(tǒng)架構(gòu)和領(lǐng)域模型

邏輯視圖

部署視圖

• 這里的mix系統(tǒng)職責(zé)是兩塊，一塊是作為復(fù)雜支付渠道的業(yè)務(wù)產(chǎn)品，包括（網(wǎng)點(diǎn)支付、代金卡、COD、MotoPay），一塊是劃入支付層職責(zé)的轉(zhuǎn)帳和分潤(rùn)業(yè)務(wù)。之所以要提出這個(gè)系統(tǒng)，是因?yàn)檫@些復(fù)雜支付渠道的業(yè)務(wù)邏輯被分散在多個(gè)系統(tǒng)中（支付系統(tǒng)、開(kāi)發(fā)平臺(tái)、銀行網(wǎng)關(guān)），而這些在系統(tǒng)中的定位是通信前置，不應(yīng)該包含這些邏輯。所以統(tǒng)一遷到mix系統(tǒng)中。
• Mix系統(tǒng)的使用者有外部前置系統(tǒng)和收銀臺(tái)，外部前置系統(tǒng)提出復(fù)雜支付渠道請(qǐng)求時(shí)，外部前置做了基本的接口校驗(yàn)之后，所有邏輯處理由mix來(lái)負(fù)責(zé)。收銀臺(tái)是支付渠道的發(fā)起者，如果發(fā)起復(fù)雜支付渠道請(qǐng)求，也先轉(zhuǎn)給mix來(lái)處理。
• Mix系統(tǒng)作為復(fù)雜支付渠道的業(yè)務(wù)產(chǎn)品，但完成支付，最終還是調(diào)用支付核心來(lái)完成。與mix后端交互系統(tǒng)，目前只有支付核心。發(fā)起支付請(qǐng)求時(shí)，mix調(diào)用支付核心。支付核心支付完畢之后，業(yè)務(wù)分流給mix系統(tǒng)。
• 清算核心負(fù)責(zé)整體清算模型的運(yùn)轉(zhuǎn)，所有跟外部機(jī)構(gòu)有清算需求的業(yè)務(wù)，都經(jīng)過(guò)清算核心，包括前面提到的復(fù)雜支付渠道。
• 支付核心和清算之間的關(guān)系非常明確，支付核心調(diào)用清算核心進(jìn)行清算請(qǐng)求，清算核心清算完畢之后，反饋給支付核心。
• 清算核心是負(fù)責(zé)整體清算模型，具體的清算指令發(fā)送，是由幾個(gè)通信前置來(lái)完成的。

模型總覽：

清算實(shí)體通用模型：

清算指令和清算文件是多對(duì)一的關(guān)系，核對(duì)并處理過(guò)的清算指令和清算文件處理結(jié)果是多對(duì)一的關(guān)系。以上都和清算通道接口是一對(duì)一的關(guān)系、即不論文件或者指令只有一個(gè)清算通道接口。

渠道類型：

渠道類型和其中一個(gè)維度通信類型是密切相關(guān)的。

渠道類型可以這樣來(lái)劃分：快捷、線下、信用卡、人工、銀企互聯(lián)、B2B、B2C、VISA，MIGS（國(guó)際支付）、COD、代金卡等

清算的各種模式也是和渠道類型分不開(kāi)的，例如：渠道類型為快捷的，統(tǒng)統(tǒng)是使用的實(shí)時(shí)接口，銀企互聯(lián)則采用批量數(shù)據(jù)通過(guò)接口提交的模式，而線下類型則是批量數(shù)據(jù)生成文件來(lái)進(jìn)行提交的。

支付機(jī)構(gòu)內(nèi)部渠道劃分為以下幾類：

銀行卡類型：

清算類型：

清算指令的狀態(tài)：

清算指令的通信狀態(tài)（文件類狀態(tài)）：指令類狀態(tài)。

批量的指令有兩種發(fā)送的實(shí)現(xiàn)模式：

• 落地為文件供結(jié)算人工下載，人工發(fā)送提交。
• 直接通過(guò)和銀行交互的接口批量或者單筆發(fā)送出去。

核心的業(yè)務(wù)邏輯

1. 充值文件內(nèi)清算指令總筆數(shù)=充值清算文件處理結(jié)果總筆數(shù)；
2. 充值文件內(nèi)每筆清算指令金額和狀態(tài)=充值清算文件處理結(jié)果內(nèi)每筆清算指令金額和狀態(tài)；
3. 充退文件內(nèi)清算指令總筆數(shù)=充退清算文件處理結(jié)果的總筆數(shù)；
4. 充退文件內(nèi)每筆清算指令金額和狀態(tài)=充退清算文件處理結(jié)果內(nèi)每筆清算指令金額和狀態(tài)。

業(yè)務(wù)邊界分析

用例總圖：

清算文件處理：

充值回導(dǎo)文件獲取。

充值回導(dǎo)文件有兩種獲取方式：

• 一種是人工去銀行網(wǎng)銀系統(tǒng)去下載，并保存到本地硬盤(pán)，然后通過(guò)工作平臺(tái)提供的上傳功能進(jìn)行上傳。
• 第二種是人工或系統(tǒng)觸發(fā)（系統(tǒng)自動(dòng)觸發(fā)會(huì)是固定時(shí)間點(diǎn)，或者有規(guī)律的時(shí)間段）并由系統(tǒng)通信前置與銀行服務(wù)器進(jìn)行交互拿到回導(dǎo)文件。

我們這里主要指的是第二種。

• 如上圖，我們將會(huì)通過(guò)標(biāo)準(zhǔn)接口和通信前置交互獲取到文件，實(shí)際保存動(dòng)作由通信前置完成，保存完成后將文件路徑返回給清算文件處理模塊。通信前置獲取到文件后，要把純文件信息保存到數(shù)據(jù)庫(kù)中。
• 在文件被解析成功后將數(shù)據(jù)導(dǎo)入SETTLE_BANK_RETURN表，同時(shí)將文件摘要信息保存到SETTLE_BANK_RETURN_BATCH表。
• 通信前置需要一定的緩存功能，比如：一些銀行多種業(yè)務(wù)一個(gè)文件返回的，那么通信前置需要能區(qū)分出來(lái)，不要去請(qǐng)求銀行多次。

清算文件處理

充值回導(dǎo)文件解析：

• 見(jiàn)上圖，我們要把解析腳本內(nèi)容保存到數(shù)據(jù)庫(kù)，直接讀取數(shù)據(jù)庫(kù)中的內(nèi)容，這樣方便管理和更新。
• 每一個(gè)文件解析腳本和文件模板都需要仔細(xì)開(kāi)發(fā)。

充值回導(dǎo)文件導(dǎo)入：文件解析完成后，需要把數(shù)據(jù)對(duì)象存儲(chǔ)到數(shù)據(jù)庫(kù)中，對(duì)于充值來(lái)說(shuō)業(yè)務(wù)關(guān)鍵字段和提現(xiàn)一樣：充值訂單號(hào)和充值金額。

充值回導(dǎo)文件對(duì)賬：

• 對(duì)賬需要在導(dǎo)入后進(jìn)行觸發(fā)，可以是人工觸發(fā)，也可以是系統(tǒng)自動(dòng)觸發(fā)，也可以在導(dǎo)入后立即系統(tǒng)自動(dòng)觸發(fā)對(duì)賬。系統(tǒng)將提供接口供工作平臺(tái)調(diào)用或者系統(tǒng)自己調(diào)用。
• 系統(tǒng)觸發(fā)可以配置成一個(gè)定時(shí)執(zhí)行任務(wù)，這樣可以把實(shí)時(shí)要做的事情變成異步確保會(huì)做的事情，將使用到定時(shí)預(yù)約的系統(tǒng)功能，在定時(shí)查詢中有講這個(gè)工具。

通用的對(duì)賬流程如下圖：

銀行通信前置：主要涉及到的工作是網(wǎng)銀對(duì)指令的簽名、校驗(yàn)簽名以及報(bào)文服務(wù)費(fèi)與清算核心的對(duì)接，還有獲取對(duì)賬文件的對(duì)接。

清算指令處理：

指令的清算結(jié)果狀態(tài)：

清算指令的通信狀態(tài)（文件類狀態(tài)）：

指令類狀態(tài)：批量的指令有兩種發(fā)送的實(shí)現(xiàn)模式。

• 落地為文件供結(jié)算人工下載，人工發(fā)送提交。
• 直接通過(guò)和銀行交互的接口批量或者單筆發(fā)送出去。

內(nèi)部服務(wù)管理：

指令處理時(shí)序圖：

系統(tǒng)邊界分析

經(jīng)過(guò)前期對(duì)業(yè)務(wù)上的一些認(rèn)識(shí)，目前產(chǎn)品可以分為三大類：網(wǎng)銀異步模式、直連模式、其它個(gè)性化模式。

• 網(wǎng)銀異步模式包含：B2B、B2C、VISA、MIGS這些有支付機(jī)構(gòu)和銀行頁(yè)面展示的，銀行端需要用戶輸入賬號(hào)密碼進(jìn)行支付的業(yè)務(wù)。
• 直連模式包含：網(wǎng)匯E、快捷這些通過(guò)某種協(xié)議只需要在網(wǎng)站確認(rèn)就可以進(jìn)行支付的業(yè)務(wù)。
• 其它個(gè)性化模式包含：MOTO、線下網(wǎng)點(diǎn)金融機(jī)構(gòu)、信用卡還款、COD貨到付款、代金卡、電話支付這些屬于清算但是模型很復(fù)雜的業(yè)務(wù)。

直連模式：

網(wǎng)銀異步模式：

本文由 @支付學(xué)院 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議