在知乎上就“多种支付渠道路由方案有哪些？”的回答。
这里简单说一下第三方支付在做支付渠道路由设计的一些思路，供参考。作为商户，接入多家第三方支付，在渠道路由策略上比第三方支付的简单多。
1、支付渠道的封装层次
一般分为：银行接口->银行通道->支付渠道->支付产品->支付解决方案
银行接口指的是银行等提供的技术接口。
银行通道是对银行接口的封装，并包含了诸如具体合作银行及通道的详细信息。例如同为某家商业银行的某个支付接口，非总对总的情况，支付公司可能同时在北京分行、上海分行接入。
支付渠道是对银行通道的业务封装，包含了诸如通道成本、最低商户费率等信息。
支付产品是第三方支付对外提供的产品，例如快捷支付。
支付解决方案是针对某个行业的整体解决方案，包含了多个支付及行业定制需求。
所谓的支付渠道路由在以上的几个封装层次上都可以发生，因此以下指的“支付渠道路由”的概念是泛指，可能涉及以上各层次。
2、支付渠道路由的设计
一般采用规则引擎或类似方案（例如基于groovy），以支持对规则集灵活调整。
一个相对丑陋的支付渠道路由的设计方案（不一定很合理，仅供参考）
3、支付渠道路由的一些例子
按费率。
按业务级别。
按业务类型。
按渠道交易总额、单笔交易额、渠道限额等额度信息。
按支付渠道类型：移动支付，在线，代扣，b2b，信用卡无磁无密，游戏点卡等。
按支付渠道可靠性要求，例如支付成功率。
按商户类型。
按渠道状态，例如监控系统发现某渠道掉单率较高时候。
按照到账时效。
按所在银行账户的资金头寸。
按营销策略，例如某个渠道年底有营销活动。
按支付渠道优先级，可以是静态优先级，也可以是动态优先级，实际上优先级的也概念包含了以上各种路由规则。其实支付渠道路由并没那么高大上，如果单纯只是满足企业当前的业务需要，用最丑陋的If-Else方式也能搞定。最复杂的问题是怎样让支付渠道路由的架构设计能够快速响应业务快速发展、业务模式创新的需要。
转载请注明：出家如初,成佛有余 » 多种支付渠道路由方案有哪些？