我們支付接了多家通道之後，支付路由就是一個繞不過去的問題了。因爲許多通道都有同卡進出的要求，因此不能簡單地把所有支付的流程全部拋給支付模塊，業務系統只關心支付結果。因此我們的支付路由設計得比較輕。當業務系統發起支付請求的時候，需要先帶着支付四要素和支付用途先查詢支付模塊一次，看走哪個通道比較合適，然後再按照返回的結果來調用支付統一接口來進行支付。這樣，當支付必須走某一個通道的時候，可以不用查詢支付路由，直接走相應的支付通道進行支付。
在支付模塊內部，實現了統一的發起代扣請求接口，代扣確認接口，代扣重新獲取驗證碼接口，綁卡接口，綁卡確認接口，代付接口，訂單查詢接口，對賬接口，支付路由查詢接口，每種支付方式還各自實現了主動通知接口。在業務系統每次調用接口的時候，都會在最後返回結果前，記錄當前調用的返回結果到數據庫中，用於成功率分析，支持路由查詢。系統有一個定時任務，每分鐘執行一次，統計最近30分鐘的支付成功率。同時每10分鐘清除一次30分鐘前的數據到歷史數據中，減少當前表的總數據量，加快統計成功率的速度。
在用戶調用支付路由的時候，首先根據支付金額選擇可能合適的支付通道，然後逐一通道進行分析，具體進入某一通道進行分析的時候，先看該通道該張卡如果在30分鐘內支付失敗過，則直接跳過該通道。如果和該銀行卡前6位相同的銀行卡（銀行卡前6位表示一家銀行發行的一種銀行卡）在30分鐘內的支付筆數沒有超過10筆，則嘗試走該通道，如果支付筆數超過了10筆，並且成功率沒有超過60%，則跳過該通道。如果嘗試了所有的通道，都沒有合適的，則直接返回沒有合適的通道。
當然以上的介紹的支付路由比較簡單，因爲我們業務上將需要綁卡且只能綁一張卡的通道給去掉了。我們實現相關的邏輯，但是考慮到這種通道的引入會讓用戶的支付流程更加複雜，同樣調度也更加複雜，因此去掉了該類型通道，並且沒有介紹。