支付路由的設計與實踐

https://www.sohu.com/a/235139911_575744

前言

用戶在一些P2P公司進行充值投資常常會收到手機短信提示輸入手機驗證碼完成支付。細心的用戶每每會發現，在不一樣的時間，不一樣的金額進行充值投資時，每每收到的短信驗證碼會略有不一樣。

這些前綴多是「寶付支付」，「連連支付」，「易寶支付」等等。其實這背後是有一個支付路由在替用戶選擇一個最合適的支付通路完成支付。本文旨在揭示與闡述支付系統背後的路由設計與實踐。

支付路由存在的意義

如前言所展現的替用戶選擇一個合適的充值渠道只是支付路由的冰山一角。

事實上，一個健壯，設計良好的支付路由存在的意義包括但不限於：

A. 下降公司的支付成本：不一樣支付通道有着不盡一致的支付成本，支付路由旨在儘量擇出一個對於公司而言節省成本的方案。

B. 保證支付成功率：對於投資用戶而言，支付成功率是用戶體驗的重要組成部分。良好的支付成功率可使用戶投資順暢，對於借款用戶而言，支付成功率是投資用戶的投資收益，以及借款按時計劃還款的重要組成部分。

C. 支持個性化的支付定製：例如對於渠道灰度切換，特定銀行特定渠道優先，或是渠道每日限額控制，A/B 測試，腳本定製。這些個性化的渠道方案定製策略都但願能夠在路由系統中被考慮和實施。

D. 計算支付總體方案的能力：不只僅計算單一的支付通道，而是擁有計算一個完成支付方案的能力。

E. 閉環控制：設計良好的支付路由系統應該有閉環控制的能力，可以根據外界環境的變化（好比渠道/銀行維護，斷路）而對於相同的輸入參數給出不一樣的輸出結果。從而下降公司總體的運營成本。

支付路由設計須要考量的因素

對於一個支付路由而言，設計時須要考量的因素有哪些呢？

本章會從系統的輸入與輸出入手，闡述支付路由中須要考量的業務因素，繼而推出路由算法以及背後的總體流程方案。

A. 系統的輸入與輸出

對於任何一個系統設計而言，首先須要明確系統的邊界在哪裏。支付路由能夠簡化爲公式：y=f(x).其中y =支付方案，x =支付請求。

支付請求：支付請求包括須要執行的支付金額，使用的銀行卡，以及對應的產品。舉例：(張三，銀行卡A, 充值, 2000元)。 這是一個典型的投資者行爲。張三在有一張綁定的銀行卡A, 但願投資充值2000元。複雜一點的, (李四，銀行卡A, 銀行卡B, 代扣，7000元)。對應的業務多是李四是借款人，登記了銀行卡A和銀行卡B，指望此次還他的貸款7000元。

支付方案：支付方案包括支付金額，使用的銀行卡，渠道。對應支付請求中的例子。多是：(張三， 銀行卡A, 2000元，連連支付)。因而張三手機上收到連連支付發送給他的短信驗證碼。對應第二個例子複雜一點, 結果是: [(李四，銀行卡A, 3000元， 寶付支付), (李四，銀行B, 2000元，網易支付), (李四，銀行卡B, 2000元，網易支付)]。表示這裏會執行三次代扣，分別是經過寶付在銀行卡A扣款3000元，經過網易在銀行卡B分別扣款2000元。

B. 路由業務：

咱們將具體的業務因素定義爲兩大類：過濾性因素以及選擇性因素。

過濾性因素指在一個支付方案在這個因素不被知足時，則整個系統就不會採納這個支付方案，選擇性因素指在多個支付方案能夠在這個因素上進行比較，從而很大因素上影響支付方案結果的產生。

典型的過濾性因素包括但不限於如下幾類：

▪渠道/銀行維護：渠道和銀行並非老是在 7*24小時內保持有效。大部分時候渠道/銀行會提早知會公司有關維護信息。

▪ 渠道銀行限額：不一樣渠道銀行在不一樣的支付產品下會有不一樣的限額設置，限額包括單筆限額，單日限額，單月限額。

▪ 渠道銀行交易頻率限制：對於特定的渠道, 單卡的每日交易次數也是有所限制。

▪ 渠道用戶綁卡狀況限制：某些支付產品，渠道是須要先綁卡後使用，對於綁卡失敗的用戶，該渠道並不能被使用。

▪ 可用渠道配置限制：系統管理員能夠根據公司簽署的渠道和產品，在系統中配置相應產品對應的多種渠道。對於不在配置列表的方案，則不該予以採納。

▪ 白名單/黑名單限制：支付請求能夠對應相應的白名單和黑名單請求，表示在指定的渠道/指定之外的渠道內進行選擇。

典型的選擇性因素包括但不限於如下幾類：

▪ 渠道費率：對於不一樣的渠道，相同的支付請求每每會對應不一樣的支付費率。費率比較是支付路由的核心比較之一。

▪ 渠道成功率：不一樣的渠道因爲其技術,運營水平的差別，每每對應不一樣的支付成功率。成功率比較也是支付路由的核心比較之一。

C.路由算法：

路由系統是否能夠支持費率優先，或者成功率優先，或是其餘更復雜的算法呢？在本章B中的選擇性因素只能給出對於一個具體的維度上，多個方案的排名優劣。可是並無回答這個排名優劣如何做用於一個最終的決策。本文給出兩個經典的經常使用算法：

🔘錦標賽算法：

錦標賽賽決出優勝者的方式是，經過一輪又一輪的比賽，在每一輪的比賽中，失敗者淘汰，優勝者晉級直至最終冠軍的產生。

舉例: 一個錦標賽的路由算法配置：[費率優先，渠道成功率優先]. 表示此次比賽，全部的候選方案都先進行費率優先的比較，然後進行成功率優先的比較。

在A中張三投資2000元有三個方案參與了比賽，分別是S1: （張三， 銀行卡A, 2000元，連連支付），S2: （張三， 銀行卡A, 2000元，寶付支付），S3（張三， 銀行卡A, 2000元，易寶支付）。 S1費率0.5元，S2費率0.5元，S3費率0.8元。則第一輪在費率上的比賽 S3出局，繼續S1和S2的成功率比賽。S1成功率99.1%, S2成功率99.9%。則優勝者爲S2. 最終張三收到連連支付發送的短信驗證碼. 錦標賽算法本質上這是一個偏序比較的算法。

🔘循環賽算法：

循環賽決出優勝者的方式是：全部候選者都參與每一輪的比賽，根據排名座次分別取得必定的積分。最終全部候選人根據總積分決定優勝者。

舉例：一個循環賽的配置是：費率排名第一的得3.5分，第二得2分，第三得1分。成功率第一得4分，第二得2分，第三得1分。在這種設置下，假設S1在費率得1分，成功率得4分。總得分5分。而S2在費率得2分，在成功率得2分。總得分4分。則最終S1勝出。說明雖然S1費率最差，可是成功率的領先讓其在路由中被擇出。而若是S2在費率中排名第一，則S2的成績從4分變爲5.5分。則S2勝出了。說明在巨大的費率優點下，整個路由系統斷定S2雖然成功率低一點可是也值得一試。循環賽算法本質上是一個權重比較的算法。

🔘自定義算法：

全部參與排序的方案在各個選擇性因素上均可以獲得一個通用的排名以及各個不一樣的比較結果參數。好比在費率的比較上，各個候選方案能夠獲得排名以及相對應的費率。在成功率的比較上，

也能夠獲得相應的排名和預測成功率數值。如下是公式定義與推導：

計費率優先算法爲f1:

計成功率優先算法爲f2:

則任何路由算法能夠定義而且實現爲f3:

D.系統流程

爲了支持A中李四的例子，整個支付路由系統被設計成可重複迭代計算的流程。 如下設計爲例：

當一個輸入進入到路由系統時。對於此輸入咱們分配了若干的候選方案。通過金額結算器（Amount Decision Maker）計算出每一個候選方案的支付金額。

然後通過過濾器（Filter Decision Maker）會根據渠道銀行限額，渠道銀行維護，黑名單，白名單等可配置的各類過濾性因素（見本章B的討論）排除掉一些不合適的方案。

以後進入選擇過濾器（Decision Comparator Maker）. 選擇過濾器由兩部分組成，一部分是業務的選擇性因素(見本章B的討論)，一部分是路由算法(見本章C的討論)。

最終選出一個合適的候選方案。最終進入中斷結算器（Terminal Decision Maker）。 中斷結算器的做用是根據輸入參數，和計算出的候選者（解）決定是否還須要迭代計算。

對於本章A中張三的例子，中斷決算器斷定不須要再迭代計算了。因此第一個候選方案就是最終方案（單解）。

而對於本章A中李四的例子，中斷結算器在前兩次的計算中斷定還須要迭代出新的方案。因此最終能夠看到完整的支付方案是包括三個解的解集（復解）。

E.系統擴展

根據高內聚，低耦合的軟件設計原則，由本章D的設計圖可知，不管是對於過濾性因素，仍是選擇性因素或者是路由算法。整個系統是能夠被實現爲可配置化的路由決策系統。在關鍵的組件上，還能夠實現DSL用戶自定義編程，從而系統能夠擁有線上靈活更改路由的能力。下圖即爲一個路由策略的配置參數：

對於二次開發而言，開發人員也只須要根據業務增長新的過濾性因素，或者編寫新的路由算法/腳本（或引入規則引擎）。線上人員只須要經過配置就能夠引入這些新的功能。

整個支付系統還能夠考慮針對不一樣渠道的返回或者自定義的計算方式決定打開/關閉某些渠道，或者動態調整渠道銀行限額。從而使得路由系統擁有閉環控制的能力。

結語

支付路由做爲支付系統的「大腦」，並非簡單的if-else的堆砌。

但願本文能夠拋磚引玉，歡迎同行一塊兒討論更多的相似解決方案。