编辑导语：路由系统能够基于支付通道的属性特点和业务系统的要求，为支付交易筛选出符合业务要求的最优的通道。本文作者从路由的架构、实现原理、规则等方面对路由的设计方法进行了分析，一起来学习一下吧。
基于支付通道的属性特点和业务系统的要求，为支付交易筛选出符合业务要求的最优的通道；简单地说就是业务系统要收款，你路由器帮我选一条最好的通道吧！这就是路由的职能，为通道选择做决策。
近期我要去三亚看海，找去过的朋友以及在网上了解怎么去比较划算和舒适；一个朋友告诉我，坐飞机比较好，用时短，还能看看天空的云；有的朋友说火车比较好，有足够的时间体验漫长和一路风景人文；还有的朋友说骑自行车比较好，既能锻炼身体又能一路吃遍南北……
当你有一个目的的时候，就会有很多条路放在你的面前，或者说，就算你没有目的，这些路都在哪里，只是等待一个时刻你去选择。
而我们选择都是有条件和依据的，比如我要时间最短，比如我要最便宜，比如我要风景最美，比如我要在那个时间段可以……当这些条件都满足以后，我决定我选择从北京骑自行车去三亚，你觉得合理么？
同样路由亦是如此，它是一个帮助你选择的管家，你告诉他你要干嘛，他告诉你走那条路，而这个过程你要提供给他足够的“要求”，比如我要成功率最高的，我要成本最低的，我要最稳定的，我还要……最后他告诉你，这是你要的，去吧。
支付路由就是这样，来了一笔支付请求要提交渠道，走哪条渠道呢？这个时候路由就问你“这笔支付什么特征”，你告诉它，这是工行卡支付的，北京的一位用户，是信用卡，在A商户买了一件衣服……路由开始选择，工行的那招商的通道就不用了，这是工行的所有通道；北京的用户，那河南的这条工行通道就不用了，这是所有北京的工行通道，A商户是vvvvvip指定了2条独家专用通道，而且今天其中一条休假，那就只能这条了……这样，我们就选出来了。
路由选择场景有2个，一个是收银台展示那些支付方式的路由，不同的用户，不同的商品组合可能用户要看到不同的支付方式以及排序；另一类是选择那条支付通道去提交用户的支付请求，根据支付的属性去匹配通道的属性，选择最适合该笔支付的请求。
如果你善于撮合爱情，那就大概率善于设计路由规则，因为路由就是撮合了支付对通道的爱。
对一个事物的认识我们先从整体去认识，会有利于需把控其中每一个环节以及细节，更可以让你对它有更强的控制力以及灵活能力；接下来我们从各个整体维度去认识和把握路由系统的设计。这将为今后其他子环节的设计打下基础，例如每个规则的设计，运营后台设计，通道返回码设计，对不同场景下的路由的设计演变等等。
通道的分类和特点：既然你要筛选某个群体，那你必然要知道这个群体的画像；路由是对通道的筛选，那么我们就需要知道通道有什么样的属性和特点，都有哪些类型的通道；当然不同的公司基于自己的发展需要可能对通道的分类方法不同，但关键是“你总归有一个属于你的分类方法”。
对于通道的认识可以看下下面的这篇文章：支付通道介绍和接入
1）支付类通道
这是我们非常清楚的通道类型，为支付的核心通道，也是支付指令提交的通道，种类和数量最繁多的通道，也是路由的核心筛选对象；对于支付通道我们又可以分出快捷通道、网银通道、代扣通道、垫资通道等等，当然对于一个普通企业来说，也可以按支付品牌去分，比如微信通道、支付宝通道、银行卡支付通道。
对用通道我们还要关注其支持的卡类型，谁发起交易，有无行业限制，交易需要的要素等等。
2）鉴权类通道
我们常听说的四要素鉴权，三要素鉴权，五要素鉴权，用户在绑卡支付时需要进行银行的鉴权，来判断卡的有效性；在结算卡绑定时同样需要通过鉴权去判断卡的有效性。
为了成功率、备份、成本考虑，一个机构也会接入多个鉴权通道，所以也需要基于鉴权请求路由出最有的鉴权通道。
3）实名类通道
对于一些业务场景需要进行实名认证，比如你要到一个家政平台去做兼职，你需要实名认证签约，就需要上传身份证照片，人脸识别等。
同理也会接入多条实名通道，需要进行路由。
那么我们常见的用于对通道进行分类或者筛选的通道属性有哪些呢？这些属性有些维护在通道管理，是通道的本身属性，有些是支付信息里是支付单据的内容？
在不同的行业，不同的公司，不同的业务模式，接了不同的通道矩阵的情况下，基于实际会设定不同的路由规则，这是个无限的过程，但是我们要掌握基础的方法，那就是“选择的艺术”，如果你懂了选择的逻辑，那么再复杂的事物，你都能选出最佳的那一个。
路由的目的是基于交易特征筛选最匹配的通道，所以这里我们就发现了关键。
交易特征就是你要知道用户发起的这笔支付的画像，什么类型的支付，用的什么卡，买的什么品类的商品，商户是谁等等。
通道就是上面我们讲的他也有他的画像，这个是什么类型的通道，支付还是鉴权，网银还是快捷，有没有行业限制，对公还是对私，成本如何等等。
然后就是匹配，通过什么样的匹配模型去将具有一定交易特征的支付匹配到可用的通道上，这也是路由的核心原理所在。
所以我们要对通道进行管理，维护全部通道的基础属性，就像你去一个婚恋网站去填一些资料一样，身高，体重，学历，有无特殊要求，便于系统帮你匹配最合适的人，也便于匹配到的人对你再次筛选。
然后就是路由的规则体系，我们知道匹配的时候关注什么内容，如何去执行这个规则条件；我们的规则可以分两类，一类是分组规则，另一类是筛选规则，并且对每一类规则我们都需要一个模块进行管理，比如成本最优规则，你就需要一个每个通道成本管理的地方去维护计费模式以及费率等，便于去计算本笔支付的通道成本。
这样我们就知道了路由的实现原理就是，交易将特征传入路由系统，路由系统针对每项规则去过滤已经维护的全部通道，直到挑选出最合适的那个。
调用系统比如支付网关、业务系统、支付系统等，传入交易特征，路由系统先根据规则树快速定位到可用通道，然后再通过一组筛选规则注意筛选，最终输出一条可用通道给到请求方。
对于路由的规则体系我们从三个方面去认识，规则的链条、规则树、规则组。
规则的链条就是为一个业务线，一个支付产品，甚至是一个商户设定一个路由规则集合，这个规则集合里规定了这个交易特征需要执行哪些规则，而这个规则链上我们可以分成规则树和规则组两部分。
规则树就是我们通过交易类型，卡类型等必传的交易特征，快速缩小通道范围，避免对全部通道执行没必要的规则判断，比如你是鉴权，那么就没必要去判断快捷类通道。
规则树就是设定几个固定维度作为快速筛选通路，可以快速定位到目标通道集合。
规则组就是将全部规则中挑选一部分规则用于这个场景的支付通道的筛选，例如通道状态过滤、行业准入、营业时间、黑白名单、成功率最高、成本最低等。
这个规则组包含：筛选规则、执行顺序。
规则组执行的逻辑
通过分组规则我们得到了一个通道组，如上面我们选出3条通道“通道A、通道B、通道C”，最终我们要选择一条通道，所以还需要进一步做筛选，这时候我们就用到了筛选规则；假如我们设定了3个属性做筛选“状态，商家报备，成本优先”，这3条通道属性如下：
假设商家已经在A通道做了报备，所以整个筛选流程模型如下：
我们知道案例中入参应该是3条通道：通道A、通道B、通道C。
通过筛选后，因为C关闭了被过滤掉，我们得到了2条通道：通道A、通道B，因为有下一条规则，所以我们继续往下走，报备规则的筛选，这时候流程图如下：
因为商家已经报备了A通道，B通道不需要报备，所以，经过这个筛选，我们依然得到两条通道通道A，通道B，因为有下一条规则，所以我们继续往下走。
成本最低优先规则的筛选，这时候流程图如下：
经过这个筛选，在A和B通道对比中，B的成本最低，所以最终我们得到了一条最优的通道：通道B。
路由一般有业务系统调研，比如实名认证时可以有用户中心调用，绑卡鉴权时可以由钱包调用，用户发起支付跳转收银台或者支付方式列表时可以由交易系统调用，提交支付筛选通道时可以由支付系统或者支付网关调用。
路由的产品系统架构
通过上面的介绍，路由系统的产品架构基本已经比较清楚了，因为我们知道了路由在支付体系流程里的空间位置，又知道了路由系统的原理以及包含的内容模块，将这些封装起了就可以得到我们的路由系统的产品架构了。
到一个平台去购买东西，提交了订单以后会到达收银台页面，这时候按照自己的喜好去选择一个支付方式，进入支付流程。
其中我们要回想一下，同样在京东，你每次购物，收银台展示的支付方式个数以及排序都一样么？
再想另一个问题：同一个时刻不同的人看到的收银台支付方式情况都一样么？
答案显然是各不相同，这就是我们今天要介绍的“展示路由”，它决定了用户在支付时能看到什么支付方式以及如何进行排序。
京东-饿了么-美团
这必然是随着平台不断的发展，积累了更复杂的场景和多样化需求造成的，就像你刚刚成立一个电商平台，在用户很少，商品很少的情况下，加上技术人力不足，可能期初其需要微信和支付宝两种方式就行了；随着大额交易越老越多，你们又上了一个预充值余额支付，那这样如果没有开通的用户其实就不需要展示给他余额支付方式；当然如果你想让更多用户使用余额支付，你可以增加开通余额账户的引导，或者默认所有用户都自动开通余额账户，只不过余额是0。
1）收银台的个性化展示
我们可以从以下几个方面去分析，当然还有很多种其他原因，归根结底都是因为多样化业务诉求的产生。
2）支付方式多样化
随着平台的发展，为了迎合更多场景及用户，会签约更多的支付渠道，从微信支付宝，到银行卡支付，苹果支付，再到银联闪付，数字人民币支付，余额支付等等，多样化的支付方式就必然对收银台的展示策略提出了更高的要求。
3）业务的多样化
有了丰富的支付渠道之后，其实业务多样化同样也会影响支付方式的展示，比如有些渠道拒绝某些品类的支付请求，所以如果用户选择了这中品类下的商品，那收银台就不应该展示不接收该类商品交易的渠道支付方式。
4）商户需求的多样化
随着商户数量的增加，种类的增加，合作模式的增加，对支付渠道的要求，甚至是收银台的要求也会相应增加，比如有些ka大商户因为跟某些渠道有合作，可能就会要求仅支持某几类支付方式，这样就需要根据大商户的特殊要求设定支付方式。
5）平台诉求的多样化
平台本身也会有营销等各种诉求，AB实验的诉求等，也会对收银台的个性化提出要求，比如某些用户优先推荐微信支付，某些已经绑了银行卡的用户优先推荐银行卡支付等。
6）渠道合作的多样化
有些渠道可能会提供一些合作模式，比如你把我放在第一位我就给你降费率，或者更有甚者，你把竞品折叠，我再给你降一些费率，而这种合作模式又可能不是全量用户，比如你要将50%的交易采用这种收银台模式。
7）用户习惯的多样化
用户体量足够大时，你就不得不考虑更好的用户习惯和体验的诉求，比如有些用户每次购物都是用微信支付，那么下次支付你要是推荐了支付宝而折叠了微信，那必然会让用户多操作几次去找到自己想要的支付方式；而如果有些用户上次使用了银行卡支付，那么下次推荐上次用的卡可能是一个不错的选择。
8）渠道营销合作
有些银行渠道可能会提供一些支付补贴，这也会成为支付方式个性化的需求来源，但是这种营销又可能不是全量用户，所以这里又需要策略问题。
所以说，收银台个性化展示的目的有时为了更高的成功率，有时为了提高用户体验，为了给某一个支付渠道引流等不同的诉求，但最终实现的业务效果就是不同的人可能看到的收银台页面的支付方式的种类和顺序会有差别。
那么从产品上我们该如何实现收银台的个性化展示诉求呢，这里就是我们今天要介绍的：展示路由，觉得用户在收银台看到什么支付方式，以及支付方式如何排序的问题。
诉求清楚了，那么去满足这个诉求就容易了，不同的公司，不同的诉求的组合，必然有不同的解法；通道的多少，展示策略的场景复杂程度都会影响设计的复杂程度，但是我们简单介绍集中常见的手段。
1）固定配置
如果公司业务没那么复杂，签约的支付渠道不多，个性化求很容易枚举，那么可以通过配置后台实现，穷举个性化场景，得到收银台模板，根据传入的交易特征匹配相应的模板即可以得到收银台展示规则；如果交易特征传入了快车，并且是在8-11点的高峰时段，那么我们就调用智能路由执行更复杂的算法而不指定支付方式。
2）个性化策略
当我们的交易有更多的特征，业务有更多的诉求，支付渠道有更多的合作模式，业务场景更加复杂时，可能枚举配置模板就不是一个好的选择；我们就需要采用更加复杂和灵活的策略化路由能力了。
比如信用极好的用户推荐白条金条的路由策略，已经绑卡的用户优先推荐有支付别贴的银行卡策略。
苹果用户优先推荐苹果支付，安卓用户优先推荐微信支付，pc用户优先推荐微信扫码，大额支付优先推荐线下支付。
618期间，全部用户优先推荐微信免密支付，次推荐微信支付等等。
我们枚举策略场景并进行分层，通过一层层的策略选择出最佳的收银台支付展示结果。
3）定制化设定
有些特殊品类或者大客户可能需要特殊的支付渠道或者支付方式，那么既可以定制特殊的收银台，比如选择企业，需要直接跳转到该企业提供的收银台去完成支付，这时候就需要为该商户配置指定的收银台链接了。
业务有业务的诉求，产品有产品的实现方法；只要是明白了业务诉求，就一定有解法，如果把产品实现作为底层的黑匣子，那么唯一知道的就是，相应的场景用户得到了期望的支付方式列表以及排序；所以展示路由解决的核心问题就是实现“你想看到的和想让你看到的”。
经验的使命是收敛于方法，方法的归宿必然收衍生出更多经验。
互联网发展了这么多年，每家公司都是从0慢慢沉淀成长起来；这么多的“厂”的支付体系各有千秋，可以说都是适合自己的“个性化定制”。
我经历过几家不错的公司，以及跟很多朋友交流大家所在公司的支付体系，总的来说“都能用，但都一般”，都能用是都可以支持自己家的业务，也挺好，都一般我想就是上面说的，大家都是摸着河过来的。
当初第一个设计的人的水平决定了起点，中间的众多参与者的水平决定他的发展。有的有幸遇到几位水平不错的产品经理，被一次次升级重构越来越好，没有长歪；有的可能不太幸运，越长越歪，以至于后来的很多优秀的产品经理都无法修正。
所以我的经验里告诉我，互联网世界里不要去相信权威，本身也没有权威，只有“虎威”，权威是它的知识的专业性，虎威是它业务的地位。
我们为什么相信“支付宝的支付体系优秀”，我想更多是因为“支付宝的业务优秀”，所以我们才相信他的支付体系也优秀。这之间也没有必然的联系，但是这么庞大的业务体系，必然会反向促使他的支付体系更加完善，更加普世，更加值得借鉴，因为他打过很多胜仗，但系统设计方法和理念并不绝对的一定比一家小公司好。
所以对于支付知识体系的建立，我更喜欢“立足当下的实用去抽象可复用的方法”。
大家各不相同，但其中有通行的方法可行，可被抽象，可被复用；在通行的方法下，也大概率可以设计出更优秀的支付系统，因为他的理念至少可以涵盖曾经的“经验体系”。
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；天使投资人；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。