各位小伙伴大家好！

支付系統(tǒng)有三大黑盒“清結(jié)算對(duì)賬、支付引擎和賬務(wù)系統(tǒng)”，之所以說(shuō)是黑盒一來(lái)是因?yàn)樗麄兩畈睾笈_(tái)很少被人看到，二來(lái)是有會(huì)計(jì)知識(shí)的門(mén)檻。這篇文章就用盡可能大白話的語(yǔ)言來(lái)介紹三個(gè)黑盒之一的“支付引擎”。

一、什么是支付引擎

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

圖1：支付引擎的位置

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

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

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

1.2、日終核算：

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

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

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

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

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

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

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

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

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

2.2、核心流程

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

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

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

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

2）支付前置處理

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

3）支付引擎處理

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

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

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

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

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

6）對(duì)賬中心的處理

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

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

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

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

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

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

服務(wù)流程有兩種觸發(fā)方式，一種是通過(guò)外部指令的主動(dòng)觸發(fā)，一種是通過(guò)清分場(chǎng)次來(lái)定時(shí)觸發(fā)任務(wù)。

2）指令解析

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

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

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

3）生成指令

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

2.3.2、支付訂單模型

圖5：支付訂單ER圖

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

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

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

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

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

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

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

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

圖8：支付引擎策略模型

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

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

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

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

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

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

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

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

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

3.1、入款處理流程

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

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

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

3.2、退款處理流程

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

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

3.3、出款處理流程

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

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

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

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

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

4.2、服務(wù)流程：

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

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

圖14：流程設(shè)置

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

4.3、清分場(chǎng)次：

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

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

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

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

4.4.1、協(xié)議賬號(hào)

圖16：協(xié)議賬號(hào)

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

4.4.2、結(jié)算周期

圖17：結(jié)算周期

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

4.5、清分規(guī)則

圖18：清分規(guī)則

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

4.5.1、內(nèi)場(chǎng)條款

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

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

4.5.2、外場(chǎng)條款

圖20：外場(chǎng)條款

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

不炒幣、不空投、不兌換、沒(méi)代理