支付“通用架構”與廣義“支付通道”
在日常生活中,我們都需要用到“支付”這個步驟,那么在支付系統中,支付的“通用架構”與廣義“支付通道”具體是如何呢?本文對此進行解析,一起來看看吧。
我們知道支付是付款人向收款人的資金轉移,而支付系統就是實現這一目標的處理系統。
“轉移”可以是用戶要在平臺下單購買商品向平臺支付資金,也可以是平臺要向商家結算經營款而發起了付款。
一、支付的通用架構
因為要轉移的資金存儲在外部非金融或者金融機構的結算賬戶或者支付賬戶中,因此如果想實現資金轉移的目標,就需要接入能與這類機構進行通訊的通道,通過通道發起支付指令和接收資金的處理結果。
從圖中可以看出來,支付通道要解決2個核心問題,一個是發起支付指令,另一個是接收支付結果;收款業務發起收款指令接收收款結果,通過收款通道實現;付款業務發起付款指令接收付款結果,通過付款通道實現。
以上是我們知道的常規通道,三方支付機構的收付通道,網聯銀聯的各類通道,銀行的各類通道,都是支付正規軍,標準化的支付業務。
二、支付核心架構及通道廣義化
可以看如下的支付架構圖,在通道層的常見通道位置,以此實現上述的收付業務。
圖中有一個標紅的通道種類,也就是有沒有非正規軍或者非常規的支付通道呢?
為了完成“支付業務”,能不能跳出三界之外,不拘泥于傳統,在保持上述框架的基礎上,而更加靈活多變。
這就是接下來要談的“廣義通道”,即只要能實現“廣義收付指令發起”“廣義收付結果接收”二者中的任何之一的職能,我們都稱之為“通道”。
我們舉例:
- 能查賬戶流水通過系統匹配實現支付確認,其中的“查詢流水的接口”,可以認為是一種通道;
- 可以人工導入線下憑證以確認待收付單據,其中“線下憑證的導入”,可以認為是一種通道;
- 可以人工確認支付結果、其中“確認按鈕”的結果確認,可以認為是一種通道;
- 接入賬戶系統發起余額增減并接收增減結果、可以認為“賬戶系統提供的接口”是一種支付通道;
- 接入倉儲,可以通過變更寄存商品的歸屬權,進行債權轉移以完成價值交換或者應收應付的核銷,其中的接入倉儲可以認為是一種通道;
因此,支付是資金的轉移,交易是價值的交換,而支付其實就是資金與價值的交換,因此廣義支付就是構建價值交換的通路,而廣義的通道就是價值交換通路的交換信息發起和交換最終結果的接收。
那么回到上面的支付架構圖,將紅色帶“?”地通道模塊展開。
高維支付思維架構圖
如此架構,可以將更多的支付“相關類似業務”兼容到支付系統的架構中,讓支付系統架構更具靈活性,并為支付業務的拓展提供了在架構上的指導和設計規范。
圖中的某些處理在常規情況下,我們一般不會放到通道層,比如調用內部賬戶系統的余額支付,很多時候我們會直接由支付核心去調用,而不是通道層去調用,這時,支付核心將會在主流程之外構建一個特殊的分支,就像在人的體外插了一個輸液的管子一樣,這樣做,看似沒什么,但總歸是對“整體架構的損害”。
下面通過1個例子來強化上面的5類或者更多特殊支付通道構建支付業務的思維。
三、線下匯入,模擬支付通知
有些場景用戶會直接匯款至對公戶,即線下支付,最大的弊端就是資金處理和線上的業務單據割裂。
這部分款項的核對以及領取相比全流程線上交易來說,比較繁瑣,一方面是核對困難,另一方面就是款項和業務單據對應上比較麻煩。
當線下匯入體量較大時,該部分工作成本更高;如果線下進行匯款,而需要線上履約時,這部分匹配工作如何提升效率,能否自動化實現。
而依托“廣義通道和支付架構”的引導,我們將對賬能力認為是一種支付能力,通過支付核心構建出來,因此就形成了這樣一種結構。
即業務系統請求支付核心,支付方式為“線下匯入”,支付核心創建線下匯入待支付單。
通過銀企直聯獲取銀行賬戶流水作為支付結果信息,在線下匯入支付的處理中進行結果的匹配,從而獲得線下匯入支付單的最終支付結果,并將該結果告知業務系統,業務系統收到結果后進行后續的業務處理。
那么,我們怎么將線下匯入業務融入到整個支付核心的架構中呢?如下圖:
在支付接入層增加線下匯入支付方式,業務系統可以進行調用,在支付核心創建“線下匯入支付方式的支付單”,最初的單據狀態為待支付。
線下匯入的支付處理關鍵處理是“線下匯入結果匹配”。
而通道層的“廣義特殊通道”為“查詢銀行流水”;是建設在銀行通道的“銀企直聯”之上。
專欄作家
陳天宇宙,微信公眾號:陳天宇宙,人人都是產品經理專欄作家。多平臺支付領域專欄作者,十年資深產品;專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務!
本文原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!