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