支付的動力引擎

各位小伙伴大家好！

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

一、什么是支付引擎

支付引擎又被稱為支付核心，他是支付系統的后臺調度者，他負責本地賬務的處理和跨行資金清分。并且支付引擎要能夠承受每天百萬筆的交易量和處理上億的資金，因此他需要又快又準。

圖1：支付引擎的位置

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

1.1、聯機交易：

他承上啟下負責將交易請求發送到賬務中心記賬和渠道清分，使得這筆交易的資金和賬務實現最終一致。

1.2、日終核算：

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

二、支付引擎的設計 2.1、業務架構

圖2：支付引擎業務架構圖

支付引擎采用了分層的架構設計，支付前置接收交易訂單和預處理；支付引擎負責核心賬務邏輯的處理。

2.1.1、支付前置（業務場景過濾）

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

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

2.1.2、支付引擎（專注賬務處理）

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

2.2、核心流程

支付引擎、賬務中心、對賬中心三者共同組成了支付核心系統。支付引擎在其中起到了核心調度者的作用。

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

1）賬務交易觸發

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

2）支付前置處理

支付前置負責報文解析、風控檢查、費用計算等業務預處理，然后將指令轉發給支付引擎進行賬務處理。如果在風控檢查階段被攔截將直接撤銷訂單，返回給前臺結果信息。

3）支付引擎處理

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

4）內場和外場處理

支付引擎調用外部賬務系統和支付系統稱之為出場，出場還分為內場和外場，內場負責賬務中心記賬，外場負責支付渠道的清分。內外場相互配合完成資金和賬務的最終一致。

5）賬務中心的處理

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

6）對賬中心的處理

支付引擎為對賬中心提供成功結算的入賬數據，對賬中心也通過支付引擎來進行調賬和期末的結轉平賬操作。

2.3、業務模型

支付引擎分為驅動業務流轉的服務模型和指令傳遞的訂單模型。

2.3.1、支付服務模型

圖4：支付服務ER模型

1）服務觸發

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

2）指令解析

支付服務首先會解析請求，然后創建指令來調用服務，

3）服務的執行

服務內部采用了流程化的處理方式，而流程則通過狀態機來控制。狀態機把每一次出場作為一個服務步點，出場的支付結果作為下一個步點的執行條件，如此循環往復直至支付完成。

3）生成指令

出場指令的生成，就根據參與者結算協議、清分規則生成清結算條款。內場條款是會計分錄，外場條款是交易金額。

2.3.2、支付訂單模型

圖5：支付訂單ER圖

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

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

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

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

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

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

圖6：支付服務路由策略

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

圖8：支付引擎策略模型

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

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

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

三、支付引擎服務流程

支付引擎采用流程化的服務處理方式，可以調用一個服務的主流程順序執行，也能直接訪問服務節點單步執行。為了流程能夠靈活的流轉，支付引擎采用了“交易步點+指令狀態”的方式來順序執行。

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

2）指令狀態：就是個子服務執行指令的結果是“成功”還是“失敗”。

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

當然現在很多開發平臺做成了更加方便的低碼平臺，可以用鼠標拖拽流程節點和設置分支邏輯。

3.1、入款處理流程

圖9：入款處理流程和清結算指令

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

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

3.2、退款處理流程

圖10：退款流程和清結算指令

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

3.3、出款處理流程

圖11：出款流程和清結算指令

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

四、支付引擎交互設計 4.1、支付引擎交互主流程

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

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

4.2、服務流程：

圖13：服務流程配置

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

圖14：流程設置

每個流程節點可以單獨配置，內容包括對應的清算規則和下一步要執行的流程。當然現在比較流行的是采用可視化的拖拽方式來配置服務處理流程。

4.3、清分場次：

圖15：入款業務清分場次

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

4.4、結算協議：

結算協議包含了賬務處理的默認賬號，以及不同交易的結算周期。

4.4.1、協議賬號

圖16：協議賬號

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

4.4.2、結算周期

圖17：結算周期

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

4.5、清分規則

圖18：清分規則

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

4.5.1、內場條款

圖19：內場條款

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

4.5.2、外場條款

圖20：外場條款

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

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