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

一、什么是支付引擎

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

圖1：支付引擎的位置

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

1.1 聯(lián)機交易

他承上啟下負責(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ù)處理；支付引擎負責(zé)核心賬務(wù)邏輯的處理。

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

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

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

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

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

2.2 核心流程

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

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

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

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

2）支付前置處理

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

3）支付引擎處理

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

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

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

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

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

6）對賬中心的處理

支付引擎為對賬中心提供成功結(jié)算的入賬數(shù)據(jù)，對賬中心也通過支付引擎來進行調(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)機來控制。狀態(tài)機把每一次出場作為一個服務(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)品編碼、支付方式、交易類型”來生成支付指令，推送支付引擎進行賬務(wù)處理。（詳細的解析過程見《支付引擎服務(wù)流程》）

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

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

為什么不拆分“收、付、退”子單？

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

2.3.3 支付策略模型

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

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

圖7：支付引擎策略模型

當(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ù)狀態(tài)。

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 入款處理流程

圖8：入款類處理流程（小程序）

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

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

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

3.2 退款處理流程

圖10：出款類處理流程

圖11：退款步點和清結(jié)算指令

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

3.3 出款處理流程

圖12：出款類處理流程

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

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

四、支付引擎交互設(shè)計

4.1 支付引擎交互主流程

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

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

圖15：支付引擎功能清單

4.2 服務(wù)流程

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

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

圖17：流程設(shè)置

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

4.3 清分場次

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

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

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

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

4.4.1 協(xié)議賬號

圖19：協(xié)議賬號

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

4.4.2 結(jié)算周期

圖20：結(jié)算周期

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

4.5 清分規(guī)則

圖21：清分規(guī)則

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

4.5.1 內(nèi)場條款

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

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

4.5.2 外場條款

圖23：外場條款

外場條款的賬務(wù)信息則簡單很多，只要填寫參與方角色和交易金額的取值即可。

五、總結(jié)

支付引擎細節(jié)的內(nèi)容比較多，如果要完全掌握支付引擎，“賬務(wù)、支付、技術(shù)”等方面都要掌握。所以對于從事研發(fā)工作的產(chǎn)品和技術(shù)人員來說，了解支付引擎的基本工作原理非常重要。畢竟支付時直接操作“錢”的業(yè)務(wù)。

5.1 什么是支付引擎

作為賬務(wù)中心和支付渠道的驅(qū)動器，其本質(zhì)就是做清分和結(jié)算的賬務(wù)的處理核心系統(tǒng)。

5.2 支付引擎的架構(gòu)

支付引擎追求又快又準(zhǔn)，因此他分為了“支付前置、支付引擎”兩部分。支付前置負責(zé)風(fēng)控、計費、報文轉(zhuǎn)換等支付預(yù)處理。支付引擎負責(zé)指令加工，調(diào)用賬務(wù)中心記賬，調(diào)用資金渠道跨行清分。

5.3 支付服務(wù)的路由

支付引擎只關(guān)心賬務(wù)的處理，因此他會過策略化方式拆解請求訂單來路由目標(biāo)服務(wù)，從而形成支付指令從而實現(xiàn)內(nèi)場賬務(wù)和外場資金的最終一致。

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

5.4 支付處理處理

附圖2：支付引擎的處理流程

支付前置會根據(jù)每一次支付請求生成支付訂單，解析報文生成指令，支付引擎執(zhí)行指令，并按照加載的清結(jié)算規(guī)則生成清結(jié)算指令來驅(qū)動賬務(wù)中心和資金渠道的清結(jié)算處理。

5.5 支付處理流程

附圖3：支付處理流程

支付引擎采用了“交易步點+支付狀態(tài)”的流轉(zhuǎn)方式，初始作為主流程的入口節(jié)點并創(chuàng)建支付指令；每個一個步點負責(zé)內(nèi)場和外場的賬務(wù)處理，每個步點的執(zhí)行結(jié)果決定了下一個交易節(jié)點的執(zhí)行；如此循環(huán)往復(fù)最終完成一筆支付請求的處理。

好啦，今天介紹的內(nèi)容就這么多啦，下次我們介紹另一個黑盒“賬務(wù)中心”歡迎大家圍觀。