中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

支付核心：

一、支付核心和清算核心職責

首先要明確一個概念：一個完整的支付清算系統結構內，各種特定業務所涵蓋的支付服務、清算服務，是相互獨立的。

其獨立性，體現在具體的產品研發過程，以及后期維護等各項工作中：

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

在設計支付清算系統時建議：

將支付核心和清算核心設計為兩層，分為兩個獨立子系統。

1. 支付核心提供適應各類產品使用的基礎支付服務；
2. 清算核心則將所有機構所能提供的底層清算服務歸集，專門負責與銀行的各類清算接口對接。

支付層則對外提供各類經過包裝的支付服務，涵蓋清算服務、賬務服務、客戶相關服務等，實現對基礎支付服務的編排。

二、提現協議系統業務流程分析

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

維度：會員層、提現產品層、支付層、財務核心、清算層、銀行。

（1）同步提現支付協議處理流程圖

會員提交提現申請后，進入提現產品層申請同步提現支付協議，然后進入支付層請求扣款提現金額。此時進入財務核心執行扣款，同時報送清算請求指令進入清算層，報送銀行處理，然后進入銀行執行扣款并返回清算結果。

此時做一個判斷，若清算成功則回執處理結果，并回到提現產品層進行業務處理并通知用戶提現處理結束。若清算失敗則進入財務核心，進行回充。

（2）異步提現支付協議處理流程圖

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

在 T + N 日，運營平臺層執行回導清算結果/文件，進入清算層勾兌清算指令并回執處理結果，進入支付層進行判斷。若清算成功則回執處理結果，并回到提現產品層進行業務處理并通知用戶提現處理結果，若清算失敗則回到清算層進行回充。

（3）退票支付協議的處理流程

這部分內容比較容易理解，這里就不做詳解了。

如圖，將支付與交易分開，主要是為了體現出支付服務機構的核心支付服務功能。

核心支付服務能夠為會員提供豐富個性的支付服務：充值、提現、內/外轉型支付、支付側營銷等內容。

若將交易產品中包裝的相關支付服務，交由支付服務層與清算服務層協作完成，并將交易以及其他產品釋放出來，則產生的整體系統框架圖如下：

三、提現支付協議領域模型

模型總覽：

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

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

提現支付指令里包含了收款方-銀行卡，付款方-支付賬戶的各自支付工具，依據此可拆分出相應的賬務類操作指令與清算類操作指令。

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

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

核心業務邏輯：

以在線用戶發起的正常提現申請為例，整體的交互時序圖如下：

支付層內部處理的交互時序圖

提現支付指令作為提現支付協議的流水數據，其處理生命周期的狀態遷轉如圖所示。

異步提現支付協議下的提現支付指令狀態圖

提現退票支付協議下的提現支付指令狀態圖

同步提現支付協議下的提現支付指令狀態圖

四、提現業務邊界分析

首先，提現業務邊界分析可以拆分為兩大部分：業務用例邊界以及系統用例邊界。

這里著重講一下系統用例邊界，分為：

1. 異步提現支付協議申請；
2. 異步提現支付協議推進處理；
3. 接受清算處理結果回執；
4. 統一協議處理結果回執；
5. 同步提現支付協議申請；
6. 同步提現支付協議推進/恢復處理；
7. 提現退票支付協議；
8. 打款機構；
9. 支付能力；
10. 分布式任務；
11. 公共查詢類服務：協議授權查詢服務、機構信息查詢服務；
12. 提現查詢類服務：銀行卡段檢查服務、對公賬戶聯行號檢查服務、支行列表查詢服務、清算通道支付限額查詢服務；
13. 管理服務：協議授權管理服務、打款機構管理服務、支付能力管理服務、緩存刷新服務。

1.?業務用例邊界

支付層作為提供基礎支付服務的核心系統，所承擔的職責圍繞著以下主要業務功能點：

以協議方式提供適用于各類產品使用的支付服務：

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

承擔包裝清算層所公布的各類底層公共查詢服務，以及獨立提供給產品層的各類公共查詢服務：

以提供公共查詢服務為職責，則分為協議授權查詢、提現統計查詢、銀行卡段檢查、對公賬戶聯行號查詢、機構信息查詢以及清算通道支付限額查詢。

作為協議使用的輔助手段，提供不同協議的干預處理服務：

可提供四種不同的干預處理服務：異步提現支付協議推進、異步提現支付協議取消、同步提現支付協議推進、統一提現支付協議回執。

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

如圖所示，三種不同的管理服務內含不同的核心處理規則配置機制：協議授權管理服務、打款機構配置管理服務、提現支付能力管理服務。

2.?系統用例邊界

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

假設目前公司的產品層尚未成型，那么現有的各類提現相關產品是分散在各個子系統中的，在這種情況下：

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

此圖要點：

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

（1）異步提現支付協議申請

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

參照提現支付協議認領模型設計，產品層可將異步提現支付協議的使用分為：申請、推進處理兩個階段，以及特殊情況下的取消操作。

本文重點描述異步提現支付協議，在申請過程中支付層的體系結構以及處理流程。

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

階段一：

調用者開啟分布式事務，在事務塊內請求異步提現支付協議申請：

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

階段二：

調用者根據支付層協議申請的返回結果，決定提交或回滾分布式事務。

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

異步提現支付協議推進處理：

異步提現支付協議在申請階段只是將提現額做了凍結，后續處理是通過支付層的調度任務根據優先級以及可執行時間按順序處理，包括對支付指令的賬務解凍、扣款、報送清算指令等步驟。

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

支付層自行調度的推進處理：

1. 加載協議數據，激活領域模型對象；
2. 執行結算處理，包括賬務解凍與扣款；
3. 執行報清算處理，通過確保達到的ESB消息通知清算層執行清算。

產品層通知方式的推進處理：

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

1）異步提現支付協議取消/接受清算處理結果回執

異步提現支付協議取消：

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

需要注意的是：

• 只有處于已預授權狀態的支付指令才可以被取消，如果已經扣款或者已報清算，則不允許在支付層發起取消。產品可以通過致使清算指令失敗的方式令支付指令失敗，達到取消的效果。
• 請求賬務執行解凍處理。
• 通知產品層代理者本提現流水已取消。

接受清算處理結果回執：

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

需要注意的是：

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

全局系統中有多處業務場景使用提現取消服務，如風控的申請后拒絕行為，客服的提現失敗任務，以及后臺凍結賬戶等，都需要取消指定的提現申請記錄。

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

相應的，如果請求者發生異常而回滾分布式事務，支付層必須確保協議整體模型數據恢復至取消前狀態（包括金額等關鍵數據要素），而不能與其他基于分布式事務的申請服務一樣，將數據刪除。

同時，支付層必須確保在請求者提交分布式事務后，才能發送回執消息給產品層代理者。不允許在業務處理內部發送回執消息，否則一旦請求者回滾事務，此消息無法刪除。

2）統一協議處理結果回執/同步提現支付協議申請

統一協議處理結果回執：

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

（2）同步提現支付協議申請

對于需要同步支付并清算的提現產品，使用本協議。同異步提現支付協議，本協議也可以使用嵌套分布式事務。

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

階段一：

調用者開啟分布式事務，在事務塊內請求異步提現支付協議申請。

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

階段二：

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

階段三：

調用者分布式事務提交后，采用主動調用同步提現支付協議的推進處理服務，通知進行后續處理。

1）同步提現支付協議推進/恢復處理

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

如果支付層在請求同步清算時出現了嚴重異常，如清算層異常宕機或清算返回丟失，則仍然返回產品處理中結果，支付層內部回復程序會繼續嘗試回復。

2）提現退票支付協議

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

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

1. 只有處理成功的支付指令才可以被退票；
2. 每一筆支付指令最多只能被退票一次；
3. 退票金額為原支付指令的實付金額；
4. 新產生的（退票）支付指令建立起與原支付指令的關聯關系；
5. 對于退票申請處理中，如果請求賬務失敗，則本次申請失敗。

3）打款機構/支付能力/分布式任務

打款機構：

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

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

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

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

分布式任務：

支付層的大量調度任務，如：異步提現支付協議的推進、同步提現支付協議的掉單恢復等，將來會有更多的調度任務加入。

考慮到線上環境是多服務器并發處理任務的，對于這種分布式任務需要解決兩個問題：

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

支付能力：

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

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

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

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

4）其他服務類

公共查詢類服務：

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

提現查詢類服務：

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

管理服務：

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

本地緩存：

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

1. 機構信息查詢結果；
2. 清算通道支付限額查詢結果；
3. 支行列表查詢結果。

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

1. 協議授權關系列表；打款機構規則列表；
2. 支付能力列表。

五、充值系統業務流程分析

充值協議處理主體流程圖（充值遵守的系統處理原則：先清算，后結算）：

充值協議處理主體流程圖（充退遵循的系統處理原則：先結算，后清算）：

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

六、充值協議系統級架構和領域模型

系統整體架構

我們從多個視角來快速瀏覽支付層的整體系統架構：

模型總覽

這里需要指出的是，充值協議不存在支付層處理的時限性，全部都是實時報送清算層完成的。引入的異步處理類充值協議并不是非實時報送清算層，而是由于金融機構回執給清算層的清算結果是異步的，今兒演變為清算回執異步通知至支付層。

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

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

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

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

核心業務邏輯

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

清算層在處理完金融機構的清算結果通知后，回執給支付層：

重要的規則、約束、平衡檢查如下：

• 產品所使用的充值協議必須經過授權，處于開通狀態；
• 必須指定支付渠道API；
• 原則上受理的充值額度區間為：0<額<= 無限大;目前的充值申請均由統一收銀臺發起，相關特定渠道的充值限額已由收銀臺進行控制，支付層不對充值額度再次檢查；
• 賬務充值動作，必須在清算層明確回執銀行清算成功后方可進行，實際充值金額以清算層回執金額為準。

充值指令的狀態遷轉

如圖所示：

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

七、充退協議領域模型

模型總覽

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

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

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

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

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

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

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

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

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

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

另外，支付層分流器以異步消息通知的方式完成回執，交易或繳費類產品在自身業務推進處理失敗時，統一報送可疑事件至此代理，由其來識別各類可充退規則配置，決定是否向支付層發起充退協議申請。

鑒于此，支付層提供的充退協議遵循一筆充值指令，最多只能有一筆處于活動狀態充退指令的約束。同樣的原因，充退協議也不再引入協議明細項，直接建立協議與指令的關系；

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

核心業務邏輯

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

注：對于后結算充退協議，指令狀態直接遷轉為已報送清算狀態，在等待清算回執后再做賬務結算。

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

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

充值協議領域模型VS充退協議領域模型：

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

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

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

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

八、充值業務邊界分析

業務用例邊界：

充值業務在支付層設計的業務用例主要包括以下若干模塊：

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

系統用例邊界：

網銀充值協議申請：

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

基本流程示意圖：

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

代金卡（充值碼）充值協議申請：

網銀充值協議申請后所返回的跳轉表單對象，供收銀臺跳轉至金融機構。而代金卡的充值處理中收銀臺，無需獲取跳轉表單對象。這里有可能是代金卡獨立業務系統，已明確了跳轉表單對象，所以這個充值協議的處理過程，僅是將支付流水與清算流水記錄即可，等待外部（百聯）系統對清算層的回執發生后發起結算行為。

代金卡充值協議需要收取手續費，在報送的協議申請單據中需要指定待凍結的金額，支付層充值領域服務完成充值后，即發起對充值賬戶的凍結處理。

快捷充值協議申請：

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

接受充值清算回執：

• 對于網銀充值需要用戶進行操作的，清算層異步通知支付層金融機構的清算結算；
• 快捷充值或網匯E類無需確認的，考慮到清算層實時通知支付層有可能出現掉單，此處也作為業務恢復點。

1. 必須以清算回執的實際清算金額為準進行賬務充值處理；
2. 發送協議推進處理事件必須在結算行為事務塊之內完成，即確保結算完成，且分流任務被啟動。

無清算充值協議申請：

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

COD是支付機構內系統最先獲知此充值請求的，由它來通知支付層創建充值協議并立即完成結算行為，在此之前支付層并無任何單據信息。

為此，支付層需要為COD模式的業務開設專用的充值協議，即所有單據據要素已由調用者收集完畢，并使用此協議完成充值，注意支付層此時的處理僅結算即可，無需再次與清算層發生關系。

這個時候可以把COD當成是業務產品在使用此充值協議，由于金額機構系統不會再次通知COD，當它們完成自身業務處理后，使用高質量確保的異步消息通知支付層形式，來完成本次充值。

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

充值后通知事件：

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

支付與清算系統掉單恢復：

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

充值協議查詢：

用以解釋當前充值訂單處理狀態，當清算層push相關信息至收銀臺后，收銀臺使用此服務獲知處理結果并顯示用戶。

此服務不限于僅在此場景下被使用：

• 處理成功狀態：充值成功，業務分流后產品處理成功；
• 充值成功狀態：僅充值成功，業務分流后產品處理失敗或未知狀態；
• 充值失敗狀態：充值失敗，無論業務分流是何結果。

預結算充退協議申請：

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

后結算充退協議申請：

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

異步充退推進調度：

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

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

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

重要：待推進處理的指令集，所對應的通道API必須處于可用狀態，如大客戶所申請的標準卡通類充退，我們不希望在其通道已關閉的情況仍對其進行扣款、報清算處理。

異步充退超時調度：

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

接收充退清算回執：

當清算層與金額機構清算完畢，業務對賬完成后，清算層將清算結果回執給支付層，支付層進行后續處理。

• 結算：當清算失敗則進行回充；注意如果是后結算充退協議則僅在清算成功的狀態下發起扣款，清算失敗不做賬務處理；
• 業務分流：發送協議推進處理事件。

單筆充退指令取消：

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

• 外部系統請求支付層取消某一筆充退指令，如果是預結算的，只有該支付指令處于預授權狀態放可進行取消。對于后結算充退指令，只要該筆充退指令沒有報送至清算層均可被取消。
• 預結算充退指令取消要完成賬務解凍處理。
• 如果當前狀態不允許進行取消，則外部系統需要請求清算層進行取消。復核清算層的取消規則后，清算層會以清算失敗的狀態異步回執支付層，則支付層進行失敗回充。

人工充退指令推進：

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

充退匯總查詢：

獨立的門面服務，支付層內部以及外部系統均可使用此服務，用以解釋指定的充值指令所對應的所有充退指令集合，包括每筆充退指令的金額、狀態等。

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

可充退額度統計：

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

計算規則如下：

當前可充退金額=充值指令總額 — （所有此充值指令下充退指令成功金額總和+ 所有此充值指令下充退指令處于活動狀態的金額總和）

此服務接口可接受批量充值指令的可充退額度統計。

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

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

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

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

產品申請的充退協議中如果已指定了高可用性，則無需再次檢查；產品申請的充退協議中未指定高可用性，支付層內置渠道規則生效。

各類規則配置管理服務：

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

• 支付渠道配置管理；
• 與收銀臺相關的過濾配置管理；
• 統一的支付能力配置管理；
• 支付能力與協議配置管理；
• 分流目標管理；
• 充值后凍結渠道配置管理。

以上各類規則配置，支付層均需開設相應的管理服務供管理平臺使用。

業務回執分流器：

本講說的支付層重要的基礎設施之一，負責完成與支付業務處理無關的業務回執分流工作，作為支付層與其他產品系統的通訊支撐。

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

（1）Target

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

（2）Context

回執給目標的信息，當請求支付層的支付協議如充值協議，在充值轉支付場景下，交易系統需要得到支付層的響應：充值是否成功、充值金額等。

context有兩種注冊方式：一種是包含在協議申請單據中，一種是無任何充值背景的、純利用此組件進行業務回執，如線下網點等。

支付層回執給產品的context包含兩部分：請求者注冊信息與支付層自有處理結果信息。

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

其中：

1. 可以在注冊請求中指定該url，也可以由支付層通過配置獲取，以請求中指定優先；
2. 必選，代表著希望告訴對方系統處理結果的唯一單據號；
3. 可選，解釋該單據號的關聯要素信息；
4. 必選，代表中接收者唯一可識別的業務單據號；
5. 可選，解釋該單據號的關聯要素信息。

（3）Strategy

每個回執上下文的處理狀態可分為：

• 未通知：尚未回執至產品層；
• 已通知：已回執產品層，但未得到應答；
• 成功：已回執產品層，得到應答，并且后續處理成功如充退申請成功，終結狀態；
• 失?。?/strong>已達到最大嘗試次數，不再進行再次嘗試的終結狀態。