适用于中小支付机构的路由设计
一、背景介绍
对于中小规模的支付公司来说,早期支付业务都是频繁对接银行渠道的。 由于各种因素的影响,商户质量参差不齐,银行渠道的服务质量更是参差不齐,支付公司不得已以渠道数量来弥补质量的不足,跑挂一条换一条,胜在放接口的银行足够多。
为了分摊单个真实商户质量不高带来的风险,支付公司可以向银行渠道进件多个商户,得到多个渠道侧商户号,构建商户池,以一定的条件策略,将一个商户的交易分摊到多个渠道侧商户号上,以达到让每个渠道侧商户号可能造成的风险较小,都在无法触发银行渠道银行风控规则的目的。 即便一部分号因风险问题,被关停了,商户池中的其他号依然可以继续让商户跑交易,胜在部分银行渠道下号很容易。
这便是在那个时代,最适合中小支付公司的业务思路。
二、支付路由定义
路由就是路牌,作用就是指路。 支付路由是由渠道、交易号、商户池和商户配置这些主要模块和一系列由具体业务决定的选路/选号策略组成的逻辑。
注意, 我们这里介绍的支付路由,是更偏向于由业务运营配置的人工路由,8分人工,2分自动。
三、支付路由基础逻辑
支付路由模块基础逻辑,如下:
- 筛选步骤:支付路由是在商户池内完成选交易号的;交易号指的是交易用的渠道侧商户号。通过选中交易号会同时得到渠道信息。
- 筛选规则:要给商户-支付方式-支付类型配置指定的若干个商户池,在交易的时候会通过对应的商户池找到用于交易的入驻号。
- 筛选结果:通过对渠道、交易号、商户池和商户配置四个模块设置相应的属性,来决定在商户池中选号时,哪个号能用,哪个号不能用。
四、属性
4.1 通用属性
关于各模块的属性,通过给渠道
、交易号
、商户池
配置像日交易限额
、单笔限额
、服务时间
等这些主要的属性, 可以在交易时间
、交易金额
和每日累计交易金额
这几个维度,组合出非常灵活的策略。
示例:
渠道A说这条渠道每天只能承受1000万特定类型的交易,每个商户每天能承受的交易量按商户类型不同,有着不同的日累计交易额限制:
- 餐饮商户每天只能跑20万,但每笔限额在500以内;
- 零售商户每天可以跑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: 这就要搞清楚单卡单日的交易次数是在渠道层面限制,还是在渠道侧商户号层面限制。如果是渠道限制机构单卡单日的交易笔数,那你就做在渠道层面,如果是限制每个商户单卡单日,那你就坐在交易号层面限制,这个做在商户层面,基本没什么用。
补充
本次以文字分享为主,但起到的只是举例的作用。
这个支付路由逻辑的核心,就在于交易时,在商户池中根据当前交易的实际情况,选择一个交易号(渠道属性都符合的交易号)。
注:
- 只要在这个框架下,举一反三的往渠道、交易号、商户池这几个主要模块中,加入交易金额、交易时间、交易卡银行、卡类型等属性的统计功能,就可以灵活的满足各类收款交易的场景。
- 百变不离其宗,当然这个路由逻辑似乎不是很适用于代付业务。
了解更多支付路由设计
支付路由设计入门,参考: 支付路由设计
以下是在本群中分享过的支付路由设计
本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。
原文转自:https://mp.weixin.qq.com/s/zzKuoIJbUk1GtAngL2w3Vg