一、背景介绍

对于中小规模的支付公司来说，早期支付业务都是频繁对接银行渠道的。由于各种因素的影响，商户质量参差不齐，银行渠道的服务质量更是参差不齐，支付公司不得已以渠道数量来弥补质量的不足，跑挂一条换一条，胜在放接口的银行足够多。

为了分摊单个真实商户质量不高带来的风险，支付公司可以向银行渠道进件多个商户，得到多个渠道侧商户号，构建商户池，以一定的条件策略，将一个商户的交易分摊到多个渠道侧商户号上，以达到让每个渠道侧商户号可能造成的风险较小，都在无法触发银行渠道银行风控规则的目的。即便一部分号因风险问题，被关停了，商户池中的其他号依然可以继续让商户跑交易，胜在部分银行渠道下号很容易。

这便是在那个时代，最适合中小支付公司的业务思路。

二、支付路由定义

路由就是路牌，作用就是指路。支付路由是由渠道、交易号、商户池和商户配置这些主要模块和一系列由具体业务决定的选路/选号策略组成的逻辑。

注意，我们这里介绍的支付路由，是更偏向于由业务运营配置的人工路由，8分人工，2分自动。

三、支付路由基础逻辑

支付路由模块基础逻辑，如下：

筛选步骤：支付路由是在商户池内完成选交易号的；交易号指的是交易用的渠道侧商户号。通过选中交易号会同时得到渠道信息。

筛选规则：要给商户-支付方式-支付类型配置指定的若干个商户池，在交易的时候会通过对应的商户池找到用于交易的入驻号。

筛选结果：通过对渠道、交易号、商户池和商户配置四个模块设置相应的属性，来决定在商户池中选号时，哪个号能用，哪个号不能用。

四、属性

4.1通用属性

关于各模块的属性，通过给渠道、交易号、商户池配置像日交易限额、单笔限额、服务时间等这些主要的属性，可以在交易时间、交易金额和每日累计交易金额这几个维度，组合出非常灵活的策略。

示例：

渠道A说这条渠道每天只能承受1000万特定类型的交易，每个商户每天能承受的交易量按商户类型不同，有着不同的日累计交易额限制：

1、餐饮商户每天只能跑20万，但每笔限额在500以内；

2、零售商户每天可以跑80万，单笔不限额。

但是建议餐饮商户只在7-9点、12-14点、17-20点交易，零售商户在全天都能交易。如果不符合渠道的要求，则可能触发风控系统。如下图：在这种情况下，我们该如何配置属性？

配置规则：

一笔交易过来，先从商户池中随机选出一个交易号；通过用当前的交易时间、交易金额对比商户池、交易号和渠道的既有属性，包括日交易限额-日交易累计额=交易金额、交易金额在单笔限额范围内、交易时间在服务金额范围内，如果全部能满足，则这个交易号可以用；路由便返回这个号对应的交易密钥、支付渠道等信息，以完成交易。

如果未全部能满足，则重新随机选一个商户池中的交易号，再做属性判断，以此类推。

4.2渠道属性

除了上面介绍的那几个通用属性外，还有一些特定业务类型的特别的属性。比如说快捷支付业务，每个渠道支持的交易卡银行、对应的卡类型，以及不同银行卡类型对应的费率都不尽相同。我们可以给渠道设计一个支持银行的属性，其中还包括卡类型和成本费率，如下图：

这样，在商户池属性中，我们可以添加一个“排序逻辑”下拉项，选择“成本优先”来决定这个商户池内的交易号，是否需要按照成本优先排序，再在成本最优的交易号中随机选择可用的交易号。

4.3交易号属性

除了上面介绍的那几个通用属性外，我们还可以在交易号属性中，加入地区编码、行业编码两个属性，给每个交易号定制一个特定的地区编码和行业编码，在商户池中选号时，通过筛选这两个编码，来实现现在某行业里需求很高的商户落地``功能。

4.4商户池属性

除了上面介绍的那几个通用属性外，在商户池属性中，我们还可预设商户池最低成功率，在商户池A的成功率低于某个预设值时，自动给该商户切换到商户池B，这需要交易程序侧在得到渠道的交易成功通知后，通知路由，统计交易已成功笔数和金额。还能通过预设最小贷借差额和最大贷记占比，来限制商户池交易的借贷比。

五、商户配置

路由应当支持多种业务。在路由设计中，我们可以将业务分成两级：

第一级叫做支付方式（如微信）；

第二级叫做支付类型（如扫码、刷卡、公众号、H5、APP）。

给每个支付类型配置一个或多个商户池，然后配置好上述三大模块的属性，就可以在第一个商户池完全无法使用时，自动切换到第二个商户池，继续交易。

Q&A

Q:请教一下，路由是否会考虑针对用户选择通道？

A:会的，多个商户可以各自配置独立的商户池，也可以构建公共的商户池，多个商户用同一个大池。我上面描述的“特定业务类型”，你应该能理解是什么，所以每个商户都会配置商户池，商户池里可能是一个号，也可能是很多个，这些号可能是来自一个渠道，也可以是来自多个渠道，这些号可以根据成本费率排序，根据优先级排序，只要满足属性，就被选中，

Q1:我只是在考虑如果池里面商户号比较少，会不会限制同一个用户的交易？

A1:可以限制。有个概念，叫做实名交易和非实名交易，大致的意思就是，实名就是一户一报，非实名就是商户池。我刚才发的图里，交易号属性中，我写了一个“允许交易的商户号”，就是规定了这个交易号在商户池中，只允许特定的商户去使用，变通一下，这个属性可以变成“商户号1,商户号2,商户号3”这样的形式，去让一个交易号允许多个指定商户去使用。

Q2:银联二维码支付是在支付之后才知道卡信息的通道，如果避免单卡交易次数过多问题，那这类交易怎么来选择呢？

A2:很简单，根据银联对机构的限制规则对商户进行限制。银联会在统计后，给支付公司发警告邮件，那我就在交易结果通知、交易查询这些接口的返回值里，把当前交易的交易卡的交易次数，笼统的分为紧急次数上限的警告状态、已经超过次数上限停用状态，返回给商户；也就意味着，只要大商户收到了警告状态，就要立即警告小商户，在支付公司停掉大商户银联二维码业务前，停掉小商户的业务，一级一级的将警告状态传递下去，如果不存在大商户，那就直接警告商户，当商户触及某张卡次数上限时，就暂停商户的银联二维码业务，直到商户提供书面说明，支付公司才重新恢复商户的银联二维码业务。只要商户会担心由于单卡单月交易次数超限，而导致支付渠道业务被暂停，而造成业务的停滞，自然就会将接近次数上限的警告传递给自己的用户，不过这些内容，已经不是路由的范畴了。

Q3:这个算风控吗？

A3：算，只是事后风控。

Q:那这商户池就是为了跳码使用？

A:跳码只是一个功能，最重要的是“平摊风险”，避免触发渠道的风控规则。

Q:大多数渠道都会限制单卡单日的支付次数，请问这个配置项是在商户池还是交易号？

A:这就要搞清楚单卡单日的交易次数是在渠道层面限制，还是在渠道侧商户号层面限制。如果是渠道限制机构单卡单日的交易笔数，那你就做在渠道层面，如果是限制每个商户单卡单日，那你就坐在交易号层面限制，这个做在商户层面，基本没什么用。

补充

本次以文字分享为主，但起到的只是举例的作用。

这个支付路由逻辑的核心，就在于交易时，在商户池中根据当前交易的实际情况，选择一个交易号（渠道属性都符合的交易号）。

注：

只要在这个框架下，举一反三的往渠道、交易号、商户池这几个主要模块中，加入交易金额、交易时间、交易卡银行、卡类型等属性的统计功能，就可以灵活的满足各类收款交易的场景。

百变不离其宗，当然这个路由逻辑似乎不是很适用于代付业务。

本文档来自“支付产品技术交流群”的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自“支付产品技术交流群”的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。