萬字長文,支付渠道和智能路由

0 評論 3862 瀏覽 38 收藏 35 分鐘

現在,線上支付已經十分常見,我們每天也都在用快捷支付產品輕松轉賬消費,那么,你了解背后的支付渠道嗎?這篇文章里,作者便拆解了支付渠道和渠道路由,一起來看看本文的分析和梳理。

這次給大家介紹的是支付的三個黑盒之一的“渠道和路由”(另外兩個黑盒是賬戶賬務、清結算)。

每天我們使用微信、支付寶等輕松轉賬消費,但背后的支付渠道選擇卻鮮為人知。面對眾多支付方式和資金來源,如何選最優渠道成難題,仿佛是個‘黑盒’。今天,我為你揭開這個‘黑盒’的秘密。

一、支付渠道需求

建設支付渠道的目的和主要的需求有以下幾個方面。

1. 降低成本

誰都希望用到手續費低、支付效率高的通道,但是大量的支付通道、開戶銀行、借貸記卡類型以及不同開戶銀行的費率標準,顯然需要一個能夠動態計算的路由來匹配最優的支付路徑。

2. 靈活配置

支付需求五花八門很多都需要支付渠道支持,例如有的客戶只用便宜的銀行,有的渠道要商戶進件才能使用,有的支付產品只能做借記卡,不同的渠道維護期也經常變更。這就需要有靈活的配置管理來快速調整渠道策略。

3. 快速發布

接了很多通道后,相同的通道是否能夠減少重復開發,通過簡單的配置就能快速發布上線,這樣即節省了開發資源也大大提高了渠道發布的效率。

4. 支付穩定

支付是所有商業模式的重要一環,用戶下單后付不了錢,那前面所有的商業運營活動就都白忙活了,所以要有支付穩定性的保障策略;

  1. 應急切換:當某支付渠道異常時,系統自動切換至備用通道。
  2. 負載均衡:當某渠道過載時,系統提前分散壓力至其他渠道,確保各渠道高效利用。

以上兩種方式自然需要自動完成切換,因為誰也不愿意半夜三更爬起來切換通道。

二、支付渠道方案介紹

1. 為什么要支付路由

交易平臺和商家為提升跨行支付轉化率,接入大量支付渠道,并推出聚合收銀臺、掃碼支付、刷臉支付等產品。在高效支付與復雜渠道間,渠道與路由協作成為關鍵。它們精準篩選和匹配最佳支付通道,確保跨行收付款既迅速又節省成本。

圖1:聚合收銀臺和背后復雜的渠道

2. 支付渠道的核心流程

實現上述的支付體驗,需要支付平臺與支付渠道協同自動化的完成整個支付過程,這里就包含“訂單數據串聯、渠道服務調度、支付路由篩選、資金渠道管理、渠道接口適配、支付結果回調”等六個過程。

圖2:渠道路由的核心流程

1)訂單數據串聯

從整個場景來看,從用戶下單到最終完成支付的鏈路是比較長的,因此為了保障數據全流程的連接,將支付訂單分為了“交易訂單”和“渠道訂單”兩部分。

  1. 交易訂單:用來記錄用戶的交易過程的信息。
  2. 渠道訂單:專注對開戶銀行的支付處理過程。

兩個訂單前后串聯,分工明確,記錄的信息也更加清晰和完整

2)渠道服務調度

支付系統接收支付請求后,將交易訂單轉為渠道訂單并發送給渠道服務。渠道服務會像指揮官一樣根據請求調度內部模塊,如綁卡、支付、退款、查詢等,確保高效完成支付處理。

3)支付路由篩選

接收支付請求后首先就是要找條最優的通道來進行支付,這里就需要進行支付路由。路由一般分為自動路由和手工路由兩種模式;

  1. 自動路由:就是根據預先配置好的規則動態的計算最優路徑。這種比較適合渠道比較多的持牌機構。
  2. 手工路由:這種又叫靜態路由,就是提前給商戶分配好支付通道直接完成支付,當然切換就需要人工接入。一般企業、服務商和非持牌機構較多采用這種方式。

本文介紹是復雜度比較高的自動路由。

4)資金渠道管理

支付路由篩選的“資金渠道”早期通過簡單篩選如開戶行、卡類型等即可選定。但隨著多銀行、多機構、多級價格、渠道商戶進件等復雜因素出現,資金渠道管理變得復雜難管。為解決此問題,需要在資金渠道的基礎上,采用搭積木的方式來實現渠道特性的擴展和路由篩選(詳細內容我們設計部分來介紹)

5)渠道接口適配

篩選到資金渠道后,需調用銀行接口完成支付。此過程涉及“接口轉換、文件處理、加解密和網絡安全”等個性化處理。為實現標準化,需進行“標準接口定義”和“渠道個性適配”兩項工作:

① 標準接口定義:

定義了不同支付產品的標準交互接口,消除渠道間的差異,使支付系統能按統一規范訪問各渠道,減少因新增渠道而頻繁修改重復開發。

② 渠道個性適配:

需人工開發,針對各銀行的接口和安全機制,轉換為渠道可識別的標準接口和字段信息,以平衡個性化需求和人力投入的矛盾。

6)結果回調通知

支付交易需實時性,渠道處理量大時可能延遲。為保障及時準確,采用回調機制:渠道處理完交易后主動通知支付系統結果。若無回調,可開發定時查詢功能并回調支付系統。支付結果展示給用戶,并通過短信等通知,確保用戶了解狀態。此流程閉環,提供便捷高效支付體驗。

回調和異步通訊:

回調是以一種異步通訊的實現手段,簡單來說他就像微信聊天一樣,你給對方發送消息,對方并不需要立刻回答你。等他忙完了之后再把處理結果告訴你。

3. 支付方式和特性

支付系統要支持的支付產品基本涵蓋了主流“入款、出款、鑒權”的主流線上化支付方式。其中族系比較龐大的是“入款”類支付產品,其特性也是紛繁復雜。參見下圖。

圖3:支持的支付產品和渠道特性

這么多產品功能要集成到一起,如果能夠快速的篩選和找到呢?這就要用到渠道路由了。

三、渠道路由方案

支付路由就是將渠道特性拆解后制定一套規則,從而實現靈活的路由。因此,講路由之前我們先從分析渠道有哪些特征信息開始。

1. 渠道特征拆解

圖4:支付渠道的特征信息

特性分析:

從上圖拆解出來的支付渠道特性種類非常多,這么多特性怎么去管理它并且做到自動路由是一個非常大的挑戰。因此我們把它們拆分為了三級特性;

  • 一級:基礎特性– 所有渠道的必備通用特性,通過可視化配置固定,確保基礎準確和穩定。
  • 二級:擴展特性– 因渠道和商戶差異產生的個性化特性,采用定制程序和腳本處理,滿足變化需求。
  • 三級:技術特性– 篩選最佳支付通道,保障高效穩定運行,通過網關策略或定制開發實現。

2. 路由篩選原理

圖5:渠道路由原理

1)路由因子分類

① 基礎因子:

一次支付路由是由一筆支付訂單驅動的,當支付訂單按照渠道標準轉化為“渠道訂單”后,支付渠道會從訂單中解析出路由的基礎因子,這些路由因子都是基礎的渠道信息。

② 擴展因子:

擴展因子是渠道一些復雜的特性或者是后期不斷新增的渠道特性,由于需要特殊的處理因此對其二次篩選。這里包含維護期、交易限額、黑白名單等比較大的特性;也包括補充鑒權、退款限額、到賬時效等小特性。

③ 質量因子:

就是能夠給用戶提供一條最高效的支付渠道。這類路由因子一般也是通過網關策略或者定制開發的方式實現的

2)多級渠道路由

渠道采用多級路由方式,我們這邊介紹的是最典型的三級路由模式。

  • 一級路由:基于“支付方式、成本等”進行初步篩選和排序。
  • 二級路由:考慮“維護、限額等”擴展特性,進一步篩選。
  • 三級路由:評估“延遲、鏈接質量”等指標,選最優渠道。

以上一個標準的渠道三級路由,當然如果你的渠道特性非常豐富,可以擴展更多的路由因子和處理規則來實現多級擴展。

3)選中渠道執行

找到一條最終的支付渠道后,就需要獲取這條渠道對應的“渠道接口”,進行渠道報文的組裝后完成支付。

3. 路由因子參數說明

圖6:路由因子和實現方式介紹

上圖就是對路由因子有哪些參數和參數結構進行的說明,可以看到既有枚舉值,也有復雜的結構化數據。對于固定的枚舉值可以通過可視化的配置方式來實現。而對于結構化的數據(例如限額、維護期、成本等)這類不適合規則配置的內容采用了定制程序或者路由腳本的方式來實現。

四、渠道設計方案

基于“渠道方案”和“路由方案”,下面我們來看下整個渠道和路由系統如何來實現。

1. 渠道業務架構

圖7:渠道業務架構

從業務架構圖我們可以看到渠道系統分成了三層的結構。

① 資金渠道管理:

這是渠道模塊的核心系統,他放在了支付系統的內網,與外網隔離保證其可以安全的使用而不被攻擊;其內部又分為了“渠道服務、路由管理、資金渠道、定時任務、基礎服務”五個重要的渠道核心功能。

② 資金渠道網關:

這部分是渠道外部的適配器,用來對接各家銀行的支付渠道,他分為了“渠道接口、渠道適配”,新增一條支付渠道就要在這里進行配置和開發。

通過資金渠道網關,屏蔽不同渠道的差異,給上層渠道服務提供統一的訪問處理。這類部分模塊是安放在網絡隔離區,通過防火墻完成內外部網絡的訪問。

③ 外部支付渠道:

這里就是需要通過對接和訪問的銀行、三方、清算機構的支付通道了。

1)資金渠道管理

圖8:資金渠道管理

① 渠道服務:

這是渠道對外提供的標準服務,上層支付平臺要按照標準接口來訪問渠道,同時渠道服務也是下游流程的調度者。這里的渠道服務支持“鑒權、預路由、入款、收款”等支付核心功能。

② 路由管理:

渠道路由會接收支付服務的請求,將支付請求的“訂單信息”解析成“路由因子”,按照對應的規則模版進行多級路由,最終選中一條資金渠道進行調用。

③ 資金渠道:

這里存放著接入的每條渠道的所有配置信息,渠道相關的重要信息都存放再此。路由結果也是通過調用這里的渠道接口完成最終的支付。

④ 定時任務:

這是資金渠道的一個輔助功能,對于需要定時進行的支付結果查詢,對賬文件、批量任務等進行處理。

⑤ 基礎服務:

這里是資金渠道業務層面的一個附屬功能,包含基礎參數、卡Bin、簽約信息、結果碼、安全證書、緩存等管理。

2)資金渠道網關

圖9:資金渠道網關

資金渠道網關既是對外訪問的模塊,新接入渠道二次開發模塊也是部署在這里。

  1. 渠道接口:定義標準的渠道訪問接口,他屏蔽了不同渠道差異性,讓上層的渠道管理可以用統一的方式來管理渠道。
  2. 渠道適配:就是對不同銀行的渠道進行接口轉換、安全加密處理、網絡處理等各種渠道差異性進行二次開發。因此新增一條通道,只要在這里做渠道的接入開發就可以了。
  3. 回調網關:用來處理銀行的支付結果的回調請求。

2. 渠道用例模型

下面我們看下這些功能是如何協同起來工作完成“渠道管理、支付路由、渠道調用”等支付處理。

圖10:渠道用例模型

1)渠道服務

渠道服務提供統一的服務接口,并根據業務類型細分為七大類功能,每類功能均可擴展。在入款功能中,按支付方式細分為快捷、網銀、條碼三類。這些服務既支持單筆和批量接口處理,也支持文件接口處理。

對于復雜的快捷支付,渠道服務提供簽約記錄和卡Bin管理兩個附屬應用,用于在快捷簽約時進行銀行卡驗證和補充鑒權操作。

渠道服務的核心職責是將“支付訂單”轉化為“渠道訂單”,實現內部數據流轉。這涉及將標準化信息傳遞給下游的路由和渠道模塊,以便進行解析和完成支付處理。通過這種機制,渠道服務確保了支付流程的高效、安全和順暢。

2)渠道路由

① 路由訪問:

  • 動態訪問:一種是提供路由因子由路由系統動態路由一條支付渠道完成支付。
  • 直接訪問:對于像快捷支付需要訪問簽約通道的支付產品,可以直接傳送簽約的“資金渠道編號”訪問對應的簽約渠道。如果由多條簽約渠道則按照“成本和Qos”找到一條最便宜、最快的通道完成支付。

② 路由處理:

圖11:路由規則工作原理

渠道路由通常利用規則引擎進行處理,這種處理方式允許我們提前編寫好規則腳本。當輸入相關數據后,規則計算引擎會根據這些腳本進行計算,并輸出一個結果。

這個結果可以是一個簡單的數值,比如一個特定的資金渠道編號,也可以是一個更復雜的數據對象,包含多個資金渠道編號以及對應的渠道接口信息。

這種機制使得渠道路由處理非常靈活,計算結果可直接調用支付渠道或作為二級路由輸入,持續篩選直至選定合適渠道。未選中則報錯。

3)渠道管理

渠道管理包含接入渠道的所有信息,其最核心的就是“資金渠道”的管理,它擁有我們一級路由所需要的主要基礎信息,而一些像“維護期、交易限額、擴展因子”等信息則根據業務的增長和需要進行靈活的擴展。

由此我們也可以知道為什么要做三級路由了,因為一級路由我們篩選的就是渠道表層的基礎信息,二級路由是篩選渠道的擴展的信息,三級路由是篩選動態的渠道交易信息。

4)渠道網關

經過渠道路由選擇資金渠道后,接下來需要調用該渠道的接口。渠道接口調用分為標準化的“渠道接口”和需要個性化開發的“接口適配”兩部分。對于新增的渠道,通過接口適配實現與系統的對接,確保順暢的支付流程。

這種機制既保證了接口的標準化和通用性,又兼顧了不同渠道的個性化需求,提升了支付系統的靈活性和可擴展性。

渠道網關還有個回調服務,前面已經介紹過來,我們這里就不再贅述了。

3. 渠道數據模型

渠道的數據模型幾乎是和用例模型直接映射的,因此下面我們就從處理流程的角度來說下數據之間的關系。

圖12:渠道ER模型

1)渠道管理

① 渠道配置

創建資金渠道:

新接入的支付渠道需要配置相應的“資金渠道”,這包括渠道的基礎特性信息,確保渠道能正確識別和處理支付請求。

關聯目標機構:

資金渠道創建后,需要與目標機構進行關聯。目標機構代表了一組特定的開戶銀行信息,與支付產品相對應,確保支付流程中的銀行信息準確無誤。

關聯擴展信息:

在基礎信息和目標機構關聯完成后,還需為渠道關聯包括“支付限額、維護期、結算信息、黑白名單”等在內的擴展信息,以滿足不同支付場景和運營需求。

② 渠道接口配置

完成上述渠道配置后,需要為渠道配置相應的接口。這些接口用于與支付渠道進行交互,包括請求發送、結果接收等,確保信息的準確傳輸和處理。

③ 渠道路由配置

只有渠道配置還不能立即使用,還要把渠道對應的路由規則按照模版配置出來,然后把這些路由規則發布。這樣這條渠道就可以使用了。

當然,這里的規則模版是為了方便配置按照不同的支付方式提供的標準化模版,這些模版既可以是一個腳本也可以是一套可視化的配置界面,這樣發布渠道就比較靈活。

2)聯機交易

渠道配置發布后,聯機交易就可以調用渠道了。

  1. 請求處理:首先上層支付系統會按照接口標準向渠道服務傳送“渠道支付訂單”信息。
  2. 渠道路由:支付路由系統把渠道訂單數據解析成“路由因子”,然后按照路由規則篩選渠道。
  3. 調用渠道:當選中一條渠道后,就調用對應的資金渠道和接口,通過渠道適配器完成接口轉換完整一筆聯機交易的處理。

3)運營管理

渠道配置完成后,商戶側運營還需要配置商戶產品和行業信息(MCC),包括微信、支付寶等支付產品,還需配置渠道行業及進件信息。

這樣商戶就能順暢的使用支付產品和新發布的渠道了。

五、資金渠道交互設計

前面講了設計,那整個支付渠道到底長什么樣子的呢?下面我們就來介紹下渠道的交互部分設計。由于支付產品的類型非常多,我們以相對復雜的快捷支付為例來介紹整體交互流程。

1. 整體交互流程

圖13:渠道交互整體流程

整個渠道交互都是圍繞著“資金渠道管理”來展開的,他整個處理流程與用例圖、ER模型基本是一致的。

1)資金渠道管理:

以資金渠道為核心頁面,完成基礎信息配置后,對擴展的關聯信息進行配置,最后完成接口配置。

2)支付路由管理:

支付路由管理通過一套可視化的配置模版的界面,可以輕松的配置各類路由規則。這些路由配置界面可以按照業務類型的不同分為不同的模版,例如“快捷路由配置”、“掃碼路由配置”、“付款路由配置”等。

2. 渠道功能清單

針對渠道比較豐富的持牌機構,需要支持的主要功能有如下。

  1. 基礎參數:提前需要配置好存放在系統內的基礎信息。
  2. 資金渠道:渠道管理和路由所需要的功能。
  3. 渠道運營:提供給商戶側運營使用與渠道相關的功能。

圖14:渠道功能清單

3. 新增資金渠道

新接入支付渠道需要對應配置一條資金渠道信息,配置資金渠道還需要同步去關聯“目標機構、維護期、渠道限額、黑白名單、渠道接口”等渠道擴展信息。

圖15:資金渠道管理

1)填寫資金渠道信息

創建資金渠道同時需要填寫渠道的基礎信息和常用的渠道特性和結算信息,這些基礎信息可以包含最常用的渠道路由信息。

圖16:資金渠道基礎信息

2)新建目標機構

創建資金通道后還要創建對應的目標機構,把當前渠道支持的開戶銀行關聯到渠道上。這樣在支付路由的時候就能獲取當前渠道支持的銀行。

圖17:創建目標機構

3)資金渠道接口

資金渠道與目標機構創建后,需配置對應渠道接口,以便路由選中時完成跨行支付。接口采用標準化模板,并提供參數配置以適應不同渠道。復雜渠道可通過個性化開發的“接口適配”服務處理支付。標準化接口減少了定制工作量,加快了渠道發布速度。

圖18:渠道接口維護

完成資金渠道和目標機構的創建后一條最基本的資金渠道就配置完成了,但是這些信息還不能滿足快捷支付產品復雜的特性需求,因此還要做擴展渠道特性的配置。

4)渠道限額

快捷產品的限額比較復雜,不同銀行按照卡類型設置了不同的單筆、日限額和支付成本,因此這部分需要單獨來進行配置和管理。

圖19:渠道限額和成本

5)渠道維護期

每條渠道對應的渠道和開戶銀行也非常多,因此不同渠道、不同銀行經常會有維護期需要進行設置(主要是快捷、網銀、付款類產品),這部分信息由于更新頻繁需要經常維護,因此也需要單獨管理。

圖20:渠道維護期設置

6)商戶黑白名單

黑白名單屬于擴展特性,只有渠道需要對指定商戶進行準入或者限制時才需要配置。

① 白名單:

即只有名單內的商戶才能使用;現在支付渠道開始要求商戶進行渠道進件,例如條碼支付、商戶側全渠道、商業委托扣款、新代收等產品。所以需要再渠道上設置對應的白名單,只有白名單的商戶才使用這些渠道。

② 黑名單:

即名單內的商戶不能使用渠道或者部分特性。黑名單使用的原因有很多,最常見的就是渠道價格調整后,有些商戶手續費和渠道成本倒掛了,因此需要限制這些商戶使用指定銀行的銀行卡產品。如果商戶支持銀行和卡選擇ALL,這說明這個商戶這條渠道不允許使用。

圖21:渠道黑白名單維護

4. 設置渠道路由

1)渠道路由管理

一套路由規則通過基礎參數、擴展參數可以關聯多個渠道,每條路由規則也要支持,創建、修改等一系列的管理功能。

路由規則不建議做物理刪除,因為直接刪除會影響渠道的穩定切換??梢酝ㄟ^新增一條規則設置新老規則的銜接時間來實現穩定的切換。

圖22:渠道路由管理

為了表現規則和渠道的兩級結構關系,交互中采用了樹形查詢列表,當然條件不具備的小伙伴可以使用普通列表查詢也可以,就是交互體驗上要考慮怎么展示規則和渠道的關系,以及規則如何修改和編輯。

2)路由規則設置

路由規則的創建是由“基礎信息、規則組、路由規則、執行渠道”嵌套實現的,沒錯又是燒腦的“嵌套”。因為這樣可以把同類型的渠道分別進行設置。

需要說明的是并不是所有規則都能可視化配置的。路由規則配置主要處理的是一級路由中固定取值的“基礎因子”的配置,動態計算的擴展因子和質量因子的處理需要定制化開發。

當然也可以提供腳本編寫功能給配置人員使用,不過這需要有編程經驗才行。

圖23:快捷路由規則設置

① 基礎信息:

是整個路由規則的基礎信息,包含這條規則什么時候生效和創建內部嵌套的規則組。

② 路由分組:

為什么要對路由規則分組呢?目的是把同類支付產品,按照不同特性區分出來。例如同樣是快捷支付產品,有的產品只要綁卡簽約就能使用,有的產品需要商戶渠道進件才能使用,有的產品小金額支付可以優惠。

這么多特性顯然需要不同的路由規則來描述,因此需要設置不同的分組。

③ 路由規則:

  • 基礎因子:這類規則都有固定的枚舉值,因此基礎規則可以用可視化的方式來設置對應的條件,多條規則通過后置邏輯關系來實現鏈接。
  • 擴展因子:“維護期、渠道限額、渠道質量”等擴展特性并非固定取值,需根據實際訂單與渠道配置信息動態計算。因此,需開發定制化程序以處理,無需在單條渠道上分別設定路由規則。
  • 臨時新增:如果有些臨時新增的規則可以通過編寫嵌入腳本來快速實現。

④ 執行渠道:

最后要把規則對應執行渠道配置上去,這樣規則才能正常工作。需要說明的是同一套規則會有一條或者多條渠道被選中,因此需要支持多條渠道和接口的設置。

可能你會問,多條渠道該用那條呢,其實路由配置就是一級路由的處理,最終命中渠道還有技術層面內部處理來決定的。

3)路由的多組規則

一條路由規則可以設置多組子路由規則,如下圖所示,通用的快捷支付規則包含了“協議支付、無卡支付、銀聯商戶側、云閃付免密”等所有的快捷類支付方式,可以通過分組的方式來實現。

圖24:快捷支付的多組規則

例如圖中的規則組1,他是為協議支付、無卡支付這樣的通用性支付渠道進行設置的規則。銀聯商戶側由于需要渠道側進件才能使用因此要單獨設置一個規則組。云閃付免密支付由于1000元以下有優惠,因此也為其提供了一個規則組。

六、支付渠道總結

本文介紹的支付渠道設計還是比較復雜和龐大的,這種模式比較實用持牌機構,非持牌機構可以按照這套模式做適當的裁剪。

本文主要基于快捷支付產品場景來介紹的,條碼支付、網銀支付、付款產品也都是適用的,本文限于篇幅不再展開介紹了,同學可以自行按照這套模式來進行擴展。

????作者:剛哥,公眾號:剛哥白話

本文由 @剛哥 原創發布于人人都是產品經理,未經授權,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!