支付域——支付路由设计

摘要

本文深入探讨了支付路由系统的背景、核心作用、设计原则以及业界常见形态。文章详细解析了支付方式咨询、渠道咨询和渠道路由的概念，并介绍了支付路由的规则种类、交易参数、通道属性和常见筛选规则。进一步讨论了基于规则的渠道路由设计、自动化开关的渠道路由以及高阶智能路由。旨在为支付系统设计提供指导和参考。

1. 支付路由背景

有些支付公司没有区分支付方式咨询、渠道咨询、渠道路由，而是混在一起做掉，这样的好处是简单而实用，缺点是扩展性不足。下面将以扩展性最好的拆分方式来讲解。

支付方式咨询：根据用户的请求，组装可用支付方式列表返回给用户。由收银域提供服务。
渠道咨询：根据用户的请求，组装可用的渠道列表和渠道属性返回给收银域，再由收银域转换为支付方式返回给用户。由渠道网关提供服务。
渠道路由：当有多个渠道可用时，选择出最优的一个渠道。由渠道网关提供服务。

再详细一点，如下：

支付方式咨询：解决用户可以使用哪些支付方式，比如余额、招行借记卡、招行信用卡等。比如虚拟商品不能使用信用卡，这种支付方式的管理就是支付方式咨询的职责。
渠道咨询：解决是否有渠道可以支持当前的支付行为。比如用户绑定了招行借记卡，但招行当前正在维护无法提供服务，那就将渠道状态设置为不可用，收银域对应的支付方式会置灰。
渠道路由：解决最优渠道问题。需要综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。

2. 渠道路由核心作用

渠道路由核心作用是当有多个渠道同时满足业务诉求时，综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。具体如下：

提高支付成功率：通过选择最合适的渠道，可以提高支付的成功率，减少支付失败带来的用户流失。原因在于不同的渠道在其内部的风险偏好是不一样的，同一个请求在A渠道会失败，但在B渠道会成功。
优化成本：不同渠道的费用可能不同，通过合理的路由，可以降低支付成本。一些渠道还有阶梯收费，需要通过分流不同的渠道，保持整体成本最优。
提升用户体验：快速、稳定的支付体验能增强用户的满意度和忠诚度。用户如果经常在A渠道支付，新的请求过来后，仍然发给A渠道支付的成功率往往会更高。
负载均衡：将支付请求合理分配到不同的渠道，避免某个渠道过载，提升整体系统的稳定性。

举几个渠道路由应用的小场景：

用户使用招行信用卡支付，支付平台同时对接了网联和银联，而网联和银联都支持招行信用卡，那么就需要渠道路由挑选一个渠道。
做实名认证，平台对接了多个实名认证通道，通过渠道路由挑选一个认证渠道。

由上面可以看到，除了支付路由外，还可能有信息类渠道路由，比如实名认证类。

那退款有没有路由？显示没有。在银联做的支付，只能去银联退款。特殊的渠道也没有路由，比如用户选择使用支付宝支付，因为支付宝只能在支付宝做支付，所以无需路由。

3. 渠道路由的设计原则

渠道路由作为支付系统的核心模块，需要满足以下几个设计原则：

灵活性：路由规则需要支持动态调整。从业务的角度出发，有些场景考虑成本，有些场景考虑成功率，都能方便支持。
扩展性：设计时要考虑到未来可能新增的支付渠道，新增的决策因子，这些都不能在代码中写死，确保系统易于扩展。
高可用性：路由系统本身需要具备高可用性，确保在高并发和故障情况下仍能稳定运行，哪怕内部报错，仍然能返回一条可用的渠道。
性能：在保证准确性的前提下，路由决策需要快速，不能成为支付流程的瓶颈。

4. 业界常见路由形态

根据业务的需要，通常有以下几种路由形态：

硬编码取第一个。在项目上线初期，为了赶进度，同时渠道也不多，常常在代码中写死取第一个，先保证支付主流程能走通。
基于规则的路由。通过预定义的规则提高灵活性和可扩展性。
智能路由。利用机器学习和大数据分析，根据历史数据和实时状态，智能地选择最佳渠道。

5. 支付路由解析

一个公司接的通道多了，路由就成了必需品。即使不做路由系统，完全依靠代码实现，但依然需要路由模型和逻辑。那么，路由筛选最优通道就需要一系列的筛选规则，路由规则就成了路由系统的重中之重。

5.1. 两种规则种类

路由规则可以分成2大类，分组规则和筛选规则。分组规则顾名思义就是对通道进行分组。

为什么要分组呢？我们知道，路由筛选是多种类的，不仅仅是筛选收款通道，还有付款通道、鉴权通道、实名通道等等。因此，如果一笔请求是付款业务，那么你就完全没必要去判断鉴权通道，否则你将全部通道都做一次判断，那路由的效率损失和性能消耗是非常大的。

这样的话，在请求来了以后，通过分组条件对通道快速进行分组筛选，先精确过滤掉大部分通道以后，再进行精细筛选，效果就更好了。

分组维度如何设定呢？其实分组条件一般不会太多，就如对人群进行分组一样，可以通过性别进行分组，男性、女性；可以通过籍贯进行分组，南方人、北方人。通道分组条件常见的如：交易类型，账户类型，卡种，银行等。

分组条件的设置就是这个原理。

进行分组以后，剩下的更少的几个通道，再进行筛选规则的筛选。比如通过卡种做了分组以后，剩下的全部是支持信用卡的通道，再进一步筛选，这时候的要筛选的通道数量明显减少。

每经过一个筛选规则的过滤，都会剔除掉一部分通道，直到最后剩下1条通道或者0条，如果是0条的话，这笔交易可能就无法完成支付了。

5.2. 何时需要建立“规则链”

上面我们讲了通道规则往往会分为分组规则和筛选规则2大类，二者共同构成一个逻辑链条。

一个平台只有一个规则链吗？不一定。如果你是一家非常小的公司，或者支付业务非常单一的公司，只有收款业务，那么一条链就够了，就是判断这笔收款走哪条收款通道。但是，如果你是一家业务种类非常多，通道种类非常多的公司，一条链可能就不够了。

比如：从支付产品来看，可能不同的支付产品需要的规则链不同，例如网银支付、快捷支付，通道的属性不同，需要校验条件不一样；但大部分条件是一样的，比如快捷支付设置了用户等级筛选条件，只有VIP用户才配用快捷支付，而网银不受这个限制，那么快捷支付的规则链中就多了一个“用户VIP筛选”。

从业务种类来看，支付、付款、鉴权、实名等不同的业务，其分组条件和筛选条件就完全不同。

例如，鉴权类业务，需要路由筛选出最优的鉴权通道，那么，鉴权类筛选里就有如“鉴权项数量”的筛选过滤，你要鉴权3项，而一条仅支持2项鉴权的鉴权通道就不满足了。因此，需要将整体业务进行抽象，抽象出多条规则链条。不同类型的企业通道类型不同，整个规则体系的设计方法论一样，只不过具体规则内容不同。

为了更好分析下面的内容，我们假设是一家三方支付机构；三方支付机构的通道来自网联、银联、银行以及其他的三方机构，通道种类非常多，数量也比较多，能分析的规则就比较多；就更容易覆盖普通企业的路由条件。

5.3. 交易参数和通道属性

路由的基本逻辑是匹配，根据交易参数，匹配通道的属性，以获得最合适的通道。所以，研究路由规则就不得不研究匹配逻辑，而研究匹配逻辑就不得不了解交易参数和通道的基本属性。

5.3.1. 交易传入参数

其实就是路由的请求接口要求传进来的参数，可能不同的路由业务要求的参数不同，比如支付传参和鉴权传参就不一样。比如支付参数，你必须传进来商户号吧，这样路由系统才知道是哪个商户的交易，你必须传进来银行卡种吧，毕竟借记卡和信用卡所能用的通道不同，等等。

当然了，传什么不是机械的，是由你的路由规则决定的，换句话说就是路由需要什么就传什么。

5.3.2. 通道属性参数

通道属性也可以认为是通道的画像，支持什么类型的支付，支付什么行业，什么时候维护，哪家银行的通道等等。

有了这些属性，才能与交易的特征进行匹配。

5.4. 设定分组规则

分组规则前面介绍了，是为了快速缩减通道范围。分组条件往往是交易在请求路由系统时的必传参数，而且多是通道的可枚举的离散属性。

什么是离散呢，就是一个一个的，比如卡种，就是信用卡、借记卡。相对于离散就是连续，如时间，成本，就是连续条件，你不能用成本对通道进行分组，除非通过设定成本区间将成本这种连续的属性，变成离散属性。如将通道成本分成三个区间[0,0.5)[0.5,0.8)[0.8,+∞)，就可以通过成本区间将通道进行分组。

常见的分组条件有：

交易类型，是消费支付、还是付款、还是鉴权；也就是这条通道支持的交易属性是什么，是支付通道、付款通道还是鉴权通道。
账户类型，是对个人还是对公账户；就是这条通道是支持个人支付还是企业支付。
卡种，是借记卡还是信用卡，这也是通道的属性之一，支持借记卡支付还是信用卡支付，当然，有些通道两类卡都支持。
银行，这是哪家银行的，招商、工行还是农行，因为像银行卡类交易或者付款，往往同行支付体验更好，成本更低，跨行的支付成本更高一些。

通过上述4个分组条件对通道进行分组，可以快速缩小要筛选通道的数量。不同的规则链可以选择对应的分组条件，如鉴权规则链，如果接的都是银联的服务，那么就不需要银行这个分组条件了。

5.5. 常见的筛选规则

在通道完成分组以后，那么就需要在剩下的通道当中进行更精细的筛选了。筛选规则就是指定通过哪些通道属性来过滤通道。比如，通道状态可不可用啊，需不需要报备啊，有没有白名单限制啊，营业时间到没到啊，有没有行业限制啊，这个商家有没有特别定制啊……其中，有些是通道的固有属性，例如有效状态；有些是需要进行加工计算的属性，列如本笔交易在某一条通道的交易成本。

经过一系列井然有序的筛选以后，能用的通道越来越少，最后几条筛选规则彻底杀死筛选。比如成本最低优先，会出现一个排序，除非有2条通道的成本一样，否则一般能选出唯一的通道。

如果最后所有规则都执行完了还没选出唯一的，还剩3条，怎么办？那么这个时候，要不就是你的路由规则设定有瑕疵，要不就是通道过于重复，这时候就需要优化路由规则链，比如对同类通道强制性增加一个优先级排序，当都满足时，谁最优先。常见的筛选规则有以下这些：

5.5.1. 通道状态

这是通道的固有属性，配置在通道信息中，一般是开通、关闭两个值，每次交易要过滤掉处于“关闭”状态的通道。

5.5.2. 营业时间

不管怎样，你得等别人开始营业才能去办理业务，也就是通道的营业时间维护，7*24小时的通道就不用说了，那些有固定营业时间的通道不是所有时间都支持交易的，比如人行的大额系统就有固定的营业时间。

5.5.3. 鉴权过滤项

在银行卡支付时，需要填写付款卡信息，用户填了多少决定了能走哪些通道，有的通道可能需要都填，有的通道可能不太严格；一般可以执行，必填必验，可填可验，必填不验。

5.5.4. 银行短信验证

有些通道会下发短信验证，有些通道不会，根据业务的诉求可能有些交易需要短信强验证，那么根据交易是否需要验证来过滤通道；如果你选了一个不会下发短信的通道执行一个需要进行短信验证的交易处理，那么通道就选错了。

5.5.5. 行业准入过滤

通道有时候也术业有专攻，有些行业的交易风险高，可能就不允许，所以需要根据交易的行业类型，过滤掉不支持该行业的通道过滤掉。

5.5.6. 签约过滤

有些通道需要用户的卡进行签约，没有签约的卡的支付便不支持。对于经过一系列筛选剩下的通道去看其需不需要签约，如果不需要那么就直接可用，留下该通道；如果需要签约并且不需要短信验证，那么也留下；如果需要签约也需要短信验证，那么就通过交易传进来的卡号判断该卡在此通道是否已经签约，如果没有签约，就过滤掉该通道。

5.5.7. 限额过滤

每一类通道都有限额，不是所有金额的支付都能走所有的通道。根据交易传进来的金额，和通道本身的限额区间进行比对，决定该通道是否可用。

5.5.8. 商户白名单

有些通道需要设置商户白名单，名单之外的商户的支付请求不能走该通道。通过交易传进来的商户编号来判断该商户在不在通道的白名单里，如果在则可以走该通道，如果不在则不能走该通道。

5.5.9. 通道卡黑名单过滤

有些卡比较奇怪，在某些通道就是支付成功率低，就是老出问题，那么就强制性把该卡种或者一张具体的卡添加到通道的卡黑名单中。只要是交易传进来的卡信息在某条通道的卡黑名单中，那么就不走该通道了。

5.5.10. 最少鉴权项优先

肯定是鉴权项越少越便宜，用户支付体验越好，支付成功率越高。所以，都满足的情况下，选择验证项少的通道，根据通道属性的验证项进行筛选。

5.5.11. 签约通道优先

优先选择那些需要签约的通道，这个可能不太好理解，不是签约就比较繁琐么，为啥要选需要签约的通道呢？

这个还是长远考虑，签约以后今后的支付体验会更好，更容易成功。

优先级最高优先：通过通道优先级这个属性对通道进行排序，选择优先级最高的通道。

通道优先级的设定一般根据通道的历史支付成功率、成本优势等等完成，优先级越高越说明通道质量越高，选择高优先级通道往往可以提高支付成功率降低支付成本。

比如同样是快捷支付通道，同类卡种，某些通道就是好，成本低，支付成功率又高，那么它的优先级就更高。

这个就像选择供应商一样，商品质量好、价格低、配货时效快，如果同一个商品多家供应商都能提供时，那你肯定优先选择该供应商。

成本最低优先： 支付机构肯定要赚钱，所以支付成本越低利润空间就越高。

那必然会选择成本最低的通道完成支付请求，根据通道的成本维护和交易传进来的金额，实时计算该笔交易走该通道的成本是多少。然后在剩下的通道中选择计算出的成本最低的那条通道。

当然还有一些其他的规则，比如商户定制、银行定制、行业定制、直联签约优先等等，可以根据实际的需求，设置更多的分组规则和筛选规则。不管怎样，无论多少规则基本逻辑都是一样的，就是通过交易特征去匹配通道特征或者进行某方面的优先性判断。

6. 基于规则的渠道路由设计

基于规则的渠道路由是最常见的设计。简单地说，就是符合什么条件就执行什么样的分流逻辑。比如：支付平台对接了网联和银联，招行信用卡全部走网联，工行信用卡500块以内的走网联，500块以上的走银联。

6.1. 核心流程设计

说明：

先进行唯一渠道判断，如果只有一条渠道，直接返回。
判断规则，如果规则没有命中，那就从可用渠道中随机挑选一条。
如果命中规则，再根据规则中的分流逻辑进行分流。
最后返回唯一的一条渠道。

6.2. 分流算法设计

如果一个请求既可以走银联，也可以走网联，还可以走直连，有以下几种情况：

没有命中任何一条规则，随机选择一条渠道。
有多条规则可以命中，选择优先级最高的。
命中的路由规则里，银联和网联分别是40%和40%，直连20%，根据规则分流。如果当前银联挂了，把银联按比例分配到网联和直连。

常见的分流算法是先把各渠道的分流比例换算成0-100区间的数字，从大到小排序，再根据用户ID取模、请求单号取模或生成一个随机数，再看这个数落在哪个区间，对应的渠道就是命中的渠道。

6.3. 路由规则配置模型

说明：

路由规则用于规则引擎运算是否命中。核心字段包括：规则ID、规则类型、规则表达式、优先级。实际实现时可根据各公司内部情况加字段。

1. 规则ID：用于分流配置做关联；
2. 规则类型：用于区分支付、实名认证等。
3. 规则表达式：用于规则引擎运算；
4. 优先级：用于排序，如果有多个规则都符合，以优先级最高的为准；

分流配置用于规则命中后，如何进行分流。核心字段包括：规则ID、渠道名、分流比例。

1. 规则ID：用于与路由规则进行关联。
2. 渠道名：表示要分流去的渠道。
3. 分流比例：说明有多少流量要分过去。

决策因子定义用于决策的条件。比如卡BIN，卡品牌，金额等。

6.4. 规则引擎选择

业务的规则引擎有很多，比如大名鼎鼎的Drools等，也可以选择自研，各公司可以根据自己的技术生态来选择。

我个人推荐QlExpress。推荐理由：简单实用。因为路由规则都非常简单，没有过于复杂的运算，不需要引入一些很重的规则引擎。

6.5. 决策子选择

决策因子就是路由规则匹配的条件，一般有以下几种：

金额：比如小于某个金额，或大于某个金额。
卡品牌：VISA、MASTER、UPAY等。
发卡行：CMB、ICBC等。
卡类型：借记卡、信用卡等。
卡BIN：某个号段的卡。
业务场景字段：各公司自定，比如线下场景，线上场景等。

6.6. 路由规则示例

规则的编写和规则引擎强相关。下面以QLExpress做个示例。实际落地时，需要根据自己选择的规则引擎做改造。假设：支付平台对接了网联和银联，要求：

招行信用卡全部走网联。
工行信用卡500块以内（不包含）的40%走网联，60%走银联。
工行信用卡500块以上的走银联。

一些基本的变量定义：

银行名称：bankName
支付方式：paymentMethod
卡类型：cardType
金额变量：amount
网联：NUCC
银联：UPAY
招行：CMB
工行：ICBC

定义规则：

规则1：paymentMethod='card' && cardType='credit' && bankName='CMB' 分流：NUCC：100
规则2：paymentMethod='card' && cardType='credit' && bankName='ICBC' and amount < 500.00 分流：NUCC：40，UPAY：60
规则3：paymentMethod='card' && cardType='credit' && bankName='ICBC' and amount >= 500.00 分流：UPAY：100

6.7. 界面配置示例

下面只是示意一个简单的路由配置。如果是多层次的与和或关系，需要产品经理做一些稍微复杂一点的界面。

说明：

示例规则的业务诉求：工行信用卡500块以内（不包含）的40%走网联，60%走银联。
后台保存的规则为：“paymentMethod='card' && cardType='credit' && bankName='ICBC' and amount < 500.00”，分流有2两条，分别是：“NUCC：40”，“UPAY：60”。
用于决策因子的元数据，需要提前定义好，包括这些字段的运算规则（比如开户行就不能使用大于、等于）。

6.8. 一些调优思路

用户最近支付成功记录优先，提高成功率。比如用户可以用银联，也可以使用网联，如果5天内最近一次使用了银联是成功的，那么为了成功率，可以考虑再次路由到银联去。因为从渠道风控的角度，已经成功的前提下，再次成功的可能性更大（余额不足除外）。
根据用户ID做分流，而不是当前订单号做分流，或者完全随机数。也就是使用伪随机。好处是同一个用户更大概率走到同一个渠道，有利于提高成功率，进而提升用户体验。
适当使用缓存，以提高运算速度。