在支付的过程中，用户在前端选择一种支付方式，比如使用招行借记卡来支付后，系统不一定就是调用招行的接口来执行支付。支付宝、微信、易宝支付等第三方支付平台以及银联等，都支持招行借记卡支付，这种将支付方式落地到具体的支付接口的模块，就是支付路由。
1 设计目标
支付路由在支付系统中的核心作用，除了本职工作路由外，还承担如下职责：
- 省钱、省钱、省钱，这是支付路由选择支付通道的最主要的规则，哪个通道省钱，基本会优先考虑这个通道。提升支付产品的 QOS，这体现在系统的可靠性、稳定性、性能和可用性上，通过屏蔽掉无法连接、不稳定、性能低的通道来提升这些指标。支持营销，通过优先选择有优惠活动的通道，可以帮助业务提升付费客户量。降低运营成本，一个设计良好的支付路由，可以大大降低运营投入。
2 软件架构
上述流程，在实现上，参考的架构设计如下：
支付路由并不会直接对接前端的支付产品或者后端的支付渠道，它是支付网关的一部分。如果是基于微服务的架构，支付路由作为一个独立的服务，被支付网关所调用
支付流程
我们以收银台为例，详细说明支付的正确打开方式。 当用户提交订单后，就会被引导到收银台上。 以某东为例，手机上是这样的：
PC上是这样的：
从这里我们可以看出，用户进入收银台之后，首先需要选择默认的支付方式。
支付方式指消费时付款的方式，比如现金支付、货到付款、信用卡支付、借记卡支付、扫码支付等。
那么有哪些支付方式适合在收银台上展示出来？ 也就是支付应用和支付方式的关系。在这里，收银台是一类支付应用。
支付应用指提供给最终用户在特定场景下使用的产品，比如扫码收银、二维码支付、打赏、众筹、POS支付、生活缴费、信用卡返款、手机充值等。 这些应用是建立在支付产品的基础之上，直接面向最终的用户提供服务。
每个支付应用可以用的支付方式是不一样的。比如说，扫码收银，可能仅支持微信和支付宝。POS支付，仅支持银行卡。而信用卡返款，只能从其他的借记卡上去扣款。 支付应用的设计和公司的业务有关，并需要考虑在公司业务场景下的用户支付体验。目前应用最全的数支付宝，可以参观下支付宝的应用（截止至2017年2月15日）：
在收银台这个应用中，在呈现支付方式时，哪些支付方式可以提供给当前场景下的用户来使用，哪个方式应该排在前面，这在支付系统中，是通过引导路由来实现的。
引导路由是根据支付应用、收款商户、订单额度等信息来决定提供给用户的支付方式列表。
当用户选择一种支付方式并提交支付后，支付系统开始执行扣款。比如用户选择通过招行来支付，系统就会请求招行来扣款吗？ 这不一定，因为系统有可能并没有接入到招行接口。除了招行自己的接口外，第三方支付公司、银联等，也可以从招行卡上扣款。那应该使用哪个通道合适？ 这是通过支付路由来决定的。
支付路由指根据用户选择的支付方式，结合费率、QOS等因素，选择合适的银行或者其他公司提供的支付接口来完成资金转移操作。
通过支付路由，我们可以定位到一个落地来执行的支付接口。
支付接口，指由银行提供的用来执行支付的接口。这里要注意，对于同一家银行，除了总行可以提供一个接口，各地的分行也可以提供这个接口。 但一般来说，同一家银行的接口规范是一样的，不同的是提供接口的服务器、费率、性能等。
比如，支付公司可以接入工行总行、工行上海分行、工行北京分行的接口。为什么要接入分行呢？ 一般来说，不少分行会提供更优惠的接入费率，以及经常会举办一些活动来吸引用户接入。
支付通道，这是对支付接口的一个封装，包含合作银行以及通道成本、商户费率、QOS等信息；
银行和第三方支付等渠道提供给电商公司使用的接口，往往都会封装成支付产品。
支付产品指将支付通道打包成满足某特定支付场景需求的商品，比如信用卡快捷、信用卡Moto等。
3 计算因子
路由规则是支付路由的核心。在规则设置上，需要和公司的业务、支付服务的 scope 来综合考虑。这里讲述的是通用的规则设计，供具体实现时参考。
- 产品类型：当然，路由时首选需要考虑渠道可以支持的支付产品。费率：费率是路由最重要的一个指标。一般银行是按照额度来收费，部分是按照交易笔数来收费，复杂点的是阶梯收费，比如 10 万一个费率档次，100 万一个费率档次。优惠活动：银行、第三方支付为了延揽客户，经常也会提供一些补贴给对接的商户，对于使用该渠道的交易进行补贴。而优惠的策略也是多种多样。交易限额：不同通道会限制每次交易的金额上限，以及针对每个账户每天的额度限制。超过这个额度，需要变换通道。卡类型：通道支持的信用卡或者借记卡。通道的 QOS：掉单率、网络延迟以及接口能支持的 TPS，是路由的一个重要衡量因素。资金头寸：电商公司在银行或者第三方平台的资金头寸。如果资金头寸不足，则不能使用这个通道来执行。到账时效：对于转账，资金什么时候到目标账户上，也是影响路由选择的一个因素。商户类型：不同类型的商户可以选择不同的通道。比如高性能、费率高的通道，预留给高级商户。
4 模块设计
支付路由从架构上来说，一般是作为支付网关的一部分。采用微服务架构时，路由模块作为一个独立的服务来部署，为支付网关所调用。所涉及的模块如下所示：
- 支付通道管理：提供通道支持的产品类型、费率等信息。支付通道 QOS 监控：收集通道使用过程中的错误信息，接口延迟，超时情况等信息，用于统计 QOS。资金头寸管理：用于监控公司在各个支付通道上的头寸，并提供头寸的信息。优惠活动：银行、第三方支付为了延揽客户，经常也会提供一些补贴给对接的商户，对于使用该渠道的交易进行补贴。而优惠的策略也是多种多样：
- 支付策略：针对使用该通道的所有支付进行补贴；仅针对首次使用该通道的用户进行补贴；仅针对绑卡的用户进行补贴。补贴时，按照支付金额来设置优惠额度，或者按比例打折。一般活动都会设置补贴总额度。该额度用完了就停止补贴。当然，活动也都会设置开始和截止时间。
5 路由计算
5.1 人工路由
大部分支付系统在接入渠道不多时，人工路由也是一个不错的选择。运营人员指定支付渠道和产品之间的映射关系。出问题时人工切换即可。这种路由的优势是性能高，路由结果可控，出问题时易于排查问题。当接入通道数量增加，营销活动频繁时，人工路由会是一个巨大的投入。
5.2 基于规则的路由
这是相对比较简单的自动路由设计。按照业务要求设置各种路由规则，比如：
if(支付方式==招商借记卡 && 额度<100) then 目标通道==银联token支付
if(支付方式==招商借记卡 && 额度>100) then 目标通道==招商快捷支付- 12
- 12
技术上，规则可以使用 drools 来描述。
5.3 基于权重的路由
规则路由的难点各种规则的制定。在路由因子增多的情况下，规则的维护会是一个噩梦。基于权重的路由则可以缓解这个问题。这种计算方式，简单说，就是对各个通道打分，分数最高的就命中。难点在于制定打分的标准以及计算公式。比如可以从费率、优惠额度、QOS 和使用率角度来评分，给优惠额度高一点的比重，这会导致高优惠额度的通道被优先命中。注意每个维度上的计算公式也不是一成不变的，比如使用率和 QOS 都是动态打分计算。权重的调整是一个挑战，需要在运行过程中不断的调试。必要时，可以使用旁路测试来比较两种算法的优劣。
路由是支付的核心模块，稳定性是第一要素，其次是性能，最后才是怎么省钱。路由系统的设计，需要和公司业务发展保持一致，并适度超前。简单的if else实现可以满足大多数场景下的需求，应该尽量避免在系统建设初期引入过于复杂的路由。