我們支付接了多家通道之後，支付路由就是乙個繞不過去的問題了。因為許多通道都有同卡進出的要求，因此不能簡單地把所有支付的流程全部拋給支付模組，業務系統只關心支付結果。因此我們的支付路由設計得比較輕。當業務系統發起支付請求的時候，需要先帶著支付四要素和支付用途先查詢支付模組一次，看走哪個通道比較合適，然後再按照返回的結果來呼叫支付統一介面來進行支付。這樣，當支付必須走某乙個通道的時候，可以不用查詢支付路由，直接走相應的支付通道進行支付。
在支付模組內部，實現了統一的發起代扣請求介面，代扣確認介面，代扣重新獲取驗證碼介面，綁卡介面，綁卡確認介面，代付介面，訂單查詢介面，對賬介面，支付路由查詢介面，每種支付方式還各自實現了主動通知介面。在業務系統每次呼叫介面的時候，都會在最後返回結果前，記錄當前呼叫的返回結果到資料庫中，用於成功率分析，支援路由查詢。系統有乙個定時任務，每分鐘執行一次，統計最近30分鐘的支付成功率。同時每10分鐘清除一次30分鐘前的資料到歷史資料中，減少當前表的總資料量，加快統計成功率的速度。
在使用者呼叫支付路由的時候，首先根據支付金額選擇可能合適的支付通道，然後逐一通道進行分析，具體進入某一通道進行分析的時候，先看該通道該張卡如果在30分鐘內支付失敗過，則直接跳過該通道。如果和該銀行卡前6位相同的銀行卡（銀行卡前6位表示一家銀行發行的一種銀行卡）在30分鐘內的支付筆數沒有超過10筆，則嘗試走該通道，如果支付筆數超過了10筆，並且成功率沒有超過60%，則跳過該通道。如果嘗試了所有的通道，都沒有合適的，則直接返回沒有合適的通道。
當然以上的介紹的支付路由比較簡單，因為我們業務上將需要綁卡且只能綁一張卡的通道給去掉了。我們實現相關的邏輯，但是考慮到這種通道的引入會讓使用者的支付流程更加複雜，同樣排程也更加複雜，因此去掉了該型別通道，並且沒有介紹。
支付路由的設計與實踐
前言使用者在一些p2p公司進行充值投資經常會收到手機簡訊提示輸入手機驗證碼完成支付。細心的使用者往往會發現，在不同的時間，不同的金額進行充值投資時，往往收到的簡訊驗證碼會略有不同。這些字首可能是 寶付支付 連連支付 易寶支付 等等。其實這背後是有乙個支付路由在替使用者選擇乙個最合適的支付通路完成支付...
支付系統對賬設計
對賬系統作為支付系統中的基石系統,處於整個支付環節中的最後一層，主要用來保證我方支付資料與第三方支付渠道或銀行的資料一致性。在沒有對賬系統之前，財務在第二日手工核對前一日的應收與實收。倘若不一致，這就需要一一核對資料，找出不一致的資料。對賬系統出現之後，就可減少以這種繁瑣手工操作，財務只需要每天關注...
iOS路由設計（二）移動端路由層設計
原生頁面 模組 元件等定義，統稱為資源 resource 在跨應用呼叫和路由層在不同端實現的業務表現需要一致的前提下，需要對資源進行定義，在路由提供內部請求分發的時候則可以提供不依賴對外進行資源定義的功能 外部呼叫如何使用統一標示 uniform 進行表示資源 如何在移動端統一定義訪問請求的過程，從...