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