p2p平台，為提高充值成功率，降低風險，要接入多家第三方支付渠道，現在的問題是多支付渠道常見的路由方式有哪些？各有什么利弊？
這里簡單說一下第三方支付在做支付渠道路由設計的一些思路，供參考。作為商戶，接入多家第三方支付，在渠道路由策略上比第三方支付的簡單多。
1、支付渠道的封裝層次
一般分為：銀行接口->銀行通道->支付渠道->支付產品->支付解決方案
銀行接口指的是銀行等提供的技術接口。
銀行通道是對銀行接口的封裝，並包含了諸如具體合作銀行及通道的詳細信息。例如同為某家商業銀行的某個支付接口，非總對總的情況，支付公司可能同時在北京分行、上海分行接入。
支付渠道是對銀行通道的業務封裝，包含了諸如通道成本、最低商戶費率等信息。
支付產品是第三方支付對外提供的產品，例如快捷支付。
支付解決方案是針對某個行業的整體解決方案，包含了多個支付及行業定制需求。
所謂的支付渠道路由在以上的幾個封裝層次上都可以發生，因此以下指的“支付渠道路由”的概念是泛指，可能涉及以上各層次。
2、支付渠道路由的設計
一般采用規則引擎或類似方案（例如基於groovy），以支持對規則集靈活調整。
一個相對丑陋的支付渠道路由的設計方案（不一定很合理，僅供參考）
3、支付渠道路由的一些例子
按費率。
按業務級別。
按業務類型。
按渠道交易總額、單筆交易額、渠道限額等額度信息。
按支付渠道類型：移動支付，在線，代扣，b2b，信用卡無磁無密，游戲點卡等。
按支付渠道可靠性要求，例如支付成功率。
按商戶類型。
按渠道狀態，例如監控系統發現某渠道掉單率較高時候。
按照到賬時效。
按所在銀行賬戶的資金頭寸。
按營銷策略，例如某個渠道年底有營銷活動。
按支付渠道優先級，可以是靜態優先級，也可以是動態優先級，實際上優先級的也概念包含了以上各種路由規則。
其實支付渠道路由並沒那么高大上，如果單純只是滿足企業當前的業務需要，用最丑陋的If-Else方式也能搞定。最復雜的問題是怎樣讓支付渠道路由的架構設計能夠快速響應業務快速發展、業務模式創新的需要。
作者：梁川
鏈接：https://www.zhihu.com/question/38278938/answer/79493500
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。