支付路由的设计与实践

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中的选择性因素只能给出对于一个具体的维度上，多个方案的排名优劣。可是并无回答这个排名优劣如何做用于一个最终的决策。本文给出两个经典的经常使用算法：

🔘锦标赛算法：

锦标赛赛决出优胜者的方式是，经过一轮又一轮的比赛，在每一轮的比赛中，失败者淘汰，优胜者晋级直至最终冠军的产生。

举例: 一个锦标赛的路由算法配置：[费率优先，渠道成功率优先]. 表示此次比赛，全部的候选方案都先进行费率优先的比较，然后进行成功率优先的比较。

在A中张三投资2000元有三个方案参与了比赛，分别是S1: （张三， 银行卡A, 2000元，连连支付），S2: （张三， 银行卡A, 2000元，宝付支付），S3（张三， 银行卡A, 2000元，易宝支付）。 S1费率0.5元，S2费率0.5元，S3费率0.8元。则第一轮在费率上的比赛 S3出局，继续S1和S2的成功率比赛。S1成功率99.1%, S2成功率99.9%。则优胜者为S2. 最终张三收到连连支付发送的短信验证码. 锦标赛算法本质上这是一个偏序比较的算法。

🔘循环赛算法：

循环赛决出优胜者的方式是：全部候选者都参与每一轮的比赛，根据排名座次分别取得必定的积分。最终全部候选人根据总积分决定优胜者。

举例：一个循环赛的配置是：费率排名第一的得3.5分，第二得2分，第三得1分。成功率第一得4分，第二得2分，第三得1分。在这种设置下，假设S1在费率得1分，成功率得4分。总得分5分。而S2在费率得2分，在成功率得2分。总得分4分。则最终S1胜出。说明虽然S1费率最差，可是成功率的领先让其在路由中被择出。而若是S2在费率中排名第一，则S2的成绩从4分变为5.5分。则S2胜出了。说明在巨大的费率优点下，整个路由系统断定S2虽然成功率低一点可是也值得一试。循环赛算法本质上是一个权重比较的算法。

🔘自定义算法：

全部参与排序的方案在各个选择性因素上均可以获得一个通用的排名以及各个不一样的比较结果参数。好比在费率的比较上，各个候选方案能够获得排名以及相对应的费率。在成功率的比较上，

也能够获得相应的排名和预测成功率数值。如下是公式定义与推导：

计费率优先算法为f1:

计成功率优先算法为f2:

则任何路由算法能够定义而且实现为f3:

D.系统流程

为了支持A中李四的例子，整个支付路由系统被设计成可重复迭代计算的流程。 如下设计为例：

当一个输入进入到路由系统时。对于此输入咱们分配了若干的候选方案。通过金额结算器（Amount Decision Maker）计算出每一个候选方案的支付金额。

然后通过过滤器（Filter Decision Maker）会根据渠道银行限额，渠道银行维护，黑名单，白名单等可配置的各类过滤性因素（见本章B的讨论）排除掉一些不合适的方案。

以后进入选择过滤器（Decision Comparator Maker）. 选择过滤器由两部分组成，一部分是业务的选择性因素(见本章B的讨论)，一部分是路由算法(见本章C的讨论)。

最终选出一个合适的候选方案。最终进入中断结算器（Terminal Decision Maker）。 中断结算器的做用是根据输入参数，和计算出的候选者（解）决定是否还须要迭代计算。

对于本章A中张三的例子，中断决算器断定不须要再迭代计算了。因此第一个候选方案就是最终方案（单解）。

而对于本章A中李四的例子，中断结算器在前两次的计算中断定还须要迭代出新的方案。因此最终能够看到完整的支付方案是包括三个解的解集（复解）。

E.系统扩展

根据高内聚，低耦合的软件设计原则，由本章D的设计图可知，不管是对于过滤性因素，仍是选择性因素或者是路由算法。整个系统是能够被实现为可配置化的路由决策系统。在关键的组件上，还能够实现DSL用户自定义编程，从而系统能够拥有线上灵活更改路由的能力。下图即为一个路由策略的配置参数：

对于二次开发而言，开发人员也只须要根据业务增长新的过滤性因素，或者编写新的路由算法/脚本（或引入规则引擎）。线上人员只须要经过配置就能够引入这些新的功能。

整个支付系统还能够考虑针对不一样渠道的返回或者自定义的计算方式决定打开/关闭某些渠道，或者动态调整渠道银行限额。从而使得路由系统拥有闭环控制的能力。

结语

支付路由做为支付系统的“大脑”，并非简单的if-else的堆砌。

但愿本文能够抛砖引玉，欢迎同行一块儿讨论更多的相似解决方案。