支付通道系統功能

支付前置

着業務定製化對交易支付需求複雜度的增長, 交易系統保證系統穩定的同時, 亦需靈活性, 靈活意味着可配置化. 支付前置負責解決支持業務變化的擴展性, 將交易經過支付前置的配置轉化爲後端支付系統能統一處理的模式, 方便後端多樣化的記帳需求.

功能定義

支付前置包裝後端支付核心系統的接口, 包裝後對外提供的服務包括餘額, 現金, 網銀, 快捷支付, 出款及相關訂單的退款和控制接口; 另提供後臺系統調用的服務包括肯定性入款, 登帳, 凍結解凍, 退票等. 全部的支付行爲都會以業務支付訂單的形式落地.

用戶在前端發起一次支付行爲後, 交易系統基於原始的交易訂單, 對應生成一條付款訂單, 經過這筆付款訂單和支付核心進行交互。

業務產品碼

交易系統各種交易接口包裝成業務產品(提現, 充值等)後, 將對應的支付請求發送到支付前置系統, 前置系統根據業務產品編碼和自己的支付業務配置關係, 生成對應的業務支付訂單並處理後續流程.

支付產品碼

因爲即時到帳, 擔保交易在業務規則上不一樣, 但支付渠道側判斷均爲支付, 所以支付產品碼相同但業務產品碼不一樣. 這裏的支付產品編碼配置來自於支付協議的配置, 一個支付產品編碼表明着一個支付協議.

支付協議

支付協議即對支付模式, 支付服務的封裝.

以收單支付爲例, 某個業務方在支付系統開設支付權限後, 可理解爲與支付系統自己簽署了收單支付協議, 便可經過交易系統對外輸出擔保交易產品和即時到帳產品來使用收單支付的能力.

此時交易側定義的兩個業務產品碼, 與支付側的收單支付產品編碼爲多對一關係, 交易系統調用前置系統時, 根據交易產品代碼和支付協議的配置, 對應生成一條收單支付的請求, 前置系統根據該請求轉化爲對應的付款訂單(支付協議的明細項, 好比經過網銀, 現金, 快捷等方式發起支付), 而後根據對應支付模式和業務支付類型生成業務支付訂單, 且將業務支付訂單轉化爲支付指令去執行下游系統的流程.

提現協議 以提現協議爲例, 提現的明細項關聯着業務方所傳遞的外部訂單號, 表明着此次業務支付行爲的原始訂單請求, 對應着收付款人的信息.

調用支付服務層的時, 會有客戶權限校驗等判斷, 經過的狀況下此時去調用支付協議的配置信息落地一筆支付訂單, 並基於該訂單生成對應的一筆或者多筆支付指令, 接下來由指令去執行調用下游系統的具體方式, 如果調用清算通道則生成清算類的操做指令(調用通道, 調用時間, 通道須要的信息等), 可稱爲外部指令, 如果要操做帳戶金額則生成帳務類的操做指令(具體帳戶, 金額, 借記仍是貸記), 可稱爲內部指令.

支付引擎

支付引擎的類型

定義支付的原子級支付形態, 全部的支付行爲都是帳戶資金的流轉, 可梳理出如下幾個支付類型

• 充值: 資金從外部資金源向內部資金源轉移

• 提現: 資金從內部資金源向外部資金源轉移

• 內轉支付(轉帳): 資金在內部帳戶轉移, 這裏的定義和產品中定義的轉帳概念不一樣

• 退款: 充值的反向操做

指令

指令即支付核心的工單號, 前置的每筆支付訂單對應着一筆甚至多筆指令. 指令裏包含了這筆支付訂單的

• 原子支付類型(充值, 提現, 轉帳, 退款), 指令必定是基於原子支付類型來生成的, 任何支付行爲都能被原子類型所支持

• 對應着的業務請求類型

• 支付方式

• 支付產品編碼

• 參與方信息(交易中收付款人的信息)

• 相關聯的支付指令信息(退款時用於關聯原支付指令)

• 支付服務流程等相關信息

由支付指令去調用支付服務流程時, 再根據流程編排環節去肯定什麼時候生成帳務類操做指令和清算類操做指令.

舉例 用戶在電商網站購買一本書價格 100 元,

1. 經過支付寶付款, 交易類型爲擔保交易,

2. 在交易核心生成一筆擔保支付的訂單,

3. 調用支付核心系統時支付系統判斷該業務調用方對應已經配置了「收單支付協議」, 且根據對應協議生成一筆業務類型爲第三方支付的支付訂單

4. 基於此訂單生成了第一條充值的支付指令.

5. 該指令在根據支付類型去調用服務流程時，先經過流程編排生成清算指令並調用(這裏值得注意的是, 先生成清算指令的緣由在於須要先調用外部支付渠道, 把錢收進來)

6. 用戶付款成功後再生成帳務指令並調用帳務核心, 執行內部帳務入帳

服務流程

定義支付指令的執行流程, 將支付拆分紅原子支付類型, 並對支付類型的流程進行編排, 任何一個交易的請求, 都能由上述四種原子支付類型組合完成支付行爲.

例如: 一筆擔保收單的交易, 用戶用支付寶等第三方支付完成了這筆交易, 並在 7 天后確認收貨, 平臺側 7 天后根據用戶的行爲應該將該筆貨款打給了商戶. 這裏咱們將用戶的行爲分爲支付和確認收貨兩個動做, 對應着在交易側 = 兩次請求 + 一次支付 + 一次結算:

• 在支付層對應收單支付協議

• 在前置系統被拆分紅了兩筆業務支付訂單, 一筆是快捷支付, 業務類型自定義, 能夠叫第三方支付; 一筆是餘額轉帳, 將資金從擔保帳戶結算到商家帳戶

• 分別生成兩條支付指令, 充值和轉帳. 充值表明着用戶的支付行爲, 轉帳表明着用戶的確認收貨行爲, 由於從但保護結算到商家帳戶, 能夠定義爲一筆帳戶之間的資金流轉

風控

支付系統設計中, 提高自身的風控意識, 爲交易增長風控模塊, 能夠有效減小風險交易形成的資金損失. 支付核心的風控模塊, 通常位於交易處理的最前端, 每筆交易經過風控模塊的檢驗後, 才容許支付核心進行後續的交易處理.

業務規則

爲支付核心設計交易流程和業務規則時, 瞭解交易中可能發現的風險因素並注意異常環節, 是攔截風險交易的有效途徑. 對於一些常見的支付產品, 已經造成了一些可以有效防範風險交易的通用業務規則.

舉例: 我的餘額帳戶的風控規則 用戶使用餘額帳戶進行首次充值時, 必須經過帳戶信息的實名認證. 因爲銀行會對持卡人的身份進行實名認證, 因此對平臺能夠經過銀行或支付機構提供的銀行卡信息驗證接口對用戶進行實名認證.

實名認證使用四要素, 須要驗證姓名, 身份證號, 銀行卡號, 手機號. 完成實名認證後, 用戶必須設置支付密碼, 後續自消費和提現時, 使用支付密碼保證餘額資金的安全.

用戶更換餘額帳戶提現銀行卡時, 必須對已綁定的銀行卡進行進行校驗, 要求用戶輸入已綁定銀行的完整帳號和綁定手機號, 同時新綁定的提現銀行卡, 也必須和帳戶已驗證的身份信息一致.

經過以上措施可有效防止用戶因我的信息泄漏形成的餘額帳戶資金損失.

風控模型

風控模型, 是依賴可獲取的交易信息和客戶信息抽象出的風險交易特徵, 可用於抽象分析風險交易特徵的主要有三類:

• 交易信息: 當前交易自身的信息要素, 例如交易類型, 交易金額, 交易時間, 支付帳號等信息

• 客戶信息: 發起該筆交易的平臺用戶信息, 包括用戶使用的設備類型, 設備編號, 用戶定位信息, 用戶手機號, 手機號歸屬地等

• 歷史數據: 用戶在平臺發生過歷史交易, 其歷史交易的交易信息和用戶信息

經過對已發生的風險交易, 分析上述信息便可抽象出風控模型, 供風控模塊識別風險交易

風控運營

對於風控模塊識別出的風險交易, 根據危害程度的等級不一樣, 分爲「事前攔截」和「事中審覈」兩種處理機制.

對於命中風險交易的交易請求, 採用事前攔截的處理機制, 由風控模塊直接拒絕交易

對於疑似風險交易的, 進入風控模塊的待審覈交易列表, 由風控專員對可疑交易進行人工審覈. 審覈後認爲是風險交易的, 則拒絕交易, 審覈後不屬於風險交易的則由支付核心繼續後續的交易處理

內部控臺

支付核心須要爲內部的運營, 財務, 管理層提供查看交易數據的可視化管理網站

交易操做

• 業務運營人員, 須要對支付系統中已經發生的交易進行檢索, 確認某一具體交易的交易狀態

• 對於某一筆具體交易，進行退款操做

• 內部控臺要爲業務運營人員提供交易操做入口

交易數據展現

展現整個平臺的業務運做狀況, 支付系統經過內部控臺提供交易總額, 訂單轉化率, 支付渠道佔比等可視化的數據圖表, 直觀展現交易數據的變化狀況

報表下載

將歷史交易數據整理爲交易報表, 供相關人員如下載的方式直接獲取

權限控制

• 內部控臺要限制僅能夠經過公司內網訪問, 並控制能夠查看數據的人員數量

• 具備數據查看權限的人員, 須要對數據安全和資金安全負責

• 用戶的卡號姓名等信息, 要作脫敏顯示, 預防用戶信息泄露

報表

支付系統負責將交易數據按期整理爲報表, 供有關人員下載使用

交易報表

按照固定的時間週期, 將支付系統中已成功處理的交易流水生成交易報表. 交易報表展現的交易流水, 須要按照交易系統支持的交易服務類型分別生成.

支付交易, 充值交易, 出款交易在交易數據信息上各不相同, 須要分別出具獨立的交易報表, 通常按照日周月爲時間維度, 固定出具交易報表, 交易報表中除了提供交易流水明細, 還須要提供該時間週期內的彙總數據, 方便使用者快速瞭解這個時間段內的交易狀況.

結算報表

支付系統的清算核心對帳戶中資金進行結算時生成結算報表, 供運營或財務進行付款前的確認或者做爲付款憑證做爲後續查帳和審覈的依據. 面向內部人員使用的結算報表能夠根據本系統的業務需求增長其餘信息字段, 以便於更好地瞭解結算交易信息.

財務報表

帳務核心分帳戶來管理資金, 帳戶記錄了所屬會計科目和帳務記錄, 帳務記錄標明瞭帳戶的資金收支狀況. 按照公司的財務報表編制期間需求, 對同一類會計科目的帳戶, 分別統計該報表編制期間內收入和支出金額, 生成財務報表.

交易監控

支付系統的穩定性十分重要, 一旦因技術故障出現交易中斷, 會對整個平臺的業務形成重大影響.

監控支付渠道的交易穩定性包括

• 監控支付系統對接的外部渠道的接口響應時間和成功交易佔比這兩個重要指標

• 監控支付核心處理交易的平均時間, 保證支付系統的穩定信息

交易監控中發現的異常告警以短信郵件等方式及時通知負責人員進行處理

 

參考資料

http://www.woshipm.com/it/1371591.html 對帳中心功能, 清算對帳業務流程