銀企支付-概要設計文件
目錄
- 銀企支付-概要設計文件
- 1、背景
- 2、基本概念
- 3、銀企支付流程說明
- 4、參考文件
銀企支付-概要設計文件
1、背景
本文介紹一般銀企支付的相關流程。一個支付體系需包括校驗，風控，支付路由、支付閘道器模組、具備基本支付，退款，轉賬能力，可查詢支付記錄，還應具備相關的支付監控模組和差錯處理模組。
2、基本概念
2.1、支付校驗
在業務受理前，為了保證介面的安全性，受理介面要依次驗證支付請求報文的安全性、使用者的許可權、引數的合法性。儘量保證受理介面只做基礎驗證，對其他複雜的的驗證流程，進行非同步處理，受理無法通過的，設定交易為失敗狀態，直接同步反饋給呼叫方。
2.2、風控
風險控制，是識別異常交易並加以額外驗證的模組，在支付系統中是不可缺少的一環。風控並不能完全避免資金損失，只能儘量減少損失。不同業務的風控要素不同，一般風控包括如下要素：
- 交易量風控，可設定交易金額區間，對不合規的交易請求直接駁回。
- 交易頻率風控，設定不同交易分類的交易頻率閥值，對過高頻率的請求，直接駁回。
- 交易習慣性風控，針對單個或某組使用者群體，做使用者畫像行為分析，對反常的交易請求，做二次確認驗證（如手機驗證碼）。
2.3、支付路由
對支付系統來說，支付路由是指一個三方支付公司分配的一個商戶號，當然它也可以更細地劃分，如新增卡型別、銀行等維度。客戶端選擇不同的支付路由，涉及到最終不同的支付交易邏輯。舉例：
- 路由1：客戶端選擇支付寶支付，支付路由為客戶->支付寶交易流程。
- 路由2：客戶端選擇浦發銀行支付，支付路由為客戶->浦發銀行。
2.4、支付閘道器
支付閘道器是支付系統與三方系統的互動介面，支付閘道器的設計要考慮的重點是報文的互動。除了普通系統要進行的引數驗證、內外系統引數對映、各種請求類的包裝外，支付系統要額外考慮的有報文簽名和加密，系統互動詳細日誌。
2.5、監控
支付系統的監控主要是在業務層面上的監控。一般監控交易異常、路由異常等影響正常交易的狀況，並及時報警告知運營或技術人員。監控還可提供一條交易資訊的完整交易流程，方便運維人員檢視交易在不同節點的明細情況。監控方式一般有：
- 統計法：定時對比統計資料與監控閾值，在統計資料的異常比例超出監控閾值時觸發報警。
- 試探法：以測試交易來定時試探系統的穩定性和三方通道的穩定性。
- 埋點法：在支付關鍵節點埋點，並檢驗交易狀態是否在期望狀態。
2.6、差錯處理
監控出異常的交易記錄後，可對部分交易異常資料，在不同節點做補償修正。通過程式或人為的重新啟動該條資料在錯誤節點的交易支付請求，從而修正異常交易流水。
2.7、對賬
對賬是對前一日交易在全域性上的對照，不同於賬務和資金管理系統，對賬是在資料流上確定交易的正確性，一般的對賬流程如下：
- 下載對賬檔案 針對各三方系統的下載方式：FTP/HTTP 獲取到對賬檔案
- 標準化處理：將格式為 txt/xml/cvs/zip 的三方系統對賬檔案處理成一種選用格式；
- 本地對賬準備：可以根據資料量的大小，從源庫/從庫/nosql/檔案方式準備與三方系統對賬檔案的對比
- 兩個賬務資料對比。
- 差異資料修復(人工/後續)
3、銀企支付流程說明
3.1、流程分段
劃分一個支付流程為三部分，分別為支付前置（初始化支付相關引數），支付路由和支付實現（第三方系統對接，如銀行，支付寶對接），支付後的業務結果處理。
整個支付流程獨立支付路由和支付實現模組。支付路由和支付實現板塊為通用模組，不和具體業務相關。
業務與支付，與後續結果處理採用適配的模式，不同業務發起支付，需要配置對應的支付路由，配置對應的結果處理。三個支付流程，可自由組合配置。
如：訂單支付，設定支付路由為支付寶，結果處理為訂單完善的相關業務。
如：報銷處理，設定支付路由為銀企處理，結果處理為報銷相關業務。3.2、流程明細
1.客戶端根據業務需求，發起支付請求。
2.業務受理模組接收到客戶端發起的支付請求，依次做支付基礎資料校驗，風控驗證，並根據業務選擇的支付型別（如銀企或轉賬）做路由選擇。業務受理成功後，同步回執受理結果給客戶端。
3.業務受理模組，採用多執行緒模式，根據支付請求引數，設定不同的路由，組裝支付引數，構建一個支付請求mns訊息(或者發起Spring boot事件)，發起一個支付任務。
4.銀企系統封裝模組接收到事件通知後，開啟一個執行緒，做業務支付與銀行對接任務。在銀行與企業對接時，需根據銀行的要求組裝支付閘道器資料（資料格式，簽名認證），並非同步等待銀行回執結果或主動獲取銀行反饋的終態結果。整個請求需保證冪等性並記錄互動流程的明細日誌（如請求引數，反饋引數，請求耗時）。銀企系統封裝層流程處理完成後，通過事件模式，發起一個非同步任務給結果處理模組。
5.支付流水與第三方系統的支付流程完成後，流轉到結果處理模組，根據與銀行處理的結果，記錄交易流水，並記錄最終該筆支付請求的終態結果（一次請求到底是失敗還是成功）。同時，完善該筆交易的業務狀態。
6.結果處理板塊完成後，反饋終態結果給客戶端。
監控：各個環節，需記錄該環節的詳細日誌，便於在交易失敗時，做問題定位和修正。一條交易記錄，最終應具備在不同環節都有詳細流程資訊，可查詢到交易資訊的完善生命週期。若交易量大，可先記錄日誌到快取Redis中，通過Redis同步資料到關係性資料庫中。若交易量小，可直接儲存到關係型資料庫中。
差錯處理：一次交易失敗可能在不同的環節出現的問題，一次失敗，不應該是所有流程都重新來過，需要根據交易的不同節點，系統定時修復或人為參與做交易失敗記錄的差錯處理。如：銀企系統封裝模組已經執行成功，結果處理模組執行失敗，可呼叫銀企封裝模組再次推送最終結果，該條支付請求僅對結果處理模組重新處理。（要完成這種基於節點模式的修復，需記錄不同節點向下一節點請求時的關鍵邏輯引數，同時提供啟動介面）。
對賬：根據財務需求，定期匯出系統中的交易流水，方便銀行流水與系統流水做資料對比。
4、參考文件
- 1.《支付系統設計》
- 2.《我的支付總結（一） 基礎概念》
- 3.《我的支付總結（二） 系統設計》