各位小伙伴大家好！

支付系統(tǒng)有三大黑盒“清結(jié)算對賬、支付引擎和賬務(wù)系統(tǒng)”，之所以說是黑盒一來是因為他們深藏后臺很少被人看到，二來是有會計知識的門檻。這篇文章就用盡可能大白話的語言來介紹三個黑盒之一的“支付引擎”。

一、什么是支付引擎

支付引擎又被稱為支付核心，他是支付系統(tǒng)的后臺調(diào)度者，他負(fù)責(zé)本地賬務(wù)的處理和跨行資金清分。并且支付引擎要能夠承受每天百萬筆的交易量和處理上億的資金，因此他需要又快又準(zhǔn)。

圖1：支付引擎的位置

從上圖可以看到，支付引擎處于后臺中間的位置，他是聯(lián)機(jī)交易和日終核算的調(diào)度者。

1.1、聯(lián)機(jī)交易：

他承上啟下負(fù)責(zé)將交易請求發(fā)送到賬務(wù)中心記賬和渠道清分，使得這筆交易的資金和賬務(wù)實現(xiàn)最終一致。

1.2、日終核算：

他為對賬中心提供記賬數(shù)據(jù)，輔助對賬中心和賬務(wù)中心完成期末的賬務(wù)核算。（核算就是會計的處理流程。）

二、支付引擎的設(shè)計 2.1、業(yè)務(wù)架構(gòu)

圖2：支付引擎業(yè)務(wù)架構(gòu)圖

支付引擎采用了分層的架構(gòu)設(shè)計，支付前置接收交易訂單和預(yù)處理；支付引擎負(fù)責(zé)核心賬務(wù)邏輯的處理。

2.1.1、支付前置（業(yè)務(wù)場景過濾）

支付前置負(fù)責(zé)請求訂單的解析、風(fēng)控的檢查和算費處理，其目讓支付引擎更加高效的處理賬務(wù)結(jié)算和渠道清分邏輯。

支付前置對外提供的可訪問的接口是具有業(yè)務(wù)含義的，例如“充值、收單、快捷支付、網(wǎng)銀支付、條碼支付”等，支付前置根據(jù)不同交易去校驗充值的同名、收單的商戶交易風(fēng)險、快捷的卡bin信息等，然后按照不同支付產(chǎn)品的賬務(wù)要求來向支付引擎發(fā)送指令。

2.1.2、支付引擎（專注賬務(wù)處理）

支付引擎負(fù)責(zé)核心的賬務(wù)邏輯處理，這里的賬務(wù)包含了賬務(wù)結(jié)算的會計分錄和渠道清分的交易金額。因此他對外提供的都是原子化接口，例如上面所說的“充值、收單”支付引擎統(tǒng)一按“入款”賬務(wù)邏輯處理，是否同名只是收付款雙方賬號的填寫區(qū)別，這些都在支付前置預(yù)處理階段檢查過了。

2.2、核心流程

支付引擎、賬務(wù)中心、對賬中心三者共同組成了支付核心系統(tǒng)。支付引擎在其中起到了核心調(diào)度者的作用。

圖3：支付核心的處理流程

1）賬務(wù)交易觸發(fā)

觸發(fā)支付引擎的賬務(wù)交易有兩種啟動方式，一種是通過交易和收銀臺主動調(diào)用支付引擎（圖中1.1、1.2）。另一種是配置清分場次來定時進(jìn)行“自動結(jié)算、渠道清算、結(jié)算到卡”等周期性結(jié)算業(yè)務(wù)。

2）支付前置處理

支付前置負(fù)責(zé)報文解析、風(fēng)控檢查、費用計算等業(yè)務(wù)預(yù)處理，然后將指令轉(zhuǎn)發(fā)給支付引擎進(jìn)行賬務(wù)處理。如果在風(fēng)控檢查階段被攔截將直接撤銷訂單，返回給前臺結(jié)果信息。

3）支付引擎處理

支付引擎就負(fù)責(zé)賬務(wù)邏輯，記賬的賬戶信息來源于用戶的“結(jié)算協(xié)議”，記賬分錄和渠道交易金額來源于“清分規(guī)則”。

4）內(nèi)場和外場處理

支付引擎調(diào)用外部賬務(wù)系統(tǒng)和支付系統(tǒng)稱之為出場，出場還分為內(nèi)場和外場，內(nèi)場負(fù)責(zé)賬務(wù)中心記賬，外場負(fù)責(zé)支付渠道的清分。內(nèi)外場相互配合完成資金和賬務(wù)的最終一致。

5）賬務(wù)中心的處理

賬務(wù)中心負(fù)責(zé)支付引擎發(fā)送的賬務(wù)指令的處理。需要注意的是為了滿足互聯(lián)網(wǎng)用戶高并發(fā)的要求，賬務(wù)中心采用資金和賬務(wù)分開處理的方式，實時更新客戶賬戶的資金余額，異步來登記明細(xì)賬務(wù)和更新內(nèi)部分戶賬余額（詳細(xì)的實現(xiàn)原理我們下次“賬務(wù)核心”模塊單獨介紹）。

6）對賬中心的處理

支付引擎為對賬中心提供成功結(jié)算的入賬數(shù)據(jù)，對賬中心也通過支付引擎來進(jìn)行調(diào)賬和期末的結(jié)轉(zhuǎn)平賬操作。

2.3、業(yè)務(wù)模型

支付引擎分為驅(qū)動業(yè)務(wù)流轉(zhuǎn)的服務(wù)模型和指令傳遞的訂單模型。

2.3.1、支付服務(wù)模型

圖4：支付服務(wù)ER模型

1）服務(wù)觸發(fā)

服務(wù)流程有兩種觸發(fā)方式，一種是通過外部指令的主動觸發(fā)，一種是通過清分場次來定時觸發(fā)任務(wù)。

2）指令解析

支付服務(wù)首先會解析請求，然后創(chuàng)建指令來調(diào)用服務(wù)，

3）服務(wù)的執(zhí)行

服務(wù)內(nèi)部采用了流程化的處理方式，而流程則通過狀態(tài)機(jī)來控制。狀態(tài)機(jī)把每一次出場作為一個服務(wù)步點，出場的支付結(jié)果作為下一個步點的執(zhí)行條件，如此循環(huán)往復(fù)直至支付完成。

3）生成指令

出場指令的生成，就根據(jù)參與者結(jié)算協(xié)議、清分規(guī)則生成清結(jié)算條款。內(nèi)場條款是會計分錄，外場條款是交易金額。

2.3.2、支付訂單模型

圖5：支付訂單ER圖

支付訂單和指令分成了四層：

1、交易層：接受交易系統(tǒng)和收銀臺發(fā)起支付請求。每一筆請求都會生成一筆支付訂單。

2、前置層：解析支付訂單中的“產(chǎn)品編碼、支付方式、交易類型”來生成支付指令，推送支付引擎進(jìn)行賬務(wù)處理。（詳細(xì)的解析過程見《支付引擎服務(wù)流程》）

3、核心層：用來生成記賬信息和渠道清分信息。

4、接觸層：按支付流程分別訪問賬務(wù)中心和支付渠道。

為什么不拆分“收、付、退”子單？ 因為支付引擎只關(guān)注賬務(wù)處理，這些場景在指令層面只有“賬務(wù)和流程”的參數(shù)的不同而已，這樣的設(shè)計一套指令就能適應(yīng)不同場景的賬務(wù)要求。當(dāng)然如果考慮更高的性能要求，可以將其單獨拆分子單來記錄，但指令信息是差不多的。

圖6：支付服務(wù)路由策略

支付引擎的策略模型是通過對訂單因子的解析來路由目標(biāo)服務(wù)，服務(wù)運(yùn)行前為服務(wù)加載清結(jié)算參數(shù)?？梢钥吹皆谡麄€策略路由過程中過濾掉了業(yè)務(wù)信息，只留下了賬務(wù)信息和需要調(diào)用的服務(wù)節(jié)點。

圖8：支付引擎策略模型

當(dāng)訂單因子在支付前置解析時，交易類型都被轉(zhuǎn)化成“入款、出款、退款”等具有賬務(wù)含義的支付類型。因為，這些交易在賬務(wù)層面都是一樣的，只是填寫的收/付款方賬號不同而已。

同時支付方式“快捷B2C借記、網(wǎng)銀B2C貸記”等類型也統(tǒng)一歸類為“快捷、網(wǎng)銀、條碼”等支付模式，因為對支付引擎來說他們只是調(diào)用渠道的流程有所不同，卡類型、公私標(biāo)志對流程沒有任何影響。

從上面這些過濾方式我們可以更加清晰的理解到“支付引擎只關(guān)注賬務(wù)信息和跨行收付款”這個定義。

三、支付引擎服務(wù)流程

支付引擎采用流程化的服務(wù)處理方式，可以調(diào)用一個服務(wù)的主流程順序執(zhí)行，也能直接訪問服務(wù)節(jié)點單步執(zhí)行。為了流程能夠靈活的流轉(zhuǎn)，支付引擎采用了“交易步點+指令狀態(tài)”的方式來順序執(zhí)行。

1）交易步點：就是支付流程處理的每個一子服務(wù)。

2）指令狀態(tài)：就是個子服務(wù)執(zhí)行指令的結(jié)果是“成功”還是“失敗”。

每個流程都有一個“初始”節(jié)點，作為流程的入口節(jié)點，同時初始節(jié)點也會創(chuàng)建一個新的支付指令。每個流程節(jié)點處理的結(jié)果決定下一步走哪個子節(jié)點。

當(dāng)然現(xiàn)在很多開發(fā)平臺做成了更加方便的低碼平臺，可以用鼠標(biāo)拖拽流程節(jié)點和設(shè)置分支邏輯。

3.1、入款處理流程

圖9：入款處理流程和清結(jié)算指令

入款流程是先訪問外部渠道，再完成內(nèi)部賬務(wù)處理。因此他有三個分支“支付成功、支付失敗和支付撤銷”，其中只有支付成功會涉及賬務(wù)處理。日終對賬后會完成渠道的匯總結(jié)轉(zhuǎn)。

上圖中“支付”是一筆指令，而“初始、申請、成功”是這筆指令控制的服務(wù)步點，結(jié)算和結(jié)轉(zhuǎn)也是如此。

3.2、退款處理流程

圖10：退款流程和清結(jié)算指令

退款業(yè)務(wù)是先從客戶賬戶扣款，渠道退款成功則入待清算賬戶，退款失敗則把錢退回客戶賬戶。退款一般都是和正向交易配套出現(xiàn)的，簡單的收單有通用的退款處理，復(fù)雜組合支付需要做資金來源的退款。

3.3、出款處理流程

圖11：出款流程和清結(jié)算指令

出款流程與退款賬務(wù)處理方式類似，先扣客戶賬戶然后渠道完成出款，如果失敗則返還客戶賬。

四、支付引擎交互設(shè)計 4.1、支付引擎交互主流程

圖12：支付引擎交互主流程

支付引擎的核心是圍繞支付服務(wù)展開的，他可以通過指令直接觸發(fā)，也能通過配置的清算場次來觸發(fā)。在流程處理過程中會獲取默認(rèn)的賬號模版來生成相應(yīng)的會計分錄訪問賬務(wù)核心，以及交易金額來調(diào)用支付渠道。

4.2、服務(wù)流程：

圖13：服務(wù)流程配置

支付引擎采用流程化的配置方式，按照服務(wù)編碼和支付類型來訪問對應(yīng)的服務(wù)節(jié)點。訪問支付服務(wù)可以通過“初始”節(jié)點作為主流程的入口程序，然后順序的訪問子流程。當(dāng)然也可以直接填寫子流程編碼直接訪問。

圖14：流程設(shè)置

每個流程節(jié)點可以單獨配置，內(nèi)容包括對應(yīng)的清算規(guī)則和下一步要執(zhí)行的流程。當(dāng)然現(xiàn)在比較流行的是采用可視化的拖拽方式來配置服務(wù)處理流程。

4.3、清分場次：

圖15：入款業(yè)務(wù)清分場次

前面介紹的是實時觸發(fā)流程的執(zhí)行方式，當(dāng)然也有定時觸發(fā)的執(zhí)行方式。例如期末核算、下發(fā)對賬文件、商戶資金的結(jié)算到卡等都可以通過場次的方式來配置不同提交和執(zhí)行頻次。

4.4、結(jié)算協(xié)議：

結(jié)算協(xié)議包含了賬務(wù)處理的默認(rèn)賬號，以及不同交易的結(jié)算周期。

4.4.1、協(xié)議賬號

圖16：協(xié)議賬號

存放填寫會計分錄時所使用的賬號，因為有些賬號只有在交易運(yùn)行的時候才能獲取到，例如“會員賬號”、“機(jī)構(gòu)待清算賬戶”等，因此可以在這里用參與方角色的方式來表示這些賬號如何取值。

4.4.2、結(jié)算周期

圖17：結(jié)算周期

填寫每類交易的結(jié)算周期，例如充值、收單、提現(xiàn)等需要實時處理。提現(xiàn)次日到賬等需要T+1日來執(zhí)行。

4.5、清分規(guī)則

圖18：清分規(guī)則

清分規(guī)則就是內(nèi)場和外場的賬務(wù)處理規(guī)則。例如上圖給入款類賬務(wù)處理設(shè)置一個“入款類條款”針對不同的清算代碼設(shè)置賬務(wù)處理規(guī)則。服務(wù)運(yùn)行的時候會通過清算代碼來執(zhí)行這些規(guī)則。

4.5.1、內(nèi)場條款

圖19：內(nèi)場條款

內(nèi)場條款就是向“賬務(wù)中心”進(jìn)行記賬處理的會計分錄。他通過套號來管理這些記賬分錄，其中“會員賬號、機(jī)構(gòu)清算戶”這些運(yùn)行時才能明確的賬號，用角色來替代。固定的內(nèi)部過渡戶直接填寫相應(yīng)的賬號即可。

4.5.2、外場條款

圖20：外場條款

【加我入群，注明"所屬行業(yè)+地點"】

不炒幣、不空投、不兌換、沒代理