全栈工程师?
嗯.....目前并不是!

支付系統設計白皮書:支付核心的 7 個要點

本文跟大家探討一下支付核心的七個要點,一起來看看~

一、支付前置

着業務定製化對交易支付需求複雜度的增加,交易系統保證系統穩定的同時,亦需靈活性以支持業務。但系統設計時,靈活和穩定是矛盾的,穩定意味着剝離變化,靈活意味着可配置化。

支付前置的職責即:解決支持業務變化的擴展性,將交易通過支付前置的配置轉化為後端支付系統能統一處理的模式,方便後端多樣化的記賬需求。

支付前置的定義

  • 支付前置包裝後端支付核心繫統的接口,包裝后對外提供的服務包括餘額、 現金、網銀、快捷支付、出款及相關訂單的退款和控制接口;另提供後台系統調用的服務包括確定性入款、登賬、凍結解凍、退票等,所有的支付行為都會以業務支付訂單的形式落地;
  • 用戶在前端發起一次支付行為後,交易系統基於原始的交易訂單,對應生成一條付款訂單,通過這筆付款訂單和支付核心進行交互。

業務產品碼:

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

支付產品碼:

由於即時到賬、擔保交易在業務規則上不同,但支付渠道側判斷均為支付,因此支付產品碼相同,但業務產品碼不同。這裡的支付產品編碼配置來自於支付協議的配置,一個支付產品編碼代表着一個支付協議。

二、支付協議

支付協議即對支付模式、支付服務的封裝。

以收單支付為例,某個業務方在支付系統開設支付權限后,可理解為與支付系統本身簽署了收單支付協議,即可通過交易系統對外輸出擔保交易產品、即時到賬產品來使用收單支付的能力。

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

提現協議:

  1. 以秋秋老師的提現協議為例,提現的明細項關聯着業務方所傳遞的外部訂單號,代表着這次業務支付行為的原始訂單請求,對應着收付款人的信息;
  2. 調用支付服務層的時,會有客戶權限校驗等判斷,通過的情況下此時去調用支付協議的配置信息落地一筆支付訂單,並基於該訂單生成對應的一筆或者多筆支付指令,接下來由指令去執行調用下游系統的具體方式,若是調用清算通道則生成清算類的操作指令(調用通道,調用時間,通道需要的信息等),可稱為外部指令,若是要操作賬戶金額則生成賬務類的操作指令(具體賬戶、金額、借記還是貸記),可稱為內部指令。

三、支付引擎

1. 支付引擎的類型

定義支付的原子級支付形態,所有的支付行為都是賬戶資金的流轉,可梳理出以下幾個支付類型:

  • 充值:資金從外部資金源向內部資金源轉移的支付動作;
  • 提現:資金從內部向外部資金源轉移的支付動作;
  • 內轉支付(轉賬):資金在內部賬戶轉移的支付動作,這裡的定義和產品中定義的轉賬概念不同;
  • 退款:充值的反向操作。

2. 指令

指令即支付核心的工單號,前置的每筆支付訂單對應着一筆甚至多筆指令。指令里包含了這筆支付訂單是原始支付類型(充值、提現、轉賬、退款,指令一定是基於原始支付類型來生成的,任何支付行為都能被原子類型所支持),對應着的業務請求類型、支付方式、支付產品編碼、參與方信息(交易中收付款人的信息)、相關聯的支付指令信息(退款時用於關聯原支付指令)、支付服務流程等相關信息;由支付指令去調用支付服務流程時,再根據流程編排環節去確定何時生成賬務類操作指令和清算類操作指令。

舉例:用戶在電商網站購買一本書價格 100 元,通過支付寶付款,交易類型為擔保交易,在交易核心生成一筆擔保支付的訂單,調用支付核心繫統時支付系統判斷該業務調用方對應已經配置了「收單支付協議」,且根據對應協議生成一筆業務類型為第三方支付的支付訂單,基於此訂單生成了第一條充值的支付指令。

該指令在根據支付類型去調用服務流程時,先通過流程編排生成清算指令並調用(這裡值得注意的是,先生成清算指令的原因在於需要先調用外部支付渠道,把錢收進來),用戶付款成功后再生成賬務指令並調用賬務核心,執行內部賬務入賬。

3. 服務流程

定義支付指令的執行流程,將支付拆分成原子級支付類型,並對支付類型的流程進行編排,任何一個交易的請求,都能被上述四種基礎支付類型組合進而完成支付行為。

例如:一筆擔保收單的交易,用戶用支付寶等第三方支付完成了這筆交易,並在 7 天後確認收貨,平台側 7 天後根據用戶的行為應該將該筆貨款打給了商戶。

這裡我們將用戶的行為分為支付確認收貨兩個動作,對應着在交易側這也是兩次請求,一次支付,一次結算:

  • 在支付層對應收單支付協議;
  • 在前置系統被拆分成了兩筆業務支付訂單,一筆是快捷支付(業務類型,類型自定義,可以叫第三方支付),一筆是餘額轉賬(將資金從擔保賬戶結算到商家賬戶);

而後分別生成兩條支付指令(充值和轉賬),充值代表着用戶的支行為,轉賬代表着用戶的確認收貨行為,因為從但保護結算到商家賬戶,可以定義為這是一筆賬戶之間的資金扭轉。

四、風控

風控是風險交易防範與控制的簡稱。支付系統設計中,提升自身的風控意識,在必要時為交易增加風控模塊,可以有效減少風險交易造成的資金損失。支付核心的風控模塊,一般位於交易處理的最前端,每筆交易通過風控模塊的檢驗后,才允許支付核心進行後續的交易處理。

是否設置風控模塊,需要評價投入產出比。當支付系統內積累了一定量風險交易數據,並且已經產生實際經濟損失的情況下,則需考慮在支付系統內設置風控模塊。

1. 業務規則

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

餘額賬戶:

用戶使用餘額賬戶進行首次充值時,必須通過賬戶信息的實名認證。由於用戶在銀行辦理銀行卡時,銀行一定會對持卡人的身份進行實名認證,所以對平台餘額賬戶使用者可以通過利用銀行或支付機構提供的銀行卡信息驗證接口,對用戶進行實名認證。

  • 進行實名認證時,需要驗證姓名、身份證號、銀行卡號、手機號;完成實名認證后,用戶必須設置支付密碼,後續自消費和提現時,就可以使用支付密碼保證餘額資金的安全。
  • 用戶更換餘額賬戶提現銀行卡時,必須對已綁定的銀行卡進行進行校驗,要求用戶輸入已綁定銀行的完整賬號和綁定手機號;同時新綁定的提現銀行卡,也必須和賬戶已驗證的身份信息一致。

以上措施,可有效防止用戶個人信息泄漏造成的餘額賬戶資金損失。

2. 風控模型

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

  1. 交易信息:該筆交易自身的信息要素,例如交易類型、交易金額、交易時間、支付賬號等信息;
  2. 客戶信息:發起該筆交易的平台用戶信息,包括用戶使用的設備類型、設備編號、用戶定位信息、用戶手機號、手機號歸屬地等;
  3. 歷史數據:用戶在平台發生過歷史交易,其歷史交易的交易信息和用戶信息。

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

3. 風控運營

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

  • 對於明確一定屬於風險交易的交易請求,採用事前攔截的處理機制,支付核心收到后,由風控模塊直接拒絕交易。
  • 對於無法確認是否屬於風險交易的,進入風控模塊的待審核交易列表,由風控專員對可疑交易進行人工審核。審核后認為是風險交易的,則拒絕交易;審核后不屬於風險交易的,由支付核心繼續後續的交易處理。

五、內部控台

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

1. 交易操作

  • 業務運營人員,需要對支付系統中已經發生的交易進行檢索,確認某一具體交易的交易狀態;
  • 對於某一筆具體交易,進行退款操作;
  • 內部控台要為業務運營人員提供交易操作入口。

2. 交易數據展示

管理層希望了解整個平台的業務運作情況,支付系統通過內部控台提供交易總額、訂單轉化率、支付渠道佔比等可視化的數據圖表,直觀展示交易數據的變化情況。

3. 報表下載

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

4. 權限控制

支付系統的交易數據屬於敏感信息。首先,內部控台要限制僅可以通過公司內網訪問,並控制可以查看數據的人員數量,具有數據查看權限的人員,需要對數據安全和資金安全負責;其次,和用戶有關的卡號、姓名等信息,要做脫敏顯示,預防泄露用戶信息。

六、報表

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

1. 交易報表

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

支付交易、充值交易、出款交易,在交易數據信息上各不相同,需要分別出具獨立的交易報表;一般按照日、周、月為時間維度,固定出具交易報表;交易報表中除了提供交易流水明細,還需要提供該時間周期內的匯總數據,方便使用者快速了解這個時間段內的交易情況。

交易報表的結構關係為:

2. 結算報表

支付系統的清算核心對賬戶中資金進行結算時,生成結算報表,供運營或財務進行付款前的確認或者作為付款憑證作為後續查賬、審核的依據。結算報表的屬於來自於清算核心提供的結算數據,面向內部人員使用的結算報表可以根據本系統的業務需求,增加其他信息字段,更好的了解結算交易信息。

3. 財務報表

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

七、交易監控

支付系統的穩定性十分重要,一旦因為故障出現交易中斷,會對整個平台的收入造成重大影響。

  • 監控支付渠道的交易穩定性:支付系統對接的外部渠道,監控支付渠道的接口響應時間成功交易佔比這兩個重要指標,來監控支付渠道的穩定性。
  • 監控支付核心處理交易的穩定性:主要監控支付核心處理交易的平均時間,保證支付系統的穩定信息。

交易監控中發現的異常告警,以短信、郵件等方式及時通知負責人員處理交易異常信息,儘早恢復交易。

 

《支付系統設計白皮書》由 PingPlusPlus支付學院(ID:pingxxpi)出品。

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《支付系統設計白皮書:支付核心的 7 個要點》
文章链接:https://www.pmbear.com/%e6%94%af%e4%bb%98%e7%b3%bb%e7%b5%b1%e8%a8%ad%e8%a8%88%e7%99%bd%e7%9a%ae%e6%9b%b8%ef%bc%9a%e6%94%af%e4%bb%98%e6%a0%b8%e5%bf%83%e7%9a%84-7-%e5%80%8b%e8%a6%81%e9%bb%9e/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们