銀企支付-概要設計文檔
- 2019 年 10 月 15 日
- 筆記
銀企支付-概要設計文檔
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同步數據到關係性資料庫中。若交易量小，可直接存儲到關係型資料庫中。
差錯處理：一次交易失敗可能在不同的環節出現的問題，一次失敗，不應該是所有流程都重新來過，需要根據交易的不同節點，系統定時修復或人為參與做交易失敗記錄的差錯處理。如：銀企系統封裝模組已經執行成功，結果處理模組執行失敗，可調用銀企封裝模組再次推送最終結果，該條支付請求僅對結果處理模組重新處理。（要完成這種基於節點模式的修復，需記錄不同節點向下一節點請求時的關鍵邏輯參數，同時提供啟動介面）。
對賬：根據財務需求，定期導出系統中的交易流水，方便銀行流水與系統流水做數據對比。
