支付業務說到底是個渠道業務，他是支付系統的接出端，對於一家支付公司來說，只有接入有市場競爭力的支付渠道，支付產品才能被更多的客戶使用。對於每個剛入支付行業的同學來說，很多都是從接渠道和配置路由開始的。

今天，我們就來介紹支付渠道和被傳的神乎其神的渠道路由。

引子：神祕的渠道路由

支付渠道是支付平臺鏈接銀行、三方等持牌機構的系統。其中最神祕的就是渠道路由，由於它是持牌機構內部的系統，因此接觸者寥寥，並且其內部結構錯綜複雜，加之 “智能化” 的宣傳使其更加神祕。

其實只要記住 “三級路由” 基本原理，把流程和模型做個上圖這樣的二維展開，任何人都能拿捏渠道對接和路由。

01、支付渠道原理

支付路由就是將渠道的路由因子組合形成一組規則，將用戶的支付請求準確的傳送到支付渠道上完成支付。因此，講路由之前我們先要了解路由因子和三級路由。

所謂的三級路由，就是把路由拆解成三個階段，各階段分工合作，最終命中一條可用的支付渠道。

1.1、路由因子

圖 1：渠道結構和路由因子

路由因子和渠道的結構密不可分，因此在瞭解路由因子前，我們先要分析下支付渠道的結構。

1.1.1、渠道結構

渠道的結構分爲 “資金渠道” 和“渠道網關”

1）資金渠道：每條資金渠道代表着一條可使用的外部支付產品。在資金渠道中設置了 “基礎信息” 和“渠道特性”參數，這些參數控制着渠道的路由和參數轉換。

2）渠道網關：負責與外部支付產品的接口適配和參數轉換，以此來屏蔽內外部接口的差異，以便支付引擎能夠按統一的流程和參數來調用。

1.1.2、路由因子

1）基礎因子：對應着渠道的基本信息，通過對支付訂單的拆解可以初步匹配到符合要求的渠道。因此基礎因子大都是支付訂單中包含的信息。

2）特性因子：對應每條渠道特殊的屬性，例如維護期、交易限額、渠道成本等需要後臺單獨配置的規則來處理，這些因子需要按請求參數進行邏輯計算。

3）質量因子：對應的是渠道網關，發起支付時要選可靠渠道，因此需要動態監控渠道的成功率、延遲率和連接數等參數，以確保支付請求被快速處理，減少訂單積壓。

1.2、三級路由

圖 2：三級路由

分析完路由因子後，我們來看下三級路由是如何流轉的。

1）一級路由：篩選渠道

解析支付訂單根據基礎因子篩選出符合條件的支付渠道，把結果存入一級列表。

2）二級路由：匹配特性：

一級列表中的渠道不能直接支付，因爲如果渠道處於維護期或限額較低等特殊情況，支付請求會失敗。需要根據每條渠道的特性匹配合適的渠道，再將結果存入二級列表。

3）三級路由：檢查網關

二級列表的渠道具備了直接支付的條件，但是爲了減少異常訂單的堆積，還需要對渠道網關運行情況進行篩選，找到質量最好的那條通道完成支付。

經過以上三級的篩選，就找到了一條又快又省錢的渠道，選中這條渠道完成支付即可。

02、支付渠道設計

瞭解了以上這些原理之後，我們再來看支付渠道的設計就很好理解了。

2.1、渠道業務架構

圖 3：渠道業務架構

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

1）資金渠道管理：

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

2）資金渠道網關：

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

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

3）外部合作渠道：

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

2.1.1. 資金渠道管理

圖 4：資金渠道管理

1）渠道服務：

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

2）路由管理：

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

3）資金渠道：

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

4）定時任務：

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

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

2.1.2. 資金渠道網關

圖 5：資金渠道網關

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

1）渠道接口：定義標準的渠道訪問接口，它屏蔽了不同渠道差異性，讓上層的渠道管理可以用統一的方式來管理渠道。

2）渠道適配：就是對不同銀行的渠道進行接口轉換、安全加密處理、網絡處理等各種渠道差異性進行二次開發。因此新增一條通道，只要在這裏做渠道的接入開發就可以了。

3）回調網關：用來處理銀行的支付結果的回調請求。

2.2、渠道集成關係

圖 6：渠道集成關係

2.2.1、渠道服務：

渠道服務提供統一的服務接口，並根據業務類型細分爲七大類標準功能，這些功能可以組合成快捷、掃碼、網銀、錢包等各種支付產品的標準接口。

通過定義標準化的服務接口，可以有效地抽象和屏蔽各渠道間的差異性。這樣一來，支付引擎就能夠以統一的方式進行調用，而無需關注每個具體渠道的特性與差異。

2.2.2、渠道路由：

渠道路由就是對支付請求進行解析，然後進行路由的篩選和計算。這裏就包含了路由訪問、訂單解析、路由計算三個步驟。

1、路由訪問：

支付請求有動態路由和直接訪問兩種方式。

1）動態訪問：顧名思義讓渠道根據請求去自動的計算，找到一條最快最便宜的渠道完成支付。

2）直接訪問：有些支付產品是與渠道綁定的，例如快捷支付的協議號只能在簽約的通道上有用，因此可以直接傳送簽約時對於的 “渠道編號” 直接訪問，而無需路由。

2、訂單解析

對支付訂單進行解析，從訂單中抽取出路由因子進行逐級的篩選。

3、路由執行：

圖 7 ：路由規則工作原理

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

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

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

2.2.3、渠道管理：

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

2.2.4、渠道網關：

渠道網關負責不同的渠道接口適配，並且完成向外部渠道發送支付請求，最終將結果以回調的方式返回給上層支付系統。因此實際渠道對接主要是在渠道網關進行二次開發，以實現不同渠道的適配和安全加解密處理

同時渠道網關也兼具渠道質量監控的功能，可以異常渠道進行降級、限流和熔斷，以減少異常訂單的堆積。

2.3、渠道流程串聯

圖 8：三級路由的流程串聯

分析完渠道設計後，下面我們就把流程、參數和模型進行串聯，以此來了解其上下游的對應關係。

①解析支付訂單：

解析出支付訂單中的路由因子，準備路由。

②判斷路由模式：

需要判斷動態路由還是直接路由，如果是動態路由就通過路由因子進行篩選渠道。如果是直接路由，則取出渠道號存入二級路由的結果列表，直接進行第三級路由。

③一級渠道匹配：

根據基礎因子篩選出共同特性符合條件的支付渠道，把結果存入一級列表。

④二級特性匹配：

前面已經介紹，一級列表中的渠道還不能直接支付。因此需要對一級列表中支付渠道的特性進行逐條遍歷和計算，找到完全符合條件的支付渠道後才能存入二級列表。進入二級列表的渠道基本滿足了支付的條件。

⑤三級網關檢查：

爲了減少超時等情況造成的訂單堆積，還要對支付網關服務質量因子（QoS）進行一次檢查，路由到成功率最高，速度最快的渠道上去。

⑥組裝接口完成支付

以上路由都成功後根據選中的渠道組裝接口，進行數據轉換後就能完成支付了。

03、支付渠道交互

前面講了基本原理和設計，那整個支付渠道到底長什麼樣子的呢？下面我們就來介紹下渠道的交互部分設計。由於支付產品的類型非常多，我們以相對複雜的快捷支付爲例來介紹整體交互流程。

3.1、整體交互流程

圖 8：渠道交互整體流程

整個渠道交互都是圍繞着 “資金渠道管理” 來展開的，因此他整個交互界面就是模型的可視化展現。

1）資金渠道管理：

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

2）支付路由管理：

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

3.2、渠道功能清單

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

1）基礎參數：提前需要配置好存放在系統內的基礎信息。

2）資金渠道：渠道管理和路由所需要的功能。

3）渠道運營：提供給商戶側運營使用與渠道相關的功能。

圖 9：渠道功能清單

3.3 新增資金渠道

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

圖 10：資金渠道管理

3.3.1、新增資金渠道

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

圖 11：資金渠道基礎信息

3.3.2、新建目標機構：

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

圖 12：創建目標機構

3.3.3、資金渠道接口

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

圖 13：渠道接口維護

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

3.3.4、渠道限額

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

圖 14：渠道限額和成本

3.3.5、渠道維護期

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

圖 15：渠道維護期設置

3.3.6、商戶黑白名單

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

3.3.2.1、 白名單商戶：

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

3.3.2.2、黑名單商戶：

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

圖 16：渠道黑白名單維護

3.4 設置渠道路由

3.4.1 渠道路由管理

一套路由規則通過基礎參數、擴展參數可以關聯多個渠道，每條路由規則也要支持，創建、修改等一系列的管理功能。路由規則不建議做物理刪除，因爲直接刪除會影響渠道的穩定切換。可以通過新增一條規則設置新老規則的銜接時間來實現穩定的切換。

圖 17：渠道路由管理

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

3.4.2、路由規則設置

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

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

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

圖 18：快捷路由規則設置

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

2）路由分組：爲什麼要對路由規則分組呢？目的是把同類支付產品，按照不同特性區分出來。例如同樣是快捷支付產品，有的產品只要綁卡簽約就能使用，有的產品需要商戶渠道進件才能使用，有的產品小金額支付可以優惠。這麼多特性顯然需要不同的路由規則來描述，因此需要設置不同的分組。

3）路由規則：

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

4）執行渠道：

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

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

3.5、路由的多組規則

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

圖 19：快捷支付的多組規則例

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

講在最後

最後，渠道路由由於需要提前在各條渠道上開啓開通備付金或者商戶賬戶，因此這種模式比較適合於持牌機構，如果普通商戶也要做支付路由，除非是傳統企業，否則都是有二清問題。

我給人面試的時候，偶爾也會聽到候選人說四方、商家做渠道路由，這種情況經常會被我問的臉紅脖子粗的，反正大家沒做渠道路由可以仔細看下我這篇文章後再去面試吧。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tx1gf8b5m0uJVzxGrjmtBg