路由系统：支付的智能指路牌
通道是原材料，路由是菜谱。没有原材料做不了菜，光有原材料没有菜谱也做不出好菜。路由系统是支付核心中的核心，它决定了每笔交易走哪条路、用户看到什么支付选项、成本能压到多低。
老王的三条管理法则
老王的连锁店越开越大，遇到了三个管理问题：
店越来越多：不同地区、不同级别的店，客户偏好的商品不一样。老王把全国的店按地区分区、按级别分类，设计了多套模板，新开一家店直接套模板就行。
订单越来越多：收银台排队太长客户就走了。老王规定排队超过一定人数就必须新开收银台分流。同时为每类供应商准备多家备份。
供应商越来越多：有因为关系好合作的，有因为价格低合作的，有出于备份考量合作的。老王定了三条策略：先保证每个供应商的最低进货量，然后看谁成本低找谁，如果有供应商贴补营销费用就走指定供应商。
这三条法则，就是路由系统的核心思想。
路由系统做什么
路由系统是支付核心系统，通过引导路由和交易路由，实现支付成功率、收益率、用户体验满意度和支付安全度的收益管理。
简单来说，路由做两件事：
- 引导路由：决定用户看得到的——每个商户展示哪些支付品牌、怎么排序
- 交易路由：决定用户看不到的——每笔交易走什么通道
引导路由：千人千面的支付列表
引导路由由三个模块构成：品牌列表 → 引导方案 → 引导规则。
品牌列表
配置各个支付品牌的排列次序和营销文案。比如工行信用卡排第一，农行信用卡排第二，工行旁边标注”满 100 减 10”的活动文案。
品牌列表是个全集，但不代表用户最终看到的就是全部。
引导方案
设置哪些支付方式可用、推荐高亮哪个、常用卡策略是”最近使用优先”还是”成本优先”。最终展示给用户的支付方式是方案中配置的支付方式与品牌列表的交集。
引导规则
根据行业类型、商户号、接入方式（App/H5/Web）、交易类型、交易币种等条件，匹配对应的引导方案。还支持按权重输出多种方案，用于 A/B 测试。
举个例子：餐饮行业的商户统一用模板 A（微信在前、支付宝在后），但某个和支付宝有战略合作的大商户单独配模板 B（支付宝在前）。新商户接入时自动归入行业模板，无需额外配置。
交易路由：四种算法找最优通道
交易路由按算法优先级分为四层：
1. 基础路由算法（最底层，但最重要）
根据商户行业、交易类型、支付品牌、金额、限额等条件，匹配可用的逻辑通道，计算手续费成本，输出成本最低的通道。
物理通道是实际的通道实体（如银联通道、招行直连通道），逻辑通道是把物理通道按不同属性拆分后的配置规则。一个物理通道可以对应多个逻辑通道。
为什么基础路由是按行业而不是按商户配置？因为行业可能就几十个，而商户是不计其数的。每天接入上万家商户，只要归到对应行业就能自动匹配路由规则，实现轻量化运营。
基础路由中的手续费计算：
- 单笔手续费：不分金额，一笔固定多少钱（常见于代扣通道）
- 百分比手续费：按交易金额的百分比收费（常见于快捷通道）
- 包年手续费：一年固定总费用，配置成本为 0，应走尽走
- 阶梯手续费：不同金额区间对应不同费率
- 封顶手续费：手续费有上限，不管金额多高都不超过
举例：一笔 5 万元的交易，通道 A 按笔收费 1 元，通道 B 按 3‰ 收费（150 元）。基础路由会选通道 A。但如果是 2 元的交易，通道 A 还是 1 元，通道 B 不到 1 分钱，这时候选通道 B 更划算。
2. 分组路由算法（效率优先，兼顾公平）
把多个通道分成一组，在组内按保量金额或权重比例分配交易。目的是维护合作关系——不能”有事钟无艳，无事夏迎春”。
分组路由会进行分布均衡算法：根据两边未完成度进行分配，谁未完成度高分配给谁。避免出现通道 A 只有 0 点到 1 点有交易、通道 B 只有 1 点后有交易这种人为操作痕迹明显的情况。
如果同时有组内和组外通道可用，组内筛选出的最优通道还要跟组外通道比成本，最终输出全局最优。
3. 短路路由算法（指定通道，优先级最高）
不看费率、不看分组、忽略其他规则，直接走指定通道。适用于三种场景：
- 营销补贴：银联出了营销活动，虽然费率不低但用户体验最好
- 新通道验证：新通道上线先让部分商户试水
- 战略合作：某大商场要求只能用它的通道
短路是优先原则，如果短路通道不可用，会回退到基础路由和分组路由。
4. 风险路由算法（安全第一）
根据风控系统返回的风险等级匹配通道：
- 高风险：直接拦截，让人工介入
- 中风险：路由到支持中风险交易的通道（如包赔通道），下发最大验证要素集合
- 低风险：视为正常交易，按其他路由规则处理
算法优先级：风险路由 > 分组路由 > 短路路由 > 基础路由。
路由调用的三个时机
事前路由
用户发起支付前，支付平台向路由请求”展示什么支付方式、需要什么要素”。绝大多数公司都做了事前路由。
事中路由
用户输入卡号后发现当前通道不支持这个卡 BIN，或者选了护照但当前通道只支持身份证，系统在用户无感知的情况下重新请求路由，换到支持的通道。
不做事中路由的后果：用户输入卡号→交易失败→提示换卡→用户没有其他卡→放弃购买。
做了事中路由：用户输入卡号→系统发现当前通道不支持→自动切换到支持的通道→用户无感知完成支付。
一个真实的痛点：护照作为姓名时，由于不同银行柜员录入习惯不同，同一个名字可能有几十种排列组合（大小写、空格、姓名顺序）。解决办法是优先路由到不需要姓名的通道。
事后路由
支付失败后，根据通道返回码判断是否可以重试。比如通道返回”超限”，这不是用户的问题，可以自动切换到另一个通道重试。这就是下一篇要讲的重试服务。
通道健康度：自动熔断
路由系统还负责通道的健康管理：
- 高并发分流：根据通道 TPS 容量，满负荷时自动切换到次优通道
- 不良通道自动熔断：通道维护时自动下线，通道成功率低于阈值时自动降权。注意这里是通道交易处理成功率，不是客户支付成功率——余额不足导致的失败不算通道问题
- 路由系统故障托底：路由整体不可用时，前台网关输出事先配好的一套最小可用方案
路由规则怎么发布
路由配置复杂，一个操作失误就可能导致交易无法成功。所以发布流程是：录入 → 批量提交 → 批量审核 → 批量发布 → 生效。
发布后每个版本都有批次号，支持版本回退（生产规则回退到某个历史版本）和数据同步（后台配置数据更新为某个版本）。
路由规则不建议直接写在代码逻辑里，因为支付通道多、商户多、维护频繁，需要配置化管理和专门的运营人员。
路由系统通过四种算法和三个调用时机，在成本最低、合作关系稳定、通道可用、交易安全之间找到最优解。下一篇我们来看两个提升支付成功率的精细化工具：重试服务和 BIN 服务。