前言使用者在一些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中的選擇性因素只能給出對於乙個具體的維度上，多個方案的排名優劣。但是並沒有回答這個排名優劣如何作用於乙個最終的決策。本文給出兩個經典的常用演算法：
支付路由設計
我們支付接了多家通道之後，支付路由就是乙個繞不過去的問題了。因為許多通道都有同卡進出的要求，因此不能簡單地把所有支付的流程全部拋給支付模組，業務系統只關心支付結果。因此我們的支付路由設計得比較輕。當業務系統發起支付請求的時候，需要先帶著支付四要素和支付用途先查詢支付模組一次，看走哪個通道比較合適，然...
PHP路由技術的原理與實踐
使用者通過指定的url正規化對後台進行訪問。url路由處理類進行處理後。到邏輯處理類，邏輯處理類將請求結果返回給使用者。約定url正規化和規則 約定一套自己喜歡的，對搜尋引擎友好。對使用者友好的url規則 url處理類 即路由實現的核心 對使用者請求的url進行解析處理，獲取到使用者請求的類，方法，...
PHP路由技術的原理與實踐
使用者通過指定的url正規化對後台進行訪問，url路由處理類進行處理後，到邏輯處理類，邏輯處理類將請求結果返回給使用者。約定一套自己喜歡的，對搜尋引擎友好，對使用者友好的url規則 對使用者請求的url進行解析處理，獲取到使用者請求的類，方法，以及query引數等，並將請求 給邏輯處理類。處理 的真...