在购物支付时，你有没有发现，这次的收银台提供的支付方式和上一次不一样了
这是什么骚操作
想了想，可能是自己换手机了，上次用的安卓手机，这次换苹果手机了，收银台多了一个苹果支付
同样，在我们进行超大额支付时，收银台所提供的支付方式也不一样了，这一点容易理解，毕竟有些支付方式本身能支持的限额就非常小
所以，一个平台是怎么实现收银台支付方式组合的多样化呢？
为什么同一个平台，支付场景不同，看到的收银台不一样呢？主要有以下几个原因
终端不同，支持的支付方式不同
最直接的，安卓手机里所有App都不支持苹果支付
就如微信支付分app支付、H5支付、小程序支付等等，所以不同的终端类型，单单微信支付就如此多样，所以难免在不同的发展阶段，不同终端能做到的支付方式也是有差异的
在H5应用里为了快速上架商用，可能初期就仅支持支付宝一种支付方式，微信支付、绑卡支付等其他支付方式稍微再接入
这样的安排，就会造成App内的收银台和H5内的收银台支持的支付方式不一样，如下图京东的pc端收银台仅支持银行卡和微信支付，相比其App端，少了很多支付方式
如果平台就2个终端，总共也就微信、支付宝、银行卡三种支付方式，那么收银台的展示完全可以在终端通过代码逻辑实现
商品不同，支持的支付方式不同
有时候用户选择的商品不同，也会造成支付方式的不同
举个例子，有些企业存在多条业务线，独立公司、独立团队运作，那么开通的收款商户号复杂多样，有的业务线可能压根就没有支付宝收款账号，那么收银台里怎么会有支付宝收款方式呢？
比如我们原来新上线了一款服务品类“做饭保姆”，做为早期的验证阶段，为了尽快上架，仅开通了微信支收款商户号，没有开通支付宝，那么针对做饭保姆这个品类用户就支付用微信进行支付了
这就是商品的不同造成了可选择的支付方式不同
支付场景不同，支持的支付方式不同
就比如开头的京东收银台，进行分次付款时，微信支付和数字人民币就不支持了
这就是不同的支付能力造成了支付方式不同，也可以认为是不同的支付场景造成了支付方式的不同
因为，不同的支付方式支持的场景是有限的
一些特殊的合作，造成支付组合不同
比如跟某些渠道达成合作，将50%的交易，让其放在收银台支付列表的第一位，会提供一定的手续费优惠，这种情况下，收银台策略发生了变化，不同的用户，或者同一个用户不同的支付，收银台支付方式排序不一样了
还有一些其他原因也会造成收银台可用支付方式不同，比如支付限额，当超大额支付时，明确超过了某些支付方式的限额时，那么就应该屏蔽或者置灰该支付方式，避免在后续过程中支付失败
我们前面介绍的支付方式是用户侧在支付时，收银台能看到的，常见的支付方式有微信支付、支付宝支付、云闪付、银行卡支付等等
用户能看到什么是由“前置路由”决定的，也就是我们本文重点介绍的，它决定了收银台的内容
还有一个路由是后置路由，也就是当用户选择了“微信支付”，并提交支付以后，后端如何决策这笔支付应该提交给谁
你可能会说，用户不是已经选择了微信支付么，肯定提交给微信侧啊
提交给微信没问题，但问题是，仅仅是微信么，或者只能是微信么？
别忘了有很多三方机构或者聚合支付支持微信支付这种方式，也就是我们可以通过多渠道实现“微信支付”
那这个时候，你就要想了，我怎么选择提交给那个微信支付？
这就是后置路由要解决的问题
它为每一笔支付选择最优的支付渠道，这部分我们在路由相关文章里有非常详细的介绍
因此
前置路由决定用户看见什么，渠道路由决定支付提交给谁进行处理
当然，用户看到什么样的收银台，完全可以靠代码把逻辑写出来，比如判断什么终端、什么品类，展示什么支付方式组合
但是，随着公司的发展，业务越来越复杂，终端种类越来越多，支持的支付方式越来越多，收银台支付方式组合的逻辑更加复杂
这时通过逻辑代码实现不再是一个好选择
因为，你不能频繁去调整非常重要的支付入口收银台的展示，不能因为一个小的策略变动，就把收银台代码改一遍，这肯定需要变革
那么就可以通过“收银台配置模版”实现
将平台支持的支付方式抽象出来，比如经过分析，共接入了下列的支付方式
这些支付方式由于开头的那些原因需要进行不同的组合和排序
每一种组合和排序都可以认为是一个收银台模版，而支付场景我们可以认为就是一组条件，有的是可以抽象和固化配置的条件，有的可能是需要逻辑和策略实现的条件
上图中每一条就是一个收银台模版，其配置决定了本次命中支持的支付方式，支付方式的排序等内容
应用不同支付方式不同，业务线不同、品类不同、交易类型不同支付方式也可以不同，我们甚至可以为某一个具体的用户或者商家提供个性化的支付方式组合
根据新的策略去配置新的模版，让收银台的丰富性变得更加灵活
从配置中可以看出，我们可以进行更加多样化的策略配置，可以配置支付方式的可用性，可以配置不同的排序，可以配置支付方式的推荐等等
只要有了这个框架逻辑，很多想法，都可以添进去
