文章主要是從八個(gè)方面來(lái)闡述什么是支付核心，它包括了一些什么內(nèi)容？

支付核心：

一、支付核心和清算核心職責(zé)

首先要明確一個(gè)概念：一個(gè)完整的支付清算系統(tǒng)結(jié)構(gòu)內(nèi)，各種特定業(yè)務(wù)所涵蓋的支付服務(wù)、清算服務(wù)，是相互獨(dú)立的。

其獨(dú)立性，體現(xiàn)在具體的產(chǎn)品研發(fā)過(guò)程，以及后期維護(hù)等各項(xiàng)工作中：

1. 這種現(xiàn)狀導(dǎo)致了業(yè)務(wù)產(chǎn)品開(kāi)發(fā)復(fù)雜化、風(fēng)險(xiǎn)性提高；
2. 支付與清算的相關(guān)規(guī)則各自為政，彼此獨(dú)立，加大管理難度；
3. 在開(kāi)放平臺(tái)的大背景下，也不能提供給大量外部業(yè)務(wù)系統(tǒng)所需要的基礎(chǔ)支付服務(wù)；
4. 若清算服務(wù)部署于在后臺(tái)管理系統(tǒng)，各類(lèi)清算細(xì)則繁冗復(fù)雜，對(duì)運(yùn)營(yíng)部門(mén)造成很大不便性。

在設(shè)計(jì)支付清算系統(tǒng)時(shí)建議：

將支付核心和清算核心設(shè)計(jì)為兩層，分為兩個(gè)獨(dú)立子系統(tǒng)。

1. 支付核心提供適應(yīng)各類(lèi)產(chǎn)品使用的基礎(chǔ)支付服務(wù)；
2. 清算核心則將所有機(jī)構(gòu)所能提供的底層清算服務(wù)歸集，專(zhuān)門(mén)負(fù)責(zé)與銀行的各類(lèi)清算接口對(duì)接。

支付層則對(duì)外提供各類(lèi)經(jīng)過(guò)包裝的支付服務(wù)，涵蓋清算服務(wù)、賬務(wù)服務(wù)、客戶(hù)相關(guān)服務(wù)等，實(shí)現(xiàn)對(duì)基礎(chǔ)支付服務(wù)的編排。

二、提現(xiàn)協(xié)議系統(tǒng)業(yè)務(wù)流程分析

前提：以同步/異步的維度劃分提現(xiàn)支付協(xié)議，得出兩類(lèi)提現(xiàn)支付協(xié)議的處理流程。

維度：會(huì)員層、提現(xiàn)產(chǎn)品層、支付層、財(cái)務(wù)核心、清算層、銀行。

（1）同步提現(xiàn)支付協(xié)議處理流程圖

會(huì)員提交提現(xiàn)申請(qǐng)后，進(jìn)入提現(xiàn)產(chǎn)品層申請(qǐng)同步提現(xiàn)支付協(xié)議，然后進(jìn)入支付層請(qǐng)求扣款提現(xiàn)金額。此時(shí)進(jìn)入財(cái)務(wù)核心執(zhí)行扣款，同時(shí)報(bào)送清算請(qǐng)求指令進(jìn)入清算層，報(bào)送銀行處理，然后進(jìn)入銀行執(zhí)行扣款并返回清算結(jié)果。

此時(shí)做一個(gè)判斷，若清算成功則回執(zhí)處理結(jié)果，并回到提現(xiàn)產(chǎn)品層進(jìn)行業(yè)務(wù)處理并通知用戶(hù)提現(xiàn)處理結(jié)束。若清算失敗則進(jìn)入財(cái)務(wù)核心，進(jìn)行回充。

（2）異步提現(xiàn)支付協(xié)議處理流程圖

會(huì)員層提交 T 日申請(qǐng)?zhí)岈F(xiàn)需求后，進(jìn)入提現(xiàn)產(chǎn)品層申請(qǐng)異步提現(xiàn)協(xié)議，然后進(jìn)入支付層：首先請(qǐng)求凍結(jié)提現(xiàn)金額，并進(jìn)入財(cái)務(wù)核心進(jìn)行凍結(jié)；在 T + N 日請(qǐng)求扣款凍結(jié)金額，并進(jìn)入財(cái)務(wù)核心層進(jìn)行扣款，同時(shí)報(bào)送清算請(qǐng)求指令，進(jìn)入清算層進(jìn)行清算指令的記錄并生成清算報(bào)文（文件），再進(jìn)入銀行層執(zhí)行清算。

在 T + N 日，運(yùn)營(yíng)平臺(tái)層執(zhí)行回導(dǎo)清算結(jié)果/文件，進(jìn)入清算層勾兌清算指令并回執(zhí)處理結(jié)果，進(jìn)入支付層進(jìn)行判斷。若清算成功則回執(zhí)處理結(jié)果，并回到提現(xiàn)產(chǎn)品層進(jìn)行業(yè)務(wù)處理并通知用戶(hù)提現(xiàn)處理結(jié)果，若清算失敗則回到清算層進(jìn)行回充。

（3）退票支付協(xié)議的處理流程

這部分內(nèi)容比較容易理解，這里就不做詳解了。

如圖，將支付與交易分開(kāi)，主要是為了體現(xiàn)出支付服務(wù)機(jī)構(gòu)的核心支付服務(wù)功能。

核心支付服務(wù)能夠?yàn)闀?huì)員提供豐富個(gè)性的支付服務(wù)：充值、提現(xiàn)、內(nèi)/外轉(zhuǎn)型支付、支付側(cè)營(yíng)銷(xiāo)等內(nèi)容。

若將交易產(chǎn)品中包裝的相關(guān)支付服務(wù)，交由支付服務(wù)層與清算服務(wù)層協(xié)作完成，并將交易以及其他產(chǎn)品釋放出來(lái)，則產(chǎn)生的整體系統(tǒng)框架圖如下：

三、提現(xiàn)支付協(xié)議領(lǐng)域模型

模型總覽：

通過(guò)對(duì)提現(xiàn)支付協(xié)議、提現(xiàn)支付指令的歸納抽取，得到本模型圖。其中，操作指令部分不對(duì)外暴露。

就提現(xiàn)支付協(xié)議本身，分為同步/異步兩種處理方式：前者將提現(xiàn)支付協(xié)議的申請(qǐng)過(guò)程、處理過(guò)程打包處理；后者則是分階段處理。

提現(xiàn)支付指令里包含了收款方-銀行卡，付款方-支付賬戶(hù)的各自支付工具，依據(jù)此可拆分出相應(yīng)的賬務(wù)類(lèi)操作指令與清算類(lèi)操作指令。

作為提現(xiàn)支付協(xié)議的一種，退票支付協(xié)議也將退票單的申請(qǐng)與處理過(guò)程打包。

• 每 1 提現(xiàn)支付協(xié)議，擁有 1 到多個(gè)明細(xì)項(xiàng)；提支付協(xié)議本身和明細(xì)項(xiàng)信息，是產(chǎn)品在使用支付協(xié)議時(shí)，各專(zhuān)用申請(qǐng)單據(jù)轉(zhuǎn)化而來(lái)，由原始業(yè)務(wù)單據(jù)數(shù)據(jù)經(jīng)過(guò)簡(jiǎn)單加工后得出。
• 每 1 提現(xiàn)支付協(xié)議，擁有 1 到多個(gè)提現(xiàn)支付指令；支付指令是在協(xié)議和協(xié)議明細(xì)項(xiàng)基礎(chǔ)之上加工得出，其具備了進(jìn)行后續(xù)操作處理的全部要素信息，除原始單據(jù)中請(qǐng)求要素外，經(jīng)過(guò)支付層的一系列諸如補(bǔ)全、拆分、檢查之后產(chǎn)生。部分沒(méi)有業(yè)務(wù)數(shù)據(jù)的提現(xiàn)產(chǎn)品，如：正常提現(xiàn)和卡通提現(xiàn)，都是以支付指令作為其產(chǎn)品數(shù)據(jù)。
• 每 1 提現(xiàn)支付指令，擁有 1 到多個(gè)提現(xiàn)操作指令；提現(xiàn)操作指令是真正可被系統(tǒng)處理的，運(yùn)行時(shí)得出的具體操作步驟。具體表現(xiàn)為賬務(wù)相關(guān)、清算相關(guān)，以及其他底層公共服務(wù)的處理單元。
• 為了簡(jiǎn)化提現(xiàn)支付指令與提現(xiàn)支付協(xié)議的從屬關(guān)系，可以直接認(rèn)為每 1 提現(xiàn)支付協(xié)議擁有1到多個(gè)提現(xiàn)支付指令。

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

以在線用戶(hù)發(fā)起的正常提現(xiàn)申請(qǐng)為例，整體的交互時(shí)序圖如下：

支付層內(nèi)部處理的交互時(shí)序圖

提現(xiàn)支付指令作為提現(xiàn)支付協(xié)議的流水?dāng)?shù)據(jù)，其處理生命周期的狀態(tài)遷轉(zhuǎn)如圖所示。

異步提現(xiàn)支付協(xié)議下的提現(xiàn)支付指令狀態(tài)圖

提現(xiàn)退票支付協(xié)議下的提現(xiàn)支付指令狀態(tài)圖

同步提現(xiàn)支付協(xié)議下的提現(xiàn)支付指令狀態(tài)圖

四、提現(xiàn)業(yè)務(wù)邊界分析

首先，提現(xiàn)業(yè)務(wù)邊界分析可以拆分為兩大部分：業(yè)務(wù)用例邊界以及系統(tǒng)用例邊界。

這里著重講一下系統(tǒng)用例邊界，分為：

1. 異步提現(xiàn)支付協(xié)議申請(qǐng)；
2. 異步提現(xiàn)支付協(xié)議推進(jìn)處理；
3. 接受清算處理結(jié)果回執(zhí)；
4. 統(tǒng)一協(xié)議處理結(jié)果回執(zhí)；
5. 同步提現(xiàn)支付協(xié)議申請(qǐng)；
6. 同步提現(xiàn)支付協(xié)議推進(jìn)/恢復(fù)處理；
7. 提現(xiàn)退票支付協(xié)議；
8. 打款機(jī)構(gòu)；
9. 支付能力；
10. 分布式任務(wù)；
11. 公共查詢(xún)類(lèi)服務(wù)：協(xié)議授權(quán)查詢(xún)服務(wù)、機(jī)構(gòu)信息查詢(xún)服務(wù)；
12. 提現(xiàn)查詢(xún)類(lèi)服務(wù)：銀行卡段檢查服務(wù)、對(duì)公賬戶(hù)聯(lián)行號(hào)檢查服務(wù)、支行列表查詢(xún)服務(wù)、清算通道支付限額查詢(xún)服務(wù)；
13. 管理服務(wù)：協(xié)議授權(quán)管理服務(wù)、打款機(jī)構(gòu)管理服務(wù)、支付能力管理服務(wù)、緩存刷新服務(wù)。

1.?業(yè)務(wù)用例邊界

支付層作為提供基礎(chǔ)支付服務(wù)的核心系統(tǒng)，所承擔(dān)的職責(zé)圍繞著以下主要業(yè)務(wù)功能點(diǎn)：

以協(xié)議方式提供適用于各類(lèi)產(chǎn)品使用的支付服務(wù)：

如圖所示，可分為同步提現(xiàn)支付申請(qǐng)協(xié)議、異步提現(xiàn)支付申請(qǐng)協(xié)議以及單筆退票支付申請(qǐng)協(xié)議。

承擔(dān)包裝清算層所公布的各類(lèi)底層公共查詢(xún)服務(wù)，以及獨(dú)立提供給產(chǎn)品層的各類(lèi)公共查詢(xún)服務(wù)：

以提供公共查詢(xún)服務(wù)為職責(zé)，則分為協(xié)議授權(quán)查詢(xún)、提現(xiàn)統(tǒng)計(jì)查詢(xún)、銀行卡段檢查、對(duì)公賬戶(hù)聯(lián)行號(hào)查詢(xún)、機(jī)構(gòu)信息查詢(xún)以及清算通道支付限額查詢(xún)。

作為協(xié)議使用的輔助手段，提供不同協(xié)議的干預(yù)處理服務(wù)：

可提供四種不同的干預(yù)處理服務(wù)：異步提現(xiàn)支付協(xié)議推進(jìn)、異步提現(xiàn)支付協(xié)議取消、同步提現(xiàn)支付協(xié)議推進(jìn)、統(tǒng)一提現(xiàn)支付協(xié)議回執(zhí)。

可供靈活編輯的各種核心處理規(guī)則配置機(jī)制，以及提供配套的規(guī)則管理服務(wù)：

如圖所示，三種不同的管理服務(wù)內(nèi)含不同的核心處理規(guī)則配置機(jī)制：協(xié)議授權(quán)管理服務(wù)、打款機(jī)構(gòu)配置管理服務(wù)、提現(xiàn)支付能力管理服務(wù)。

2.?系統(tǒng)用例邊界

支付服務(wù)層的主要作用：與產(chǎn)品層對(duì)接，暴露各類(lèi)支付協(xié)議以供產(chǎn)品使用，并囊括各協(xié)議的賬務(wù)處理、清算處理、客戶(hù)相關(guān)檢查等部分；釋放產(chǎn)品層與清算服務(wù)層的鏈接，使得后者不受限于具體產(chǎn)品業(yè)務(wù)邏輯，專(zhuān)注于與金融機(jī)構(gòu)的清算過(guò)程。對(duì)于產(chǎn)品層來(lái)說(shuō)，同樣也無(wú)需關(guān)注具體的清算過(guò)程。更方便、更簡(jiǎn)潔。

假設(shè)目前公司的產(chǎn)品層尚未成型，那么現(xiàn)有的各類(lèi)提現(xiàn)相關(guān)產(chǎn)品是分散在各個(gè)子系統(tǒng)中的，在這種情況下：

通過(guò)對(duì)提現(xiàn)產(chǎn)品的提煉，可抽取三種提現(xiàn)支付模式：異步提現(xiàn)模式、同步提現(xiàn)模式以及批量提現(xiàn)模式。其中批量提現(xiàn)模式，是對(duì)前兩者的再組裝、復(fù)用的過(guò)程。因此，在支付服務(wù)層對(duì)提現(xiàn)支付協(xié)議的劃分可根據(jù)同步、異步兩種方式即可得出。

此圖要點(diǎn)：

1. 支付服務(wù)層暴露提現(xiàn)支付協(xié)議給產(chǎn)品使用，貫穿提現(xiàn)業(yè)務(wù)的整體生命周期，提供提現(xiàn)支付協(xié)議申請(qǐng)、推進(jìn)執(zhí)行、取消、查詢(xún)等服務(wù)；其中提現(xiàn)支付協(xié)議的推進(jìn)執(zhí)行入口，主要包括針對(duì)同步提現(xiàn)支付協(xié)議的推進(jìn)處理，和異步提現(xiàn)支付協(xié)議的推進(jìn)處理（例如：生僻字復(fù)核）。
2. 產(chǎn)品希望得到提現(xiàn)支付協(xié)議的處理結(jié)果，支付層需要以統(tǒng)一透明的方式，將提現(xiàn)支付協(xié)議處理結(jié)果，回執(zhí)給特定產(chǎn)品。在產(chǎn)品層需要有統(tǒng)一的接受支付層處理回執(zhí)服務(wù)，在接受到支付層的回執(zhí)之后，此服務(wù)將自行分發(fā)至各特定提現(xiàn)產(chǎn)品進(jìn)行處理。
3. 支付服務(wù)層報(bào)送賬務(wù)請(qǐng)求至賬務(wù)核心，請(qǐng)求賬務(wù)處理，包括充值、提現(xiàn)、支付以及凍結(jié)、解凍等。
4. 支付服務(wù)層請(qǐng)求清算服務(wù)層執(zhí)行清算過(guò)程，與產(chǎn)品層同理，支付服務(wù)層需要得到清算指令的處理結(jié)果來(lái)決定其下一步業(yè)務(wù)處理。對(duì)于差評(píng)層需要取消提現(xiàn)支付協(xié)議的，支付服務(wù)層需要得到清算服務(wù)層允許后方可決定是否取消。所以支付服務(wù)層與清算服務(wù)層的交互有發(fā)送清算指令，接受清算結(jié)果，查詢(xún)清算指令，取消清算指令以及問(wèn)詢(xún)清算指令是否可絮叨等。
5. 退票作為提現(xiàn)支付協(xié)議的方向處理過(guò)程，支付服務(wù)層提供給管理平臺(tái)退票申請(qǐng)入口，將退票作為提現(xiàn)支付協(xié)議的一種特殊類(lèi)型即退票支付協(xié)議看待，與提現(xiàn)支付協(xié)議簡(jiǎn)歷關(guān)聯(lián)。輔以退票支付指令，進(jìn)行會(huì)員賬務(wù)回充等處理。
6. 支付服務(wù)層需要將內(nèi)部各類(lèi)規(guī)則配置釋放給管理平臺(tái)，以便后續(xù)可支持靈活的規(guī)則組合，以達(dá)到各類(lèi)支付協(xié)議業(yè)務(wù)敏捷的目的。

（1）異步提現(xiàn)支付協(xié)議申請(qǐng)

作為提現(xiàn)支付協(xié)議中最為基礎(chǔ)的一種，異步提現(xiàn)支付協(xié)議適用于現(xiàn)有各類(lèi)非實(shí)時(shí)處理的提現(xiàn)產(chǎn)品，如：正常提現(xiàn)、認(rèn)證提現(xiàn)、委托提現(xiàn)等。

參照提現(xiàn)支付協(xié)議認(rèn)領(lǐng)模型設(shè)計(jì)，產(chǎn)品層可將異步提現(xiàn)支付協(xié)議的使用分為：申請(qǐng)、推進(jìn)處理兩個(gè)階段，以及特殊情況下的取消操作。

本文重點(diǎn)描述異步提現(xiàn)支付協(xié)議，在申請(qǐng)過(guò)程中支付層的體系結(jié)構(gòu)以及處理流程。

需要重點(diǎn)指出的是，支付層所提供的協(xié)議申請(qǐng)使用嵌套分布式事物，在此將申請(qǐng)過(guò)程分為兩個(gè)階段處理：

階段一：

調(diào)用者開(kāi)啟分布式事務(wù)，在事務(wù)塊內(nèi)請(qǐng)求異步提現(xiàn)支付協(xié)議申請(qǐng)：

1. 整合現(xiàn)有各類(lèi)非實(shí)時(shí)處理類(lèi)提現(xiàn)產(chǎn)品要素，設(shè)計(jì)專(zhuān)用的申請(qǐng)單據(jù)對(duì)象；異步提現(xiàn)支付協(xié)議支持每次申請(qǐng)單筆或批量明細(xì)項(xiàng)；
2. 通過(guò)內(nèi)部的業(yè)務(wù)接入層將專(zhuān)用單據(jù)轉(zhuǎn)換成統(tǒng)一的內(nèi)部領(lǐng)域模型對(duì)象；
3. 對(duì)領(lǐng)域模型對(duì)象加工，包括補(bǔ)全、拆分、檢查等；
4. 啟動(dòng)嵌套分布式任務(wù)，執(zhí)行預(yù)授權(quán)處理，即凍結(jié)提現(xiàn)款；
5. 組裝處理結(jié)果并返回。

階段二：

調(diào)用者根據(jù)支付層協(xié)議申請(qǐng)的返回結(jié)果，決定提交或回滾分布式事務(wù)。

這個(gè)調(diào)用是隱式的，與調(diào)用賬務(wù)核心服務(wù)接口方向一致，即調(diào)用者本地事務(wù)提交，則分布式失誤提交，同時(shí)支付層調(diào)用賬務(wù)核心的嵌套式分布式任務(wù)也提交，否則本次申請(qǐng)做回滾處理。

異步提現(xiàn)支付協(xié)議推進(jìn)處理：

異步提現(xiàn)支付協(xié)議在申請(qǐng)階段只是將提現(xiàn)額做了凍結(jié)，后續(xù)處理是通過(guò)支付層的調(diào)度任務(wù)根據(jù)優(yōu)先級(jí)以及可執(zhí)行時(shí)間按順序處理，包括對(duì)支付指令的賬務(wù)解凍、扣款、報(bào)送清算指令等步驟。

對(duì)于正常提現(xiàn)或認(rèn)證提現(xiàn)，某些需要審核生僻字的提現(xiàn)申請(qǐng)。產(chǎn)品層調(diào)用者在請(qǐng)求支付層申請(qǐng)?zhí)幚?，如果指定了不允許支付層自行處理的，則支付層不會(huì)自行通過(guò)調(diào)度任務(wù)方式推進(jìn)處理，而是等待產(chǎn)品層通知才進(jìn)行處理。

支付層自行調(diào)度的推進(jìn)處理：

1. 加載協(xié)議數(shù)據(jù)，激活領(lǐng)域模型對(duì)象；
2. 執(zhí)行結(jié)算處理，包括賬務(wù)解凍與扣款；
3. 執(zhí)行報(bào)清算處理，通過(guò)確保達(dá)到的ESB消息通知清算層執(zhí)行清算。

產(chǎn)品層通知方式的推進(jìn)處理：

1. 加載協(xié)議數(shù)據(jù)，激活領(lǐng)域模型對(duì)象；
2. 記錄協(xié)議的相關(guān)審核人以及類(lèi)似于生僻字審核所需要的銀行開(kāi)戶(hù)名等信息；
3. 執(zhí)行結(jié)算處理，包括賬務(wù)解凍與扣款；
4. 執(zhí)行報(bào)清算處理，通過(guò)確保達(dá)到的ESB消息通知清算層執(zhí)行清算。

1）異步提現(xiàn)支付協(xié)議取消/接受清算處理結(jié)果回執(zhí)

異步提現(xiàn)支付協(xié)議取消：

• 這里提到的協(xié)議取消不是對(duì)整個(gè)協(xié)議的取消，支付層只允許對(duì)單筆支付指令的取消行為；
• 對(duì)于大多數(shù)協(xié)議支付指令為單筆的提現(xiàn)支付協(xié)議，如果該筆支付指令取消成功，則協(xié)議也相應(yīng)進(jìn)入處理結(jié)束狀態(tài)；
• 取消支付指令由于涉及賬務(wù)處理，所以繼續(xù)使用嵌套分布式事務(wù)解決。

需要注意的是：

• 只有處于已預(yù)授權(quán)狀態(tài)的支付指令才可以被取消，如果已經(jīng)扣款或者已報(bào)清算，則不允許在支付層發(fā)起取消。產(chǎn)品可以通過(guò)致使清算指令失敗的方式令支付指令失敗，達(dá)到取消的效果。
• 請(qǐng)求賬務(wù)執(zhí)行解凍處理。
• 通知產(chǎn)品層代理者本提現(xiàn)流水已取消。

接受清算處理結(jié)果回執(zhí)：

在經(jīng)歷了上述兩個(gè)處理過(guò)程后，清算層根據(jù)自有的業(yè)務(wù)規(guī)則進(jìn)行清算處理。最終的清算結(jié)果需要確保通知到支付層，此處繼續(xù)選用高可靠性的ESB確保到達(dá)。

需要注意的是：

• 對(duì)于清算成功的支付指令，將該筆置為成功狀態(tài)；
• 對(duì)于清算失敗的支付指令，請(qǐng)求賬務(wù)進(jìn)行失敗回充處理，并將該筆置為失敗狀態(tài)；
• 對(duì)于清算成功的支付指令，更新其實(shí)付金額為應(yīng)付金額；對(duì)于清算失敗的支付指令，更新其實(shí)付金額為0；
• 成功或失敗狀態(tài)的支付指令都代表處理結(jié)束；如果申請(qǐng)的異步提現(xiàn)支付協(xié)議只有所有支付指令均處理結(jié)束，則需要將協(xié)議也置為處理結(jié)束狀態(tài)；同時(shí)累加其所屬支付指令的實(shí)付金額作為協(xié)議的實(shí)付金額；
• 所有處理結(jié)束的支付指令，均需要回執(zhí)給產(chǎn)品層，由其進(jìn)行具體業(yè)務(wù)處理。

全局系統(tǒng)中有多處業(yè)務(wù)場(chǎng)景使用提現(xiàn)取消服務(wù)，如風(fēng)控的申請(qǐng)后拒絕行為，客服的提現(xiàn)失敗任務(wù)，以及后臺(tái)凍結(jié)賬戶(hù)等，都需要取消指定的提現(xiàn)申請(qǐng)記錄。

請(qǐng)求者（系統(tǒng)）使用分布式事務(wù)，來(lái)要求支付層保證整體業(yè)務(wù)的原子性，也就是說(shuō)支付層所提供的取消服務(wù)，在分布式事務(wù)第一階段執(zhí)行成功后，如賬務(wù)解凍成功后，需要將協(xié)議重新置為系統(tǒng)狀態(tài)，等待請(qǐng)求者提交分布式事務(wù)。

相應(yīng)的，如果請(qǐng)求者發(fā)生異常而回滾分布式事務(wù)，支付層必須確保協(xié)議整體模型數(shù)據(jù)恢復(fù)至取消前狀態(tài)（包括金額等關(guān)鍵數(shù)據(jù)要素），而不能與其他基于分布式事務(wù)的申請(qǐng)服務(wù)一樣，將數(shù)據(jù)刪除。

同時(shí)，支付層必須確保在請(qǐng)求者提交分布式事務(wù)后，才能發(fā)送回執(zhí)消息給產(chǎn)品層代理者。不允許在業(yè)務(wù)處理內(nèi)部發(fā)送回執(zhí)消息，否則一旦請(qǐng)求者回滾事務(wù)，此消息無(wú)法刪除。

2）統(tǒng)一協(xié)議處理結(jié)果回執(zhí)/同步提現(xiàn)支付協(xié)議申請(qǐng)

統(tǒng)一協(xié)議處理結(jié)果回執(zhí)：

• 除了上述的支付指令處理成功/失敗已經(jīng)提現(xiàn)取消作為處理結(jié)束狀態(tài)，需要回執(zhí)給產(chǎn)品層外，對(duì)于退票情況，也需要回執(zhí)給產(chǎn)品層；
• 產(chǎn)品層目前也是通過(guò)前置來(lái)統(tǒng)一處理的，所以支付層在回執(zhí)產(chǎn)品層提現(xiàn)處理結(jié)果時(shí)需要一并報(bào)送該筆支付指令的產(chǎn)品碼、子協(xié)議代碼以及備注信息、操作員等；
• 這里回執(zhí)給產(chǎn)品層的處理結(jié)果，也是采用高可靠性的ESB確保到達(dá)。

（2）同步提現(xiàn)支付協(xié)議申請(qǐng)

對(duì)于需要同步支付并清算的提現(xiàn)產(chǎn)品，使用本協(xié)議。同異步提現(xiàn)支付協(xié)議，本協(xié)議也可以使用嵌套分布式事務(wù)。

不同的是本協(xié)議的使用需要三階段處理模式：

階段一：

調(diào)用者開(kāi)啟分布式事務(wù)，在事務(wù)塊內(nèi)請(qǐng)求異步提現(xiàn)支付協(xié)議申請(qǐng)。

• 快捷提現(xiàn)都是通過(guò)快捷協(xié)議號(hào)，即收款方信息較為簡(jiǎn)單，為此設(shè)計(jì)專(zhuān)用的申請(qǐng)單據(jù)對(duì)象，只支持每次申請(qǐng)單筆明細(xì)項(xiàng)。
• 通過(guò)內(nèi)部的業(yè)務(wù)接入層，將專(zhuān)用單據(jù)轉(zhuǎn)換成統(tǒng)一的內(nèi)部領(lǐng)域模型對(duì)象。
• 對(duì)領(lǐng)域模型對(duì)象加工，包括補(bǔ)全、拆分、檢查等。
• 開(kāi)啟嵌套分布式事務(wù)，執(zhí)行結(jié)算處理，直接進(jìn)行扣款。
• 組裝處理結(jié)果并返回。

階段二：

調(diào)用者根據(jù)支付層協(xié)議申請(qǐng)的返回結(jié)果，決定提交或回滾分布式事務(wù)。這個(gè)調(diào)用是隱式的，與調(diào)用賬務(wù)核心服務(wù)接口方式一致——即調(diào)用者本地事務(wù)提交，則分布式事務(wù)提交，同時(shí)支付層調(diào)用賬務(wù)核心的嵌套分布式事務(wù)也提交，否則本次申請(qǐng)做回滾處理。

階段三：

調(diào)用者分布式事務(wù)提交后，采用主動(dòng)調(diào)用同步提現(xiàn)支付協(xié)議的推進(jìn)處理服務(wù)，通知進(jìn)行后續(xù)處理。

1）同步提現(xiàn)支付協(xié)議推進(jìn)/恢復(fù)處理

1. 之所以沒(méi)有在同步提現(xiàn)支付協(xié)議申請(qǐng)過(guò)程中進(jìn)行清算，原因是清算層無(wú)分布式事務(wù)支持。而同步提現(xiàn)支付協(xié)議的清算是需要同步請(qǐng)求清算層的，為了保證前期處理過(guò)程的一致性。支付層在申請(qǐng)階段確保賬務(wù)扣款成功，這個(gè)是由嵌套分布式事務(wù)框架來(lái)確保的。
2. 而此時(shí)并未進(jìn)行實(shí)時(shí)清算，產(chǎn)品層需要顯示的調(diào)用本推進(jìn)處理服務(wù)來(lái)通知支付層進(jìn)行后續(xù)清算處理。這個(gè)通知是不需要確保的，原因是經(jīng)過(guò)前期的申請(qǐng)?zhí)幚?，支付層的協(xié)議處理已提交。而產(chǎn)品層顯示調(diào)用支付層進(jìn)行推進(jìn)只是為了實(shí)時(shí)的拿到最終處理結(jié)果，從而回顯給會(huì)員。
3. 而支付層內(nèi)部則簡(jiǎn)單的請(qǐng)求清算層進(jìn)行同步清算即可。
4. 如果發(fā)生掉單的情況，支付層內(nèi)部的恢復(fù)程序會(huì)不斷的嘗試恢復(fù)，直至清算處理結(jié)束為止。這里就需要清算層對(duì)于支付層，同一支付指令的多次清算請(qǐng)求，做忽略處理，并返回當(dāng)前的處理狀態(tài)。
5. 支付層同步請(qǐng)求清算，清算層的返回結(jié)果中有三種清算狀態(tài)：

如果支付層在請(qǐng)求同步清算時(shí)出現(xiàn)了嚴(yán)重異常，如清算層異常宕機(jī)或清算返回丟失，則仍然返回產(chǎn)品處理中結(jié)果，支付層內(nèi)部回復(fù)程序會(huì)繼續(xù)嘗試回復(fù)。

2）提現(xiàn)退票支付協(xié)議

提現(xiàn)退票支付協(xié)議作為本講引入的協(xié)議之一，通過(guò)申請(qǐng)支付層的協(xié)議，由支付層負(fù)責(zé)賬務(wù)與業(yè)務(wù)推進(jìn)處理。在本協(xié)議下，退票流水將作為支付指令存在，與被退票的支付指令平級(jí)，不會(huì)去對(duì)已經(jīng)處理成功的原支付流水做任何改動(dòng)。

由于不需要進(jìn)行清算，支付層內(nèi)部只需要處理賬務(wù)充值部分即可。所以本協(xié)議也是同步的，即申請(qǐng)成功則全部處理完畢，使用嵌套分布式事務(wù)。

1. 只有處理成功的支付指令才可以被退票；
2. 每一筆支付指令最多只能被退票一次；
3. 退票金額為原支付指令的實(shí)付金額；
4. 新產(chǎn)生的（退票）支付指令建立起與原支付指令的關(guān)聯(lián)關(guān)系；
5. 對(duì)于退票申請(qǐng)?zhí)幚碇?，如果?qǐng)求賬務(wù)失敗，則本次申請(qǐng)失敗。

3）打款機(jī)構(gòu)/支付能力/分布式任務(wù)

打款機(jī)構(gòu)：

任何一筆提現(xiàn)申請(qǐng)，最終目的都是從某一支付賬戶(hù)提現(xiàn)至指定的銀行卡上，這個(gè)銀行卡就是提現(xiàn)支付協(xié)議中指定的收款方信息。

由于銀行卡信息中的開(kāi)戶(hù)行種類(lèi)繁多，比如：各類(lèi)非直接打款銀行，對(duì)于這些開(kāi)戶(hù)行的提現(xiàn)申請(qǐng)，實(shí)際會(huì)通過(guò)跨行的方式進(jìn)行提現(xiàn)。具體說(shuō)來(lái)就是根據(jù)開(kāi)戶(hù)行，提現(xiàn)的額度范圍，賬戶(hù)的對(duì)公對(duì)私屬性等，來(lái)決定最優(yōu)的提現(xiàn)方式。

產(chǎn)品層不知道本次提現(xiàn)的實(shí)際打款機(jī)構(gòu)，而支付層對(duì)每筆支付指令進(jìn)行賬務(wù)處理時(shí)需要知道具體的打款機(jī)構(gòu)，這樣才能請(qǐng)求賬務(wù)進(jìn)行扣款或者回充處理，所以打款機(jī)構(gòu)的規(guī)則就需要支付層進(jìn)行維護(hù)。

• 根據(jù)既定的打款機(jī)構(gòu)配置方式，按照開(kāi)戶(hù)行、提現(xiàn)的額度范圍、賬戶(hù)的對(duì)公對(duì)私屬性以及產(chǎn)品碼來(lái)補(bǔ)全支付指令的打款機(jī)構(gòu)；
• 對(duì)于同步提現(xiàn)支付協(xié)議，其打款機(jī)構(gòu)與開(kāi)戶(hù)行相同。

分布式任務(wù)：

支付層的大量調(diào)度任務(wù)，如：異步提現(xiàn)支付協(xié)議的推進(jìn)、同步提現(xiàn)支付協(xié)議的掉單恢復(fù)等，將來(lái)會(huì)有更多的調(diào)度任務(wù)加入。

考慮到線上環(huán)境是多服務(wù)器并發(fā)處理任務(wù)的，對(duì)于這種分布式任務(wù)需要解決兩個(gè)問(wèn)題：

1. 防止重復(fù)處理：由于各服務(wù)器程序代碼都是一樣的，這樣就很容易造成彼此處理的數(shù)據(jù)相同，造成資源的浪費(fèi)，并且可能帶來(lái)嚴(yán)重的資損風(fēng)險(xiǎn)。
2. 最大限度的并發(fā)：在解決了重復(fù)處理的問(wèn)題后，還必須讓集群服務(wù)器發(fā)揮效能，真正實(shí)現(xiàn)多服務(wù)器并發(fā)的處理，在保證安全的情況下最大程度的提高處理效率。

支付能力：

作為支付協(xié)議最重要的處理規(guī)則，支付層對(duì)外提供可供快速定制的各種內(nèi)部處理打包方案，這些打包方案里配置了一些極為關(guān)鍵的規(guī)則要素：

1. 支付處理優(yōu)先級(jí)：決定其在支付層處理的優(yōu)先級(jí)別，值越大的越優(yōu)先處理；
2. 支付處理延時(shí)時(shí)間：以此推出每筆支付指令的具體可執(zhí)行時(shí)間；
3. 清算優(yōu)先級(jí)：報(bào)送的清算指令，在清算層內(nèi)部的處理優(yōu)先級(jí)別；
4. 內(nèi)部渠道：內(nèi)部渠道的劃分，如線下、快捷等，以此決定清算通道；
5. 賬務(wù)子交易代碼：執(zhí)行賬務(wù)扣款的子交易代碼；
6. 失敗回充賬務(wù)子交易代碼：執(zhí)行賬務(wù)失敗回充的子交易代碼。

除此之外，每個(gè)支付能力擁有以下要素：

1. 子協(xié)議代碼：一個(gè)支付能力可以被多個(gè)支付協(xié)議使用，這里就是可以使用這個(gè)支付能力的子協(xié)議代碼。
2. 是否是默認(rèn)能力：每個(gè)支付協(xié)議都有且只有一個(gè)默認(rèn)的支付能力。
3. 作為初始數(shù)據(jù)，支付層配置了若干支付能力，正式由于這些支付能力的存在，支付層能夠做到靈活的發(fā)布新的支付服務(wù)。而這種打包方案的發(fā)布，無(wú)需代碼改動(dòng)成本、無(wú)發(fā)布成本，只需簡(jiǎn)單配置即可工作。
4. 產(chǎn)品與可使用的支付協(xié)議之間是多對(duì)多的關(guān)系，支付協(xié)議與可使用的支付能力之間也是多對(duì)多的關(guān)系。
5. 不同的產(chǎn)品，使用不同的支付協(xié)議，實(shí)際上是在使用不同的支付能力。
6. 不同的產(chǎn)品，使用相同的支付協(xié)議，也可以使用不同的支付能力。
7. 相同的產(chǎn)品，使用相同的支付協(xié)議，仍然可以使用不同的支付能力。

4）其他服務(wù)類(lèi)

公共查詢(xún)類(lèi)服務(wù)：

• 協(xié)議授權(quán)查詢(xún)服務(wù)：此服務(wù)由支付層自行提供，所有使用支付協(xié)議的產(chǎn)品，必須得到支付層的使用授權(quán)。這里提供了根據(jù)產(chǎn)品碼、子協(xié)議代碼檢查是否可用的查詢(xún)服務(wù)。
• 機(jī)構(gòu)信息查詢(xún)服務(wù)：此服務(wù)由清算層提供，支付層代為封裝，查詢(xún)所有系統(tǒng)支持的機(jī)構(gòu)信息列表，每個(gè)機(jī)構(gòu)信息包括機(jī)構(gòu)ID、機(jī)構(gòu)名稱(chēng)等基本要素。通過(guò)機(jī)構(gòu)ID查詢(xún)機(jī)構(gòu)信息服務(wù)；通過(guò)機(jī)構(gòu)名稱(chēng)查詢(xún)機(jī)構(gòu)信息服務(wù)；檢查指定的機(jī)構(gòu)ID與機(jī)構(gòu)名稱(chēng)是否匹配服務(wù)。

提現(xiàn)查詢(xún)類(lèi)服務(wù)：

• 銀行卡段檢查服務(wù)：此服務(wù)由清算層提供，支付層代為封裝。會(huì)員在設(shè)置銀行卡信息時(shí)，產(chǎn)品通過(guò)此服務(wù)檢查會(huì)員設(shè)定的銀行卡信息的有效性。同時(shí)在發(fā)起提現(xiàn)申請(qǐng)時(shí)，支付層內(nèi)部也需要通過(guò)該服務(wù)再次請(qǐng)求清算層檢查，以確保報(bào)送的清算指令數(shù)據(jù)合法性。
• 對(duì)公賬戶(hù)聯(lián)行號(hào)檢查服務(wù)：此服務(wù)由清算層提供，支付層代為封裝，產(chǎn)品層在檢查設(shè)置了對(duì)公銀行賬戶(hù)有效性時(shí)使用。
• 清算通道支付限額查詢(xún)服務(wù)：此服務(wù)由清算層提供，支付層代為封裝，某些特定場(chǎng)景下，產(chǎn)品層希望提前得到清算層，所設(shè)定的某個(gè)清算通道支付上限金額。
• 提現(xiàn)統(tǒng)計(jì)查詢(xún)服務(wù)：此服務(wù)由支付層自行提供，統(tǒng)計(jì)會(huì)員在某時(shí)間段內(nèi)的所有統(tǒng)計(jì)信息，包括提現(xiàn)成功、失敗、取消、退票以及處理中的總比數(shù)、總金額等。

管理服務(wù)：

• 協(xié)議授權(quán)管理服務(wù)：提供產(chǎn)品的協(xié)議使用授權(quán)開(kāi)通、關(guān)閉服務(wù)。
• 打款機(jī)構(gòu)管理服務(wù)：提供打款機(jī)構(gòu)規(guī)則的配置、取消服務(wù)。
• 支付能力管理服務(wù)：提供支付能力的配置、取消服務(wù)。
• 緩存刷新服務(wù)：前文提到的支付層內(nèi)置本地緩存機(jī)制，一旦某些清算層的配置規(guī)則或支付層自有配置規(guī)則發(fā)生變化，需要刷新這些緩存。支付層提供管理平臺(tái)使用的本地緩存刷新服務(wù)，支持全部緩存刷新和對(duì)指定的某個(gè)緩存刷新。這里需要考慮由于線上是集群服務(wù)器環(huán)境，要做到所有服務(wù)器均可刷新。此外，對(duì)于支付層自由配置規(guī)則的調(diào)整，內(nèi)部會(huì)自動(dòng)進(jìn)行刷新本次調(diào)整所對(duì)應(yīng)的緩存內(nèi)容。

本地緩存：

由于支付層代理了清算層的一些底層查詢(xún)服務(wù)，并且這些服務(wù)頻繁的被產(chǎn)品層使用，而且支付層內(nèi)部處理也需要用到這些底層服務(wù)。為了降低遠(yuǎn)程查詢(xún)的系統(tǒng)開(kāi)銷(xiāo)，支付層需要建立起本地緩存機(jī)制，將適合的清算層查詢(xún)結(jié)果緩存在本地。

1. 機(jī)構(gòu)信息查詢(xún)結(jié)果；
2. 清算通道支付限額查詢(xún)結(jié)果；
3. 支行列表查詢(xún)結(jié)果。

除此之外，支付層自有的配置規(guī)則也可以考慮使用緩存的模式，減少數(shù)據(jù)庫(kù)讀取頻率：

1. 協(xié)議授權(quán)關(guān)系列表；打款機(jī)構(gòu)規(guī)則列表；
2. 支付能力列表。

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

充值協(xié)議處理主體流程圖（充值遵守的系統(tǒng)處理原則：先清算，后結(jié)算）：

充值協(xié)議處理主體流程圖（充退遵循的系統(tǒng)處理原則：先結(jié)算，后清算）：

后結(jié)算處理的充值協(xié)議，如阿里國(guó)際站的小額擔(dān)保交易的使用場(chǎng)景，其處理流程如下：

六、充值協(xié)議系統(tǒng)級(jí)架構(gòu)和領(lǐng)域模型

系統(tǒng)整體架構(gòu)

我們從多個(gè)視角來(lái)快速瀏覽支付層的整體系統(tǒng)架構(gòu)：

模型總覽

這里需要指出的是，充值協(xié)議不存在支付層處理的時(shí)限性，全部都是實(shí)時(shí)報(bào)送清算層完成的。引入的異步處理類(lèi)充值協(xié)議并不是非實(shí)時(shí)報(bào)送清算層，而是由于金融機(jī)構(gòu)回執(zhí)給清算層的清算結(jié)果是異步的，今兒演變?yōu)榍逅慊貓?zhí)異步通知至支付層。

充值協(xié)議需要支持各類(lèi)場(chǎng)景下的充值行為，如：網(wǎng)銀、快捷等，這些充值場(chǎng)景分表代表的是付款方支付工具的接入方式。當(dāng)加工處理為充值指令內(nèi)部的清算單據(jù)時(shí)，僅作為此清算通道所必須的清算要素而存在，它們最終成為報(bào)送清算層的各類(lèi)充值清算操作指令。對(duì)于充值協(xié)議本身不同的支付工具決定了支付、清算系統(tǒng)交互的細(xì)微差異，如：快捷與網(wǎng)匯E，需要實(shí)時(shí)響應(yīng)服務(wù)使用者協(xié)議處理結(jié)果，而網(wǎng)銀則被動(dòng)接受金融機(jī)構(gòu)的異步通知。

充值不再采用提現(xiàn)協(xié)議中協(xié)議、協(xié)議明細(xì)、指令三者間的1:N:M關(guān)系，而是簡(jiǎn)化為協(xié)議與指令間1:N關(guān)系，在不進(jìn)行定期支付的場(chǎng)景下，協(xié)議明細(xì)項(xiàng)作用不大。

每1充值協(xié)議，擁有1到多個(gè)充值指令，充退指令是在各充值協(xié)議單據(jù)要素基礎(chǔ)之上加工得出，其具備了進(jìn)行后續(xù)操作處理的全部要素信息，如需要報(bào)送清算層的清算單據(jù)和與賬務(wù)進(jìn)行交互的賬務(wù)單據(jù)。

每1充值指令，擁有1到多個(gè)充值操作指令，充值操作指令是真正可被系統(tǒng)處理的、運(yùn)行時(shí)得出的具體操作步驟，具體表現(xiàn)為清算。

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

用戶(hù)進(jìn)入統(tǒng)一收銀臺(tái)界面，選擇了充值渠道以及充值金額，收銀臺(tái)經(jīng)過(guò)規(guī)則檢查（如安全、渠道等）后，向支付層發(fā)起充值協(xié)議申請(qǐng)：

清算層在處理完金融機(jī)構(gòu)的清算結(jié)果通知后，回執(zhí)給支付層：

重要的規(guī)則、約束、平衡檢查如下：

• 產(chǎn)品所使用的充值協(xié)議必須經(jīng)過(guò)授權(quán)，處于開(kāi)通狀態(tài)；
• 必須指定支付渠道API；
• 原則上受理的充值額度區(qū)間為：0<額<= 無(wú)限大;目前的充值申請(qǐng)均由統(tǒng)一收銀臺(tái)發(fā)起，相關(guān)特定渠道的充值限額已由收銀臺(tái)進(jìn)行控制，支付層不對(duì)充值額度再次檢查；
• 賬務(wù)充值動(dòng)作，必須在清算層明確回執(zhí)銀行清算成功后方可進(jìn)行，實(shí)際充值金額以清算層回執(zhí)金額為準(zhǔn)。

充值指令的狀態(tài)遷轉(zhuǎn)

如圖所示：

1. 其中已預(yù)授權(quán)與已預(yù)清算狀態(tài)均為中間狀態(tài)，為B2B網(wǎng)銀支付和Migs網(wǎng)銀支付所設(shè)計(jì)。實(shí)際情況下已預(yù)清算狀態(tài)不會(huì)遷轉(zhuǎn)至清算失敗狀態(tài)，但是在系統(tǒng)設(shè)計(jì)中我們認(rèn)為這樣的狀態(tài)遷轉(zhuǎn)有效。
2. 絕大多數(shù)的充值指令，均是從已報(bào)送清算狀態(tài)，直接遷轉(zhuǎn)為清算成功或清算失敗狀態(tài)。

七、充退協(xié)議領(lǐng)域模型

模型總覽

充退協(xié)議的處理過(guò)程與提現(xiàn)協(xié)議極其類(lèi)似，唯一的差別在于提現(xiàn)協(xié)議可以指定收款方的支付工具，如客戶(hù)指定收款的銀行卡信息。而充退則依照“由哪里來(lái)，回哪里去”的原則，即客戶(hù)不能指定收款方信息。

充退必須要關(guān)聯(lián)到一筆充值指令，金融機(jī)構(gòu)依據(jù)充值清算過(guò)程中的付款方，作為本次充退的收款方，而支付層則無(wú)需關(guān)心收款方信息，并且也無(wú)法得知此信息。

允許對(duì)一筆充值指令流水號(hào)進(jìn)行多次充退，只要充退金額滿(mǎn)足系統(tǒng)限制即可發(fā)起，所以充值指令與充退指令間存在這樣的關(guān)系：

另外異步后結(jié)算充退協(xié)議是專(zhuān)門(mén)為外卡這樣的充值渠道退款而開(kāi)設(shè)的，我們都知道充退與提現(xiàn)的資金流向相同，在處理此類(lèi)業(yè)務(wù)時(shí)，支付層必須確保先做完賬務(wù)結(jié)算，才能報(bào)送清算指令。

而后結(jié)算充退協(xié)議則用于非常特殊的場(chǎng)景：在報(bào)送清算層時(shí)支付層無(wú)法完成賬務(wù)處理，如外幣充退。在支付層不做任何賬務(wù)處理的情況下，報(bào)送充退清算指令，最終清算完成后再進(jìn)行賬務(wù)結(jié)算處理。支付層不保證此類(lèi)充退的賬務(wù)結(jié)算順利完成，由此帶來(lái)的結(jié)算失敗風(fēng)險(xiǎn)由業(yè)務(wù)產(chǎn)品承擔(dān)。

由于金融機(jī)構(gòu)與清算層的交互使用充值指令流水號(hào)，而不是以支付層所產(chǎn)生的充退指令流水號(hào)作為交互依據(jù)，并且存在著一筆充值指令流水號(hào)多次、且同金額的充退指令。這樣對(duì)于后續(xù)賬務(wù)、會(huì)計(jì)系統(tǒng)以及對(duì)賬中心的資金清算對(duì)賬都帶來(lái)了麻煩。

原則上，我們希望同一筆充值指令流水號(hào)只能存在一筆處于活動(dòng)中的充退指令，當(dāng)這筆充退指令全部處理結(jié)束時(shí)，才能發(fā)起對(duì)該充值流水號(hào)的再次充退。

在某些特定商業(yè)背景下（如機(jī)票平臺(tái)大客戶(hù)的充退需求）必須大客戶(hù)一次性對(duì)一筆充值指令的連續(xù)多次充退請(qǐng)求，有如下兩種實(shí)現(xiàn)方式：

• 方式一：需要清算層在報(bào)送銀行端時(shí)進(jìn)行恰當(dāng)?shù)奶幚?，如將支付層?bào)送過(guò)來(lái)的充退清算指令進(jìn)行合并，或采取延遲報(bào)送銀行等手段加以實(shí)現(xiàn)；
• 方式二：產(chǎn)品層加強(qiáng)此類(lèi)合并充退的組織力度，即支付層、賬務(wù)/會(huì)計(jì)、清算層以及對(duì)賬中心都不為此類(lèi)業(yè)務(wù)進(jìn)行內(nèi)部業(yè)務(wù)合并，而是交由產(chǎn)品進(jìn)行合并，請(qǐng)求支付層的充退已經(jīng)是合并后的單據(jù)。這樣的整體代價(jià)較小，并且提高了核心系統(tǒng)的業(yè)務(wù)處理穩(wěn)定性。

統(tǒng)一的充退申請(qǐng)代理除了上述的完成對(duì)充退申請(qǐng)合并工作外，該代理將作為所有充退產(chǎn)品申請(qǐng)入口，一個(gè)很重要的職責(zé)是識(shí)別產(chǎn)品所發(fā)起的充退申請(qǐng)合法性。由于充退申請(qǐng)存在資損風(fēng)險(xiǎn)點(diǎn)，且發(fā)起場(chǎng)景非常復(fù)雜、難以統(tǒng)一控制，所以將這些申請(qǐng)進(jìn)入支付層的安全性檢查統(tǒng)一由代理者進(jìn)行識(shí)別，支付層本身的充退協(xié)議做到最底層的合法性檢查即可。

另外，支付層分流器以異步消息通知的方式完成回執(zhí)，交易或繳費(fèi)類(lèi)產(chǎn)品在自身業(yè)務(wù)推進(jìn)處理失敗時(shí)，統(tǒng)一報(bào)送可疑事件至此代理，由其來(lái)識(shí)別各類(lèi)可充退規(guī)則配置，決定是否向支付層發(fā)起充退協(xié)議申請(qǐng)。

鑒于此，支付層提供的充退協(xié)議遵循一筆充值指令，最多只能有一筆處于活動(dòng)狀態(tài)充退指令的約束。同樣的原因，充退協(xié)議也不再引入?yún)f(xié)議明細(xì)項(xiàng)，直接建立協(xié)議與指令的關(guān)系；

• 每1充退協(xié)議，擁有1到多個(gè)充退指令，充退指令是在各充退協(xié)議單據(jù)要素基礎(chǔ)之上加工得出，其具備了進(jìn)行后續(xù)操作處理的全部要素信息，如需要報(bào)送清算層的清算單據(jù)和與賬務(wù)進(jìn)行交互的賬務(wù)單據(jù)。
• 每1充退指令，擁有1到多個(gè)充退操作指令，充退操作指令是真正可被系統(tǒng)處理的、運(yùn)行時(shí)得出的具體操作步驟，具體表現(xiàn)為清算操作指令、賬務(wù)操作指令以及其他底層公共服務(wù)的處理單元。

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

前文中提到充退協(xié)議與提現(xiàn)協(xié)議的處理方式極其類(lèi)似，除了收款方信息用戶(hù)無(wú)法指定外，其余部分與提現(xiàn)的現(xiàn)有做法一致，所以此處不再贅述。充退協(xié)議存在時(shí)限性，我們繼續(xù)沿用支付能力可配置的做法，將充退產(chǎn)品與充退協(xié)議實(shí)現(xiàn)松耦合綁定關(guān)系。

注：對(duì)于后結(jié)算充退協(xié)議，指令狀態(tài)直接遷轉(zhuǎn)為已報(bào)送清算狀態(tài)，在等待清算回執(zhí)后再做賬務(wù)結(jié)算。

重要的規(guī)則、約束、平衡檢查等包括以下各點(diǎn)：

• 每筆充值指令最多只擁有一筆處于活動(dòng)中狀態(tài)的充退指令。
• （每筆充值指令下所有處于活動(dòng)狀態(tài)的充退指令金額總額）ART <= （該筆充值指令實(shí)付金額）DT – （所有該筆充值指令下已充退成功的金額總額）SRT。
• 預(yù)結(jié)算充退協(xié)議申請(qǐng)單據(jù)中指定的主事務(wù)號(hào)不得重復(fù)，全局唯一。
• 產(chǎn)品所使用的提現(xiàn)支付協(xié)議必須經(jīng)過(guò)授權(quán)，處于開(kāi)通狀態(tài)。
• 必須有可匹配的支付能力。

充值協(xié)議領(lǐng)域模型VS充退協(xié)議領(lǐng)域模型：

與提現(xiàn)和退票的關(guān)系類(lèi)似，充退也是建立在充值基礎(chǔ)之上的特殊協(xié)議，都是完成了正向協(xié)議的反向資金處理過(guò)程。

在前面講述中將提現(xiàn)協(xié)議與退票協(xié)議進(jìn)行合并，反映在模型本身、處理流程以及數(shù)據(jù)存儲(chǔ)等各方面都保持一致，

而本期充值協(xié)議與充退協(xié)議則是分開(kāi)建設(shè)的，原因有以下幾點(diǎn)：

1. 提現(xiàn)無(wú)多次退票場(chǎng)景，每筆提現(xiàn)指令與退票指令存在唯一對(duì)應(yīng)關(guān)系，而充值與充退則存在1:N的對(duì)應(yīng)關(guān)系。
2. 將退票與提現(xiàn)合并，在數(shù)據(jù)格式上要求嚴(yán)格的統(tǒng)一，即拷貝原有的提現(xiàn)數(shù)據(jù)，生成退票數(shù)據(jù)。提現(xiàn)、退票的數(shù)據(jù)量小，開(kāi)銷(xiāo)少，對(duì)于獨(dú)立的查詢(xún)、統(tǒng)計(jì)均比較方便。而充值與充退的數(shù)據(jù)量相差太大，二者進(jìn)行合并必然帶來(lái)各自處理以及查詢(xún)統(tǒng)計(jì)的巨大消耗，尤其以充退為甚。
3. 充退流水要素構(gòu)成比較簡(jiǎn)單，只需記錄所關(guān)聯(lián)的充值指令流水號(hào)即可完成后續(xù)的清算退回過(guò)程，沒(méi)有必要拷貝充值數(shù)據(jù)。

八、充值業(yè)務(wù)邊界分析

業(yè)務(wù)用例邊界：

充值業(yè)務(wù)在支付層設(shè)計(jì)的業(yè)務(wù)用例主要包括以下若干模塊：

1. 以協(xié)議方式提供適用于收銀臺(tái)或其他業(yè)務(wù)產(chǎn)品使用的充值服務(wù) ；
2. 以協(xié)議方式提供適用于各類(lèi)業(yè)務(wù)產(chǎn)品使用的充退服務(wù)；
3. 建立對(duì)支付渠道的統(tǒng)一管理；
4. 基于通用性而設(shè)計(jì)的統(tǒng)一業(yè)務(wù)分流組件；提供相應(yīng)的注冊(cè)（推進(jìn)）服務(wù)；
5. 作為協(xié)議使用的輔助手段，提供不同協(xié)議的干預(yù)處理服務(wù)；
6. 承擔(dān)包裝清算層所公布的各類(lèi)底層公共查詢(xún)服務(wù)，以及獨(dú)立提供給產(chǎn)品層的各類(lèi)查詢(xún)統(tǒng)計(jì)服務(wù)；
7. 可供靈活編輯的各種核心處理規(guī)則配置機(jī)制，以及提供配套的規(guī)則管理服務(wù)。

系統(tǒng)用例邊界：

網(wǎng)銀充值協(xié)議申請(qǐng)：

• 用戶(hù)選擇網(wǎng)銀渠道，如B2C或B2B以及VISA等，收銀臺(tái)組裝本充值協(xié)議申請(qǐng)單據(jù)，請(qǐng)求支付層處理；
• 如申請(qǐng)單據(jù)中包含業(yè)務(wù)分流回執(zhí)信息，則需要完成對(duì)回執(zhí)上下文的注冊(cè)工作，這里交由監(jiān)聽(tīng)器處理；
• 報(bào)送清算指令清算層，并將可供收銀臺(tái)實(shí)現(xiàn)頁(yè)面跳轉(zhuǎn)的地址或html串響應(yīng)給收銀臺(tái)。

基本流程示意圖：

1. 協(xié)議申請(qǐng)單據(jù)一旦經(jīng)過(guò)合法性檢查，必須先存儲(chǔ)，同時(shí)發(fā)送協(xié)議申請(qǐng)事件，以期分流任務(wù)注冊(cè)完成。
2. 同步報(bào)送清算指令，如果此時(shí)請(qǐng)求失敗或超時(shí)，直接返回調(diào)用者申請(qǐng)失敗即可，清算層完成指令落地工作并返回跳轉(zhuǎn)表單對(duì)象。
3. 會(huì)產(chǎn)生一定的廢單數(shù)據(jù)，如會(huì)員在網(wǎng)銀頁(yè)面后直接關(guān)閉。
4. 結(jié)算行為必須在得到清算層明確的清算成功回執(zhí)之后，以實(shí)付金額為準(zhǔn)進(jìn)行賬務(wù)結(jié)算，下同。這里的清算回執(zhí)是異步的，所以不在此圖中顯示，見(jiàn)后續(xù)充值清算回執(zhí)說(shuō)明。

代金卡（充值碼）充值協(xié)議申請(qǐng)：

網(wǎng)銀充值協(xié)議申請(qǐng)后所返回的跳轉(zhuǎn)表單對(duì)象，供收銀臺(tái)跳轉(zhuǎn)至金融機(jī)構(gòu)。而代金卡的充值處理中收銀臺(tái)，無(wú)需獲取跳轉(zhuǎn)表單對(duì)象。這里有可能是代金卡獨(dú)立業(yè)務(wù)系統(tǒng)，已明確了跳轉(zhuǎn)表單對(duì)象，所以這個(gè)充值協(xié)議的處理過(guò)程，僅是將支付流水與清算流水記錄即可，等待外部（百聯(lián)）系統(tǒng)對(duì)清算層的回執(zhí)發(fā)生后發(fā)起結(jié)算行為。

代金卡充值協(xié)議需要收取手續(xù)費(fèi)，在報(bào)送的協(xié)議申請(qǐng)單據(jù)中需要指定待凍結(jié)的金額，支付層充值領(lǐng)域服務(wù)完成充值后，即發(fā)起對(duì)充值賬戶(hù)的凍結(jié)處理。

快捷充值協(xié)議申請(qǐng)：

不同于網(wǎng)銀充值，快捷不需要會(huì)員在金融機(jī)構(gòu)再次確認(rèn)，收銀臺(tái)、支付層、清算層以及金融機(jī)構(gòu)之間全部實(shí)時(shí)交互完成。當(dāng)然，對(duì)于支付層與清算層之間掉單的數(shù)據(jù)，需要恢復(fù)補(bǔ)償措施。

接受充值清算回執(zhí)：

• 對(duì)于網(wǎng)銀充值需要用戶(hù)進(jìn)行操作的，清算層異步通知支付層金融機(jī)構(gòu)的清算結(jié)算；
• 快捷充值或網(wǎng)匯E類(lèi)無(wú)需確認(rèn)的，考慮到清算層實(shí)時(shí)通知支付層有可能出現(xiàn)掉單，此處也作為業(yè)務(wù)恢復(fù)點(diǎn)。

1. 必須以清算回執(zhí)的實(shí)際清算金額為準(zhǔn)進(jìn)行賬務(wù)充值處理；
2. 發(fā)送協(xié)議推進(jìn)處理事件必須在結(jié)算行為事務(wù)塊之內(nèi)完成，即確保結(jié)算完成，且分流任務(wù)被啟動(dòng)。

無(wú)清算充值協(xié)議申請(qǐng)：

以上介紹的各類(lèi)充值協(xié)議其處理過(guò)程，都遵循了支付層先記錄單據(jù)，待清算層完成清算后再由支付層進(jìn)行結(jié)算的處理原則，也就是意味著當(dāng)清算層回執(zhí)支付層具體的清算結(jié)果時(shí)，支付層一定是有相應(yīng)的單據(jù)的。而由于COD業(yè)務(wù)模式的特殊性，物流收到貨款后即才支付機(jī)構(gòu)發(fā)出通知，以物流訂單號(hào)作為充值訂單號(hào)，要求完成此次充值行為。

COD是支付機(jī)構(gòu)內(nèi)系統(tǒng)最先獲知此充值請(qǐng)求的，由它來(lái)通知支付層創(chuàng)建充值協(xié)議并立即完成結(jié)算行為，在此之前支付層并無(wú)任何單據(jù)信息。

為此，支付層需要為COD模式的業(yè)務(wù)開(kāi)設(shè)專(zhuān)用的充值協(xié)議，即所有單據(jù)據(jù)要素已由調(diào)用者收集完畢，并使用此協(xié)議完成充值，注意支付層此時(shí)的處理僅結(jié)算即可，無(wú)需再次與清算層發(fā)生關(guān)系。

這個(gè)時(shí)候可以把COD當(dāng)成是業(yè)務(wù)產(chǎn)品在使用此充值協(xié)議，由于金額機(jī)構(gòu)系統(tǒng)不會(huì)再次通知COD，當(dāng)它們完成自身業(yè)務(wù)處理后，使用高質(zhì)量確保的異步消息通知支付層形式，來(lái)完成本次充值。

支付層要嚴(yán)格控制消息的冪等性，不能為中間賬戶(hù)多次充值！

充值后通知事件：

所有成功完成的充值協(xié)議，都需要以異步消息方式通知CTU及積分核心系統(tǒng)本充值事件。

支付與清算系統(tǒng)掉單恢復(fù)：

對(duì)于實(shí)時(shí)完成支付、清算過(guò)程的充值協(xié)議，需要輔以定時(shí)調(diào)度任務(wù)恢復(fù)系統(tǒng)響應(yīng)超時(shí)的掉單充值指令。掃描2小時(shí)內(nèi)處于報(bào)送清算狀態(tài)的充值指令，使用清算層提供的指令查詢(xún)接口問(wèn)詢(xún)當(dāng)前處理進(jìn)度。對(duì)于清算明確解釋指令處于未知狀態(tài)的，則無(wú)需再做處理，等待其處理結(jié)束后主動(dòng)發(fā)起通知。

充值協(xié)議查詢(xún)：

用以解釋當(dāng)前充值訂單處理狀態(tài)，當(dāng)清算層push相關(guān)信息至收銀臺(tái)后，收銀臺(tái)使用此服務(wù)獲知處理結(jié)果并顯示用戶(hù)。

此服務(wù)不限于僅在此場(chǎng)景下被使用：

• 處理成功狀態(tài)：充值成功，業(yè)務(wù)分流后產(chǎn)品處理成功；
• 充值成功狀態(tài)：僅充值成功，業(yè)務(wù)分流后產(chǎn)品處理失敗或未知狀態(tài)；
• 充值失敗狀態(tài)：充值失敗，無(wú)論業(yè)務(wù)分流是何結(jié)果。

預(yù)結(jié)算充退協(xié)議申請(qǐng)：

• 同提現(xiàn)協(xié)議處理方式，使用此協(xié)議的請(qǐng)求者（產(chǎn)品）必須經(jīng)過(guò)授權(quán)，通過(guò)指定具體支付能力的方式達(dá)到不同的處理時(shí)限以及有差異性的結(jié)算、清算過(guò)程。
• 以原充值指令號(hào)及該筆充值指令的支付渠道API請(qǐng)求清算層，獲得新的退回API及充退流水號(hào)。
• 使用嵌套分布式事務(wù)，保證賬務(wù)凍結(jié)的處理成功，當(dāng)滿(mǎn)足處理時(shí)限要求后，依序進(jìn)行賬務(wù)結(jié)算以及報(bào)清算處理，見(jiàn)下文關(guān)于異步充退推進(jìn)調(diào)度所述。
• 當(dāng)前協(xié)議下每筆待充退的充值指令，不允許存在活動(dòng)中狀態(tài)的充退指令。

后結(jié)算充退協(xié)議申請(qǐng)：

• 針對(duì)諸如Migs的渠道，支付層提供了后結(jié)算充退協(xié)議供使用，與預(yù)結(jié)算充退協(xié)議不同處在于，完全依賴(lài)清算層的回執(zhí)才進(jìn)行賬務(wù)扣款，并且不存在凍結(jié)、解凍以及失敗回充的動(dòng)作。僅在清算層明確回執(zhí)清算成功后，以實(shí)際清算金額（RMB）為準(zhǔn)進(jìn)行賬務(wù)扣款。
• 由于沒(méi)有事先結(jié)算，理論上清算完成后進(jìn)行賬務(wù)扣款有可能失敗，如：賬戶(hù)余額不足。對(duì)于此類(lèi)場(chǎng)景，系統(tǒng)要不斷重試，直到能夠扣款成功為止。

異步充退推進(jìn)調(diào)度：

使用分布式任務(wù)組件，作為異步充退推進(jìn)處理的調(diào)度策略，這里要完成：

• 結(jié)算：解凍、扣款，注意如果是后結(jié)算充退協(xié)議則不需要進(jìn)行此類(lèi)賬務(wù)處理。
• 清算：報(bào)送清算指令。

調(diào)度任務(wù)中只負(fù)責(zé)識(shí)別出當(dāng)前待推進(jìn)處理的指令集合，交由獨(dú)立門(mén)面服務(wù)進(jìn)行上述處理。此門(mén)面服務(wù)需要對(duì)外開(kāi)放，如系統(tǒng)約定對(duì)于大客戶(hù)充退申請(qǐng)的處理時(shí)限，業(yè)務(wù)部門(mén)可能對(duì)其進(jìn)行臨時(shí)干預(yù)，要求立即完成清算，把這個(gè)服務(wù)釋放出去，供管理平臺(tái)調(diào)用。

重要：待推進(jìn)處理的指令集，所對(duì)應(yīng)的通道API必須處于可用狀態(tài)，如大客戶(hù)所申請(qǐng)的標(biāo)準(zhǔn)卡通類(lèi)充退，我們不希望在其通道已關(guān)閉的情況仍對(duì)其進(jìn)行扣款、報(bào)清算處理。

異步充退超時(shí)調(diào)度：

• 處于結(jié)算成本以及客戶(hù)引導(dǎo)的原因，結(jié)算人員對(duì)客戶(hù)發(fā)起某些金融機(jī)構(gòu)下的充退是不給予處理的。同時(shí)某些充退在申請(qǐng)時(shí)其通道是可用的，而推進(jìn)處理時(shí)則發(fā)現(xiàn)通道已關(guān)閉，此類(lèi)充退指令則一直處于待推進(jìn)狀態(tài)。
• 為此類(lèi)申請(qǐng)?jiān)O(shè)置超時(shí)時(shí)間，如7日內(nèi)仍處于申請(qǐng)狀態(tài)的，則將其充退凍結(jié)款項(xiàng)進(jìn)行解凍處理。

接收充退清算回執(zhí)：

當(dāng)清算層與金額機(jī)構(gòu)清算完畢，業(yè)務(wù)對(duì)賬完成后，清算層將清算結(jié)果回執(zhí)給支付層，支付層進(jìn)行后續(xù)處理。

• 結(jié)算：當(dāng)清算失敗則進(jìn)行回充；注意如果是后結(jié)算充退協(xié)議則僅在清算成功的狀態(tài)下發(fā)起扣款，清算失敗不做賬務(wù)處理；
• 業(yè)務(wù)分流：發(fā)送協(xié)議推進(jìn)處理事件。

單筆充退指令取消：

允許異步充值指令的取消行為，所遵循的處理原則有：

• 外部系統(tǒng)請(qǐng)求支付層取消某一筆充退指令，如果是預(yù)結(jié)算的，只有該支付指令處于預(yù)授權(quán)狀態(tài)放可進(jìn)行取消。對(duì)于后結(jié)算充退指令，只要該筆充退指令沒(méi)有報(bào)送至清算層均可被取消。
• 預(yù)結(jié)算充退指令取消要完成賬務(wù)解凍處理。
• 如果當(dāng)前狀態(tài)不允許進(jìn)行取消，則外部系統(tǒng)需要請(qǐng)求清算層進(jìn)行取消。復(fù)核清算層的取消規(guī)則后，清算層會(huì)以清算失敗的狀態(tài)異步回執(zhí)支付層，則支付層進(jìn)行失敗回充。

人工充退指令推進(jìn)：

見(jiàn)上述異步充退推進(jìn)調(diào)度中所使用的獨(dú)立門(mén)面服務(wù)，完成結(jié)算以及報(bào)清算處理過(guò)程。

充退匯總查詢(xún)：

獨(dú)立的門(mén)面服務(wù)，支付層內(nèi)部以及外部系統(tǒng)均可使用此服務(wù)，用以解釋指定的充值指令所對(duì)應(yīng)的所有充退指令集合，包括每筆充退指令的金額、狀態(tài)等。

服務(wù)使用者可通過(guò)此服務(wù)的結(jié)果輸出，決定是否繼續(xù)接受針對(duì)本充值指令的充退請(qǐng)求，如：支付層收到產(chǎn)品的充退協(xié)議申請(qǐng)，自我完成對(duì)“一筆充值指令最多只能存在一筆活動(dòng)中狀態(tài)的充退指令”約束規(guī)則檢查。

可充退額度統(tǒng)計(jì)：

用以統(tǒng)計(jì)每筆充值指令當(dāng)前可充退金額，如前臺(tái)會(huì)員自助充退則需要獲得此統(tǒng)計(jì)金額進(jìn)行控制。

計(jì)算規(guī)則如下：

當(dāng)前可充退金額=充值指令總額 — （所有此充值指令下充退指令成功金額總和+ 所有此充值指令下充退指令處于活動(dòng)狀態(tài)的金額總和）

此服務(wù)接口可接受批量充值指令的可充退額度統(tǒng)計(jì)。

充退高可用性的渠道配置：

對(duì)于業(yè)務(wù)部門(mén)希望一定要將其處理掉的充退申請(qǐng)，比如：某些渠道下的充值指令在發(fā)起充退申請(qǐng)時(shí)，線下文件方式退款失敗了，那么業(yè)務(wù)部門(mén)可能選擇柜面提交的方式再次處理；對(duì)于支付層的要求是識(shí)別出這些高可用性的充退申請(qǐng)，在報(bào)送清算指令時(shí)為其指明此參數(shù)項(xiàng)。

目前的識(shí)別規(guī)則分三個(gè)維度：產(chǎn)品、商戶(hù)(客戶(hù))、渠道，實(shí)際上充退產(chǎn)品在申請(qǐng)充退協(xié)議時(shí)從產(chǎn)品和商戶(hù)的角度來(lái)決定，比如：強(qiáng)制充退產(chǎn)品發(fā)起的充退申請(qǐng)，或者由BD簽約商戶(hù)發(fā)起的充退都是屬于高可用性的充退申請(qǐng)。

而渠道的識(shí)別規(guī)則的充值指令，其充退必然屬于高可用性，渠道的識(shí)別規(guī)則我們不希望產(chǎn)品進(jìn)行管轄，那么識(shí)別的規(guī)則需要產(chǎn)品層與支付層共同協(xié)作完成。

產(chǎn)品申請(qǐng)的充退協(xié)議中如果已指定了高可用性，則無(wú)需再次檢查；產(chǎn)品申請(qǐng)的充退協(xié)議中未指定高可用性，支付層內(nèi)置渠道規(guī)則生效。

各類(lèi)規(guī)則配置管理服務(wù)：

簡(jiǎn)單的介紹一下引入的各類(lèi)配置規(guī)則包括：

• 支付渠道配置管理；
• 與收銀臺(tái)相關(guān)的過(guò)濾配置管理；
• 統(tǒng)一的支付能力配置管理；
• 支付能力與協(xié)議配置管理；
• 分流目標(biāo)管理；
• 充值后凍結(jié)渠道配置管理。

以上各類(lèi)規(guī)則配置，支付層均需開(kāi)設(shè)相應(yīng)的管理服務(wù)供管理平臺(tái)使用。

業(yè)務(wù)回執(zhí)分流器：

本講說(shuō)的支付層重要的基礎(chǔ)設(shè)施之一，負(fù)責(zé)完成與支付業(yè)務(wù)處理無(wú)關(guān)的業(yè)務(wù)回執(zhí)分流工作，作為支付層與其他產(chǎn)品系統(tǒng)的通訊支撐。

分流器需要解決如下幾個(gè)問(wèn)題：

（1）Target

回執(zhí)的目標(biāo)，即需要將支付結(jié)果通知給誰(shuí)，通過(guò)預(yù)定義的分流目標(biāo)配置數(shù)據(jù)，我們將各類(lèi)產(chǎn)品的接收支付層回執(zhí)服務(wù)地址、通訊方式、通訊質(zhì)量等記錄起來(lái)，作為初始的回執(zhí)目標(biāo)。新產(chǎn)品上線，輔以管理平臺(tái)的功能菜單，達(dá)到回執(zhí)目標(biāo)數(shù)據(jù)可靈活配置。

（2）Context

回執(zhí)給目標(biāo)的信息，當(dāng)請(qǐng)求支付層的支付協(xié)議如充值協(xié)議，在充值轉(zhuǎn)支付場(chǎng)景下，交易系統(tǒng)需要得到支付層的響應(yīng)：充值是否成功、充值金額等。

context有兩種注冊(cè)方式：一種是包含在協(xié)議申請(qǐng)單據(jù)中，一種是無(wú)任何充值背景的、純利用此組件進(jìn)行業(yè)務(wù)回執(zhí)，如線下網(wǎng)點(diǎn)等。

支付層回執(zhí)給產(chǎn)品的context包含兩部分：請(qǐng)求者注冊(cè)信息與支付層自有處理結(jié)果信息。

示例：url①+(回執(zhí)者單據(jù)號(hào)② [金額，狀態(tài)，支付渠道…..]③) + (接收者單據(jù)號(hào)④[買(mǎi)家，賣(mài)家，交易金額，商品名稱(chēng)]⑤)

其中：

1. 可以在注冊(cè)請(qǐng)求中指定該url，也可以由支付層通過(guò)配置獲取，以請(qǐng)求中指定優(yōu)先；
2. 必選，代表著希望告訴對(duì)方系統(tǒng)處理結(jié)果的唯一單據(jù)號(hào)；
3. 可選，解釋該單據(jù)號(hào)的關(guān)聯(lián)要素信息；
4. 必選，代表中接收者唯一可識(shí)別的業(yè)務(wù)單據(jù)號(hào)；
5. 可選，解釋該單據(jù)號(hào)的關(guān)聯(lián)要素信息。

（3）Strategy

每個(gè)回執(zhí)上下文的處理狀態(tài)可分為：

• 未通知：尚未回執(zhí)至產(chǎn)品層；
• 已通知：已回執(zhí)產(chǎn)品層，但未得到應(yīng)答；
• 成功：已回執(zhí)產(chǎn)品層，得到應(yīng)答，并且后續(xù)處理成功如充退申請(qǐng)成功，終結(jié)狀態(tài)；
• 失敗：已達(dá)到最大嘗試次數(shù)，不再進(jìn)行再次嘗試的終結(jié)狀態(tài)。

分流器與與業(yè)務(wù)邏輯互不侵入，僅僅充當(dāng)通訊工具的角色，原則上分流器不會(huì)自我發(fā)起業(yè)務(wù)回執(zhí)，需要第三者來(lái)通知分流器執(zhí)行回執(zhí)。但分流器本身也擁有一定的處理抉擇權(quán)，如已通知的任務(wù)實(shí)例。

分流器只對(duì)這種場(chǎng)景下的回執(zhí)行為進(jìn)行再次嘗試，直到滿(mǎn)足所指定的最大回執(zhí)次數(shù)為止，分流器只關(guān)心系統(tǒng)間通訊狀態(tài)。

本講說(shuō)的回執(zhí)通訊方式選型為基于ESB的異步通知方式。

業(yè)務(wù)回執(zhí)分流注冊(cè)：

本講有充值/充退背景的業(yè)務(wù)回執(zhí)行為，在組裝申請(qǐng)單據(jù)至支付層時(shí)即設(shè)置了回執(zhí)上下文。而其他子系統(tǒng)也可以直接使用業(yè)務(wù)回執(zhí)分流器完成回執(zhí)，可僅注冊(cè)回執(zhí)上下文信息。

統(tǒng)一支付能力：

設(shè)計(jì)提現(xiàn)、充值、充退領(lǐng)域服務(wù)可配置的支付能力，保證后續(xù)的支付等都可以配置各類(lèi)協(xié)議所使用的差異性支付能力。

領(lǐng)域服務(wù)監(jiān)聽(tīng)器：

這里將分流器建設(shè)成與支付協(xié)議無(wú)關(guān)的系統(tǒng)間共用通訊通道，從而確保分流器本身的穩(wěn)定性；另一方面，各類(lèi)支付協(xié)議如充值協(xié)議的核心領(lǐng)域服務(wù)需要建設(shè)的更加堅(jiān)固、穩(wěn)定，現(xiàn)在需要另外一個(gè)角色來(lái)將兩者連接起來(lái)——領(lǐng)域服務(wù)監(jiān)聽(tīng)器，由其來(lái)決定是否該通知分流器進(jìn)行回執(zhí)。

如上圖，通過(guò)監(jiān)聽(tīng)領(lǐng)域服務(wù)處理結(jié)果，來(lái)識(shí)別是否需要發(fā)起對(duì)產(chǎn)品的回執(zhí)，這樣就讓核心領(lǐng)域服務(wù)層與分流器做到隔離。

這里會(huì)設(shè)置一些識(shí)別規(guī)則，如預(yù)定義網(wǎng)銀充值B2B特定支付渠道，對(duì)于交易產(chǎn)品來(lái)說(shuō)，關(guān)心B2B支付的預(yù)授權(quán)以及清算完成狀態(tài)。實(shí)際上這不是交易產(chǎn)品的約束，而是渠道自身所固有的。

當(dāng)充值協(xié)議申請(qǐng)單據(jù)中指定了回執(zhí)目標(biāo)及回執(zhí)上下文時(shí)，此處依據(jù)所配置的規(guī)則，識(shí)別出來(lái)當(dāng)指令狀態(tài)遷轉(zhuǎn)為預(yù)授權(quán)或清算成功/失敗時(shí)，需要通知分流器進(jìn)行分流，此時(shí)即完成分流任務(wù)的注冊(cè)工作。

當(dāng)充值領(lǐng)域服務(wù)接收到清算層的回執(zhí)如清算成功后，領(lǐng)域服務(wù)完成賬務(wù)充值等業(yè)務(wù)邏輯，通知本監(jiān)聽(tīng)器，包括當(dāng)前充值指令的狀態(tài)、金額等信息。由此后領(lǐng)域服務(wù)不再關(guān)心監(jiān)聽(tīng)器，以及分流器的實(shí)際處理過(guò)程，監(jiān)聽(tīng)器要識(shí)別出當(dāng)前指令狀態(tài)是否需要回執(zhí)產(chǎn)品，滿(mǎn)足條件則通知分流器進(jìn)行回執(zhí)。

業(yè)務(wù)回執(zhí)分流器恢復(fù)調(diào)度：

即前文中所提到的分流器默認(rèn)調(diào)度策略：接收到監(jiān)聽(tīng)器通知但并未執(zhí)行的，或者采取同步回執(zhí)通訊方式的，對(duì)方應(yīng)答丟失的兩種場(chǎng)景下需要進(jìn)行再次嘗試，當(dāng)回執(zhí)次數(shù)超過(guò)指定的上限后即不再?lài)L試。

業(yè)務(wù)回執(zhí)分流器恢復(fù)調(diào)度：

如圖，支付層將對(duì)所有的支付渠道進(jìn)行管理，支付渠道包含了與金融機(jī)構(gòu)交互的清算通道、以及無(wú)需清算類(lèi)的通道，如余額等，所以支付渠道的范圍是大于等于清算通道范圍的。

• 清算層負(fù)責(zé)管理各類(lèi)清算通道的可用性維護(hù)，理論上支付渠道中所包含的清算通道部分沒(méi)有必要一定要與清算層的保持一致，如：狀態(tài)、API的命名等。但某個(gè)清算通道的關(guān)閉/開(kāi)啟，我們希望能夠直接反映至前臺(tái)，基于用戶(hù)體驗(yàn)而考慮，在清算通道發(fā)生關(guān)閉/開(kāi)啟事件后，需要以異步消息通知至支付層。
• 支付層負(fù)責(zé)同步更新該通道的可用狀態(tài)，以此反映至收銀臺(tái)的可供選擇渠道列表。不考慮對(duì)清算層新開(kāi)通的清算通道數(shù)據(jù)做同步，此處需要人工介入。

 

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

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