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

支付核心：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

核心支付服務(wù)能夠為會員提供豐富個性的支付服務(wù)：充值、提現(xiàn)、內(nèi)/外轉(zhuǎn)型支付、支付側(cè)營銷等內(nèi)容。

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

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

模型總覽：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

此圖要點：

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

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

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

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

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

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

階段一：

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

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

階段二：

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

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

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

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

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

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

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

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

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

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

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

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

需要注意的是：

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

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

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

需要注意的是：

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

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

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

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

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

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

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

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

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

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

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

階段一：

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

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

階段二：

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

階段三：

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

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

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

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

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

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

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

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

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

打款機構(gòu)：

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

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

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

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

分布式任務(wù)：

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

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

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

支付能力：

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

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

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

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

4）其他服務(wù)類

公共查詢類服務(wù)：

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

提現(xiàn)查詢類服務(wù)：

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

管理服務(wù)：

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

本地緩存：

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

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

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

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

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

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

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

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

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

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

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

模型總覽

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

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

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

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

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

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

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

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

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

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

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

如圖所示：

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

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

模型總覽

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基本流程示意圖：

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

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

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

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

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

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

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

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

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

無清算充值協(xié)議申請：

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

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

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

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

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

充值后通知事件：

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

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

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

充值協(xié)議查詢：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

單筆充退指令取消：

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

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

人工充退指令推進：

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

充退匯總查詢：

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

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

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

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

計算規(guī)則如下：

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

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

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

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

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

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

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

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

簡單的介紹一下引入的各類配置規(guī)則包括：

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

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

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

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

分流器需要解決如下幾個問題：

（1）Target

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

（2）Context

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

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

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

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

其中：

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

（3）Strategy

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

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