https://www.sohu.com/a/235139911_575744
前言
用户在一些P2P公司进行充值投资经常会收到手机短信提示输入手机验证码完成支付。细心的用户往往会发现，在不同的时间，不同的金额进行充值投资时，往往收到的短信验证码会略有不同。
这些前缀可能是“宝付支付”，“连连支付”，“易宝支付”等等。其实这背后是有一个支付路由在替用户选择一个最合适的支付通路完成支付。本文旨在揭示与阐述支付系统背后的路由设计与实践。
支付路由存在的意义
如前言所展示的替用户选择一个合适的充值渠道只是支付路由的冰山一角。
事实上，一个健壮，设计良好的支付路由存在的意义包括但不限于：
A. 降低公司的支付成本：不同支付通道有着不尽一致的支付成本，支付路由旨在尽可能择出一个对于公司而言节省成本的方案。
B. 保证支付成功率：对于投资用户而言，支付成功率是用户体验的重要组成部分。良好的支付成功率可以使用户投资顺畅，对于借款用户而言，支付成功率是投资用户的投资收益，以及借款按时计划还款的重要组成部分。
C. 支持个性化的支付定制：例如对于渠道灰度切换，特定银行特定渠道优先，或是渠道每日限额控制，A/B 测试，脚本定制。这些个性化的渠道方案定制策略都希望可以在路由系统中被考虑和实施。
D. 计算支付整体方案的能力：不仅仅计算单一的支付通道，而是拥有计算一个完成支付方案的能力。
E. 闭环控制：设计良好的支付路由系统应该有闭环控制的能力，能够根据外界环境的变化（比如渠道/银行维护，断路）而对于相同的输入参数给出不同的输出结果。从而降低公司整体的运营成本。
支付路由设计需要考量的因素
对于一个支付路由而言，设计时需要考量的因素有哪些呢？
本章会从系统的输入与输出入手，阐述支付路由中需要考量的业务因素，继而推出路由算法以及背后的整体流程方案。
A. 系统的输入与输出
对于任何一个系统设计而言，首先需要明确系统的边界在哪里。支付路由可以简化为公式：y=f(x).其中y =支付方案，x =支付请求。
支付请求：支付请求包括需要执行的支付金额，使用的银行卡，以及对应的产品。举例：(张三，银行卡A, 充值, 2000元)。 这是一个典型的投资者行为。张三在有一张绑定的银行卡A, 希望投资充值2000元。复杂一点的, (李四，银行卡A, 银行卡B, 代扣，7000元)。对应的业务可能是李四是借款人，登记了银行卡A和银行卡B，期望这次还他的贷款7000元。
支付方案：支付方案包括支付金额，使用的银行卡，渠道。对应支付请求中的例子。可能是：(张三， 银行卡A, 2000元，连连支付)。于是张三手机上收到连连支付发送给他的短信验证码。对应第二个例子复杂一点, 结果是: [(李四，银行卡A, 3000元， 宝付支付), (李四，银行B, 2000元，网易支付), (李四，银行卡B, 2000元，网易支付)]。表示这里会执行三次代扣，分别是通过宝付在银行卡A扣款3000元，通过网易在银行卡B分别扣款2000元。
B. 路由业务：
我们将具体的业务因素定义为两大类：过滤性因素以及选择性因素。
过滤性因素指在一个支付方案在这个因素不被满足时，则整个系统就不会采纳这个支付方案，选择性因素指在多个支付方案可以在这个因素上进行比较，从而很大因素上影响支付方案结果的产生。
典型的过滤性因素包括但不限于以下几类：
▪渠道/银行维护：渠道和银行并不是总是在 7*24小时内保持有效。大部分时候渠道/银行会提前知会公司有关维护信息。
▪ 渠道银行限额：不同渠道银行在不同的支付产品下会有不同的限额设置，限额包括单笔限额，单日限额，单月限额。
▪ 渠道银行交易频率限制：对于特定的渠道, 单卡的每日交易次数也是有所限制。
▪ 渠道用户绑卡情况限制：某些支付产品，渠道是需要先绑卡后使用，对于绑卡失败的用户，该渠道并不能被使用。
▪ 可用渠道配置限制：系统管理员可以根据公司签署的渠道和产品，在系统中配置相应产品对应的多种渠道。对于不在配置列表的方案，则不应予以采纳。
▪ 白名单/黑名单限制：支付请求可以对应相应的白名单和黑名单请求，表示在指定的渠道/指定以外的渠道内进行选择。
典型的选择性因素包括但不限于以下几类：
▪ 渠道费率：对于不同的渠道，相同的支付请求往往会对应不同的支付费率。费率比较是支付路由的核心比较之一。
▪ 渠道成功率：不同的渠道由于其技术,运营水平的差异，往往对应不同的支付成功率。成功率比较也是支付路由的核心比较之一。
C.路由算法：
路由系统是否可以支持费率优先，或者成功率优先，或是其他更复杂的算法呢？在本章B中的选择性因素只能给出对于一个具体的维度上，多个方案的排名优劣。但是并没有回答这个排名优劣如何作用于一个最终的决策。本文给出两个经典的常用算法：