編輯導語：路由系統能夠基于支付通道的屬性特點和業務系統的要求，為支付交易篩選出符合業務要求的最優的通道。本文作者從路由的架構、實現原理、規則等方面對路由的設計方法進行了分析，一起來學習一下吧。

一、先認識路由

基于支付通道的屬性特點和業務系統的要求，為支付交易篩選出符合業務要求的最優的通道；簡單地說就是業務系統要收款，你路由器幫我選一條最好的通道吧！這就是路由的職能，為通道選擇做決策。

近期我要去三亞看海，找去過的朋友以及在網上了解怎麼去比較劃算和舒适；一個朋友告訴我，坐飛機比較好，用時短，還能看看天空的雲；有的朋友說火車比較好，有足夠的時間體驗漫長和一路風景人文；還有的朋友說騎自行車比較好，既能鍛煉身體又能一路吃遍南北……

當你有一個目的的時候，就會有很多條路放在你的面前，或者說，就算你沒有目的，這些路都在哪裡，隻是等待一個時刻你去選擇。

而我們選擇都是有條件和依據的，比如我要時間最短，比如我要最便宜，比如我要風景最美，比如我要在那個時間段可以……當這些條件都滿足以後，我決定我選擇從北京騎自行車去三亞，你覺得合理麼？

同樣路由亦是如此，它是一個幫助你選擇的管家，你告訴他你要幹嘛，他告訴你走那條路，而這個過程你要提供給他足夠的“要求”，比如我要成功率最高的，我要成本最低的，我要最穩定的，我還要……最後他告訴你，這是你要的，去吧。

支付路由就是這樣，來了一筆支付請求要提交渠道，走哪條渠道呢？這個時候路由就問你“這筆支付什麼特征”，你告訴它，這是工行卡支付的，北京的一位用戶，是信用卡，在A商戶買了一件衣服……路由開始選擇，工行的那招商的通道就不用了，這是工行的所有通道；北京的用戶，那河南的這條工行通道就不用了，這是所有北京的工行通道，A商戶是vvvvvip指定了2條獨家專用通道，而且今天其中一條休假，那就隻能這條了……這樣，我們就選出來了。

路由選擇場景有2個，一個是收銀台展示那些支付方式的路由，不同的用戶，不同的商品組合可能用戶要看到不同的支付方式以及排序；另一類是選擇那條支付通道去提交用戶的支付請求，根據支付的屬性去匹配通道的屬性，選擇最适合該筆支付的請求。

如果你善于撮合愛情，那就大概率善于設計路由規則，因為路由就是撮合了支付對通道的愛。

二、路由的架構解析

對一個事物的認識我們先從整體去認識，會有利于需把控其中每一個環節以及細節，更可以讓你對它有更強的控制力以及靈活能力；接下來我們從各個整體維度去認識和把握路由系統的設計。這将為今後其他子環節的設計打下基礎，例如每個規則的設計，運營後台設計，通道返回碼設計，對不同場景下的路由的設計演變等等。

通道的分類和特點：既然你要篩選某個群體，那你必然要知道這個群體的畫像；路由是對通道的篩選，那麼我們就需要知道通道有什麼樣的屬性和特點，都有哪些類型的通道；當然不同的公司基于自己的發展需要可能對通道的分類方法不同，但關鍵是“你總歸有一個屬于你的分類方法”。

對于通道的認識可以看下下面的這篇文章：支付通道介紹和接入

1）支付類通道

這是我們非常清楚的通道類型，為支付的核心通道，也是支付指令提交的通道，種類和數量最繁多的通道，也是路由的核心篩選對象；對于支付通道我們又可以分出快捷通道、網銀通道、代扣通道、墊資通道等等，當然對于一個普通企業來說，也可以按支付品牌去分，比如微信通道、支付寶通道、銀行卡支付通道。

對用通道我們還要關注其支持的卡類型，誰發起交易，有無行業限制，交易需要的要素等等。

2）鑒權類通道

我們常聽說的四要素鑒權，三要素鑒權，五要素鑒權，用戶在綁卡支付時需要進行銀行的鑒權，來判斷卡的有效性；在結算卡綁定時同樣需要通過鑒權去判斷卡的有效性。

為了成功率、備份、成本考慮，一個機構也會接入多個鑒權通道，所以也需要基于鑒權請求路由出最有的鑒權通道。

3）實名類通道

對于一些業務場景需要進行實名認證，比如你要到一個家政平台去做兼職，你需要實名認證簽約，就需要上傳身份證照片，人臉識别等。

同理也會接入多條實名通道，需要進行路由。

那麼我們常見的用于對通道進行分類或者篩選的通道屬性有哪些呢？這些屬性有些維護在通道管理，是通道的本身屬性，有些是支付信息裡是支付單據的内容？

• 交易類型：網銀支付，快捷支付，pos支付，聚合支付等等
• 銀行：招商銀行，農業銀行，北京銀行
• 賬戶類型：對公賬戶，對私賬戶，政府專戶，備付金賬戶等
• 卡種：借記卡，貸記卡
• 通道狀态：通道是開啟狀态還是關閉狀态
• 限額：通道有交易限額，不滿足交易限額的支付不選擇，比如單筆限額2萬，2.5萬的支付不能選擇
• 簽約：如果某條通道需要用戶提前簽約，則不簽約用戶發起的支付不選擇
• 銀行短驗：如果這筆支付不能接收銀行下發的短信驗證，不選擇
• 最少鑒權項優先：選擇需要鑒權的要素數最少的通道
• 營業時間：有些通道有固定的維護時間，在維護時間内不選擇
• 行業準入：有行業限制的通道不選擇，比如某通道不允許借貸還款支付，則不選擇
• 商戶白名單：如果通道隻允許在名單裡的商戶的交易使用，則不在名單裡的商戶的交易不能選擇
• 通道黑名單卡：該卡種如果在某些通道的卡黑名單裡，則不能選擇
• 簽約通道優先：優先選擇需要銀行簽約的通道
• 優先級最高優先：通道固有屬性，當多條通道可用時，選擇其中優先級屬性最高的通道
• 成本最低優先：多條可用時，選擇預計算成本最低的通道
• 三方通道微信優先：如果多條三方通道可用時，優先選擇微信通道

在不同的行業，不同的公司，不同的業務模式，接了不同的通道矩陣的情況下，基于實際會設定不同的路由規則，這是個無限的過程，但是我們要掌握基礎的方法，那就是“選擇的藝術”，如果你懂了選擇的邏輯，那麼再複雜的事物，你都能選出最佳的那一個。

三、路由的實現原理

路由的目的是基于交易特征篩選最匹配的通道，所以這裡我們就發現了關鍵。

1. 路由三要素

交易特征就是你要知道用戶發起的這筆支付的畫像，什麼類型的支付，用的什麼卡，買的什麼品類的商品，商戶是誰等等。

通道就是上面我們講的他也有他的畫像，這個是什麼類型的通道，支付還是鑒權，網銀還是快捷，有沒有行業限制，對公還是對私，成本如何等等。

然後就是匹配，通過什麼樣的匹配模型去将具有一定交易特征的支付匹配到可用的通道上，這也是路由的核心原理所在。

2. 要素準備

所以我們要對通道進行管理，維護全部通道的基礎屬性，就像你去一個婚戀網站去填一些資料一樣，身高，體重，學曆，有無特殊要求，便于系統幫你匹配最合适的人，也便于匹配到的人對你再次篩選。

然後就是路由的規則體系，我們知道匹配的時候關注什麼内容，如何去執行這個規則條件；我們的規則可以分兩類，一類是分組規則，另一類是篩選規則，并且對每一類規則我們都需要一個模塊進行管理，比如成本最優規則，你就需要一個每個通道成本管理的地方去維護計費模式以及費率等，便于去計算本筆支付的通道成本。

這樣我們就知道了路由的實現原理就是，交易将特征傳入路由系統，路由系統針對每項規則去過濾已經維護的全部通道，直到挑選出最合适的那個。

3. 路由原理模型

調用系統比如支付網關、業務系統、支付系統等，傳入交易特征，路由系統先根據規則樹快速定位到可用通道，然後再通過一組篩選規則注意篩選，最終輸出一條可用通道給到請求方。

四、路由的規則體系

對于路由的規則體系我們從三個方面去認識，規則的鍊條、規則樹、規則組。

1. 規則鍊條

規則的鍊條就是為一個業務線，一個支付産品，甚至是一個商戶設定一個路由規則集合，這個規則集合裡規定了這個交易特征需要執行哪些規則，而這個規則鍊上我們可以分成規則樹和規則組兩部分。

規則樹就是我們通過交易類型，卡類型等必傳的交易特征，快速縮小通道範圍，避免對全部通道執行沒必要的規則判斷，比如你是鑒權，那麼就沒必要去判斷快捷類通道。

2. 規則樹

規則樹就是設定幾個固定維度作為快速篩選通路，可以快速定位到目标通道集合。

3. 規則組

規則組就是将全部規則中挑選一部分規則用于這個場景的支付通道的篩選，例如通道狀态過濾、行業準入、營業時間、黑白名單、成功率最高、成本最低等。

這個規則組包含：篩選規則、執行順序。

規則組執行的邏輯

4. 示例

通過分組規則我們得到了一個通道組，如上面我們選出3條通道“通道A、通道B、通道C”，最終我們要選擇一條通道，所以還需要進一步做篩選，這時候我們就用到了篩選規則；假如我們設定了3個屬性做篩選“狀态，商家報備，成本優先”，這3條通道屬性如下：

假設商家已經在A通道做了報備，所以整個篩選流程模型如下：

我們知道案例中入參應該是3條通道：通道A、通道B、通道C。

通過篩選後，因為C關閉了被過濾掉，我們得到了2條通道：通道A、通道B，因為有下一條規則，所以我們繼續往下走，報備規則的篩選，這時候流程圖如下：

因為商家已經報備了A通道，B通道不需要報備，所以，經過這個篩選，我們依然得到兩條通道通道A，通道B，因為有下一條規則，所以我們繼續往下走。

成本最低優先規則的篩選，這時候流程圖如下：

經過這個篩選，在A和B通道對比中，B的成本最低，所以最終我們得到了一條最優的通道：通道B。

五、路由的流程架構和産品架構

路由一般有業務系統調研，比如實名認證時可以有用戶中心調用，綁卡鑒權時可以由錢包調用，用戶發起支付跳轉收銀台或者支付方式列表時可以由交易系統調用，提交支付篩選通道時可以由支付系統或者支付網關調用。

路由的産品系統架構

通過上面的介紹，路由系統的産品架構基本已經比較清楚了，因為我們知道了路由在支付體系流程裡的空間位置，又知道了路由系統的原理以及包含的内容模塊，将這些封裝起了就可以得到我們的路由系統的産品架構了。

六、展示路由

到一個平台去購買東西，提交了訂單以後會到達收銀台頁面，這時候按照自己的喜好去選擇一個支付方式，進入支付流程。

其中我們要回想一下，同樣在京東，你每次購物，收銀台展示的支付方式個數以及排序都一樣麼？

再想另一個問題：同一個時刻不同的人看到的收銀台支付方式情況都一樣麼？

答案顯然是各不相同，這就是我們今天要介紹的“展示路由”，它決定了用戶在支付時能看到什麼支付方式以及如何進行排序。

京東-餓了麼-美團

1. 為什麼會看到不同支付方式和排序呢

這必然是随着平台不斷的發展，積累了更複雜的場景和多樣化需求造成的，就像你剛剛成立一個電商平台，在用戶很少，商品很少的情況下，加上技術人力不足，可能期初其需要微信和支付寶兩種方式就行了；随着大額交易越老越多，你們又上了一個預充值餘額支付，那這樣如果沒有開通的用戶其實就不需要展示給他餘額支付方式；當然如果你想讓更多用戶使用餘額支付，你可以增加開通餘額賬戶的引導，或者默認所有用戶都自動開通餘額賬戶，隻不過餘額是0。

1）收銀台的個性化展示

我們可以從以下幾個方面去分析，當然還有很多種其他原因，歸根結底都是因為多樣化業務訴求的産生。

2）支付方式多樣化

随着平台的發展，為了迎合更多場景及用戶，會簽約更多的支付渠道，從微信支付寶，到銀行卡支付，蘋果支付，再到銀聯閃付，數字人民币支付，餘額支付等等，多樣化的支付方式就必然對收銀台的展示策略提出了更高的要求。

3）業務的多樣化

有了豐富的支付渠道之後，其實業務多樣化同樣也會影響支付方式的展示，比如有些渠道拒絕某些品類的支付請求，所以如果用戶選擇了這中品類下的商品，那收銀台就不應該展示不接收該類商品交易的渠道支付方式。

4）商戶需求的多樣化

随着商戶數量的增加，種類的增加，合作模式的增加，對支付渠道的要求，甚至是收銀台的要求也會相應增加，比如有些ka大商戶因為跟某些渠道有合作，可能就會要求僅支持某幾類支付方式，這樣就需要根據大商戶的特殊要求設定支付方式。

5）平台訴求的多樣化

平台本身也會有營銷等各種訴求，AB實驗的訴求等，也會對收銀台的個性化提出要求，比如某些用戶優先推薦微信支付，某些已經綁了銀行卡的用戶優先推薦銀行卡支付等。

6）渠道合作的多樣化

有些渠道可能會提供一些合作模式，比如你把我放在第一位我就給你降費率，或者更有甚者，你把競品折疊，我再給你降一些費率，而這種合作模式又可能不是全量用戶，比如你要将50%的交易采用這種收銀台模式。

7）用戶習慣的多樣化

用戶體量足夠大時，你就不得不考慮更好的用戶習慣和體驗的訴求，比如有些用戶每次購物都是用微信支付，那麼下次支付你要是推薦了支付寶而折疊了微信，那必然會讓用戶多操作幾次去找到自己想要的支付方式；而如果有些用戶上次使用了銀行卡支付，那麼下次推薦上次用的卡可能是一個不錯的選擇。

8）渠道營銷合作

有些銀行渠道可能會提供一些支付補貼，這也會成為支付方式個性化的需求來源，但是這種營銷又可能不是全量用戶，所以這裡又需要策略問題。

所以說，收銀台個性化展示的目的有時為了更高的成功率，有時為了提高用戶體驗，為了給某一個支付渠道引流等不同的訴求，但最終實現的業務效果就是不同的人可能看到的收銀台頁面的支付方式的種類和順序會有差别。

2. 如何從産品上實現收銀台個性化

那麼從産品上我們該如何實現收銀台的個性化展示訴求呢，這裡就是我們今天要介紹的：展示路由，覺得用戶在收銀台看到什麼支付方式，以及支付方式如何排序的問題。

訴求清楚了，那麼去滿足這個訴求就容易了，不同的公司，不同的訴求的組合，必然有不同的解法；通道的多少，展示策略的場景複雜程度都會影響設計的複雜程度，但是我們簡單介紹集中常見的手段。

1）固定配置

如果公司業務沒那麼複雜，簽約的支付渠道不多，個性化求很容易枚舉，那麼可以通過配置後台實現，窮舉個性化場景，得到收銀台模闆，根據傳入的交易特征匹配相應的模闆即可以得到收銀台展示規則；如果交易特征傳入了快車，并且是在8-11點的高峰時段，那麼我們就調用智能路由執行更複雜的算法而不指定支付方式。

2）個性化策略

當我們的交易有更多的特征，業務有更多的訴求，支付渠道有更多的合作模式，業務場景更加複雜時，可能枚舉配置模闆就不是一個好的選擇；我們就需要采用更加複雜和靈活的策略化路由能力了。

比如信用極好的用戶推薦白條金條的路由策略，已經綁卡的用戶優先推薦有支付别貼的銀行卡策略。

蘋果用戶優先推薦蘋果支付，安卓用戶優先推薦微信支付，pc用戶優先推薦微信掃碼，大額支付優先推薦線下支付。

618期間，全部用戶優先推薦微信免密支付，次推薦微信支付等等。

我們枚舉策略場景并進行分層，通過一層層的策略選擇出最佳的收銀台支付展示結果。

3）定制化設定

有些特殊品類或者大客戶可能需要特殊的支付渠道或者支付方式，那麼既可以定制特殊的收銀台，比如選擇企業，需要直接跳轉到該企業提供的收銀台去完成支付，這時候就需要為該商戶配置指定的收銀台鍊接了。

業務有業務的訴求，産品有産品的實現方法；隻要是明白了業務訴求，就一定有解法，如果把産品實現作為底層的黑匣子，那麼唯一知道的就是，相應的場景用戶得到了期望的支付方式列表以及排序；所以展示路由解決的核心問題就是實現“你想看到的和想讓你看到的”。

經驗的使命是收斂于方法，方法的歸宿必然收衍生出更多經驗。

互聯網發展了這麼多年，每家公司都是從0慢慢沉澱成長起來；這麼多的“廠”的支付體系各有千秋，可以說都是适合自己的“個性化定制”。

我經曆過幾家不錯的公司，以及跟很多朋友交流大家所在公司的支付體系，總的來說“都能用，但都一般”，都能用是都可以支持自己家的業務，也挺好，都一般我想就是上面說的，大家都是摸着河過來的。

當初第一個設計的人的水平決定了起點，中間的衆多參與者的水平決定他的發展。有的有幸遇到幾位水平不錯的産品經理，被一次次升級重構越來越好，沒有長歪；有的可能不太幸運，越長越歪，以至于後來的很多優秀的産品經理都無法修正。

所以我的經驗裡告訴我，互聯網世界裡不要去相信權威，本身也沒有權威，隻有“虎威”，權威是它的知識的專業性，虎威是它業務的地位。

我們為什麼相信“支付寶的支付體系優秀”，我想更多是因為“支付寶的業務優秀”，所以我們才相信他的支付體系也優秀。這之間也沒有必然的聯系，但是這麼龐大的業務體系，必然會反向促使他的支付體系更加完善，更加普世，更加值得借鑒，因為他打過很多勝仗，但系統設計方法和理念并不絕對的一定比一家小公司好。

所以對于支付知識體系的建立，我更喜歡“立足當下的實用去抽象可複用的方法”。

大家各不相同，但其中有通行的方法可行，可被抽象，可被複用；在通行的方法下，也大概率可以設計出更優秀的支付系統，因為他的理念至少可以涵蓋曾經的“經驗體系”。

#專欄作家#

陳天宇宙，陳天宇宙，人人都是産品經理專欄作家。多平台支付領域專欄作者，十年資深産品；天使投資人；專注為10萬支付産品經理和支付機構以及企業提供深度支付内容和服務！

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部