整个交易过程中有很多节点，有交易系统提交请求给支付系统，收银台暂时还未展示的节点；有在收银台界面输入支付要素的节点；有输入完成支付要素，提交整个订单的节点。在这些节点，支付系统前端都会与路由系统进行交互，以保证支付的高可用，从而不断提高支付成功率。我们将这些不同交易节点与调用支付路由的关系分别称为事前路由、事中路由和事后路由。
1、事前路由
事前路由是用户发起支付，支付平台为了向用户展示支付方式、银行、输入要素而向路由系统发起请求的过程。前文已经介绍了如何调用路由服务以及路由服务有哪些算法与功能，这里不再整述。绝大多数公司都会做事前路由，但这还不够，会带来些问题，我们将在介绍事中路由和事后路由时进一步说明。
2、事中路由
事中路由是指在支付交易过程中，用户输入卡号、护照等支付要素，支付平台根据输入要索进行判定，若事前路由下发的最优通道不支持此交易（如不支持此卡BIN或者证件类型），会再次请求路由服务，获得支持此要素的支付通道的处理机制。绝大多数公司只做了事前路由，甚至只做了路由中的基础路由，这样仅仅能够解决能用的问题，要想不断提高支付成功率，就需要做事中路由。
图1展示了平台支持的支付品牌，选择后会进一 步展示需要的支付要素。但因为每个通道支持的卡BIN不一致，支持的证件类型也不一样，如果只有事前一次路由，就会出现问题。比如用户输入卡号后，若最初下发的通道不支持用户所输入卡号的卡BIN；又如最初下发的最优通道只支持身份证，而用户要使用护照；这些场景都会造成支付失败。
对于上述情况，大致有以下3种可能的应对方法。
方法一：提示用户换卡。但也许用户并没有其他银行卡，想换也换不了；也许其他银行卡用的证件也是护照，换了也没用。另外，不管换了后是否成功，都会影响用户体验，因为支付时间变长了。
图1 收银台支持银行列表
方法二：不管不问，直接将交易提交到支付通道。最终结果就是产生大量的支付失败和报错提示。用户自己根据报错提示，了解到要换卡；或者不停打电话给平台或银行的客服，询问为什么支付会失败。
这样不仅会影响用户体验，支付成功率也会下降，而且用户还可能陷入死循环，比如用户一直输入护照号码尝试支付，虽然每次输入的要素都对，但系统一直报错“卡信息有误”。
方法三：将交易转移到支持此支付要素的通道。在支付过程中，如果已经识别卡号不支持或者证件类型不支持，那么最好的办法就是找到支持的通道，并且在用户无感知的前提下替换掉原有通道。至于实现，这就是事中路由要做的。
事中路由如何提高支付成功率？图2所示为用户选择某个支付品牌后平台展示的需要的支付要素，下面从卡BIN、证件类型、姓名三个支付要素出发，阐述如何提高支付成功率。
图2 支付要素填写页
支付要素一：卡BIN。
用户输入卡号后，系统要判定通道是否支持这个卡号，其实就是判定通道是否支持这个卡号的卡BIN。前文介绍过，同一个支付品牌可对应多个支付通道，但每个通道支持的卡BIN并不完全一致，也并不能支持某发卡行发行的全部银行卡。如果只有事前一次路由，就会带来一些问题。
由于事前路由的时候并不知道用户卡号，只能假设通道支持该支付品牌的所有卡BIN ，根据路由各模块优先级筛选出最优通道。比如用户输入卡号后，支付平台发现最初下发的通道不支持用户所输入的卡BIN，如果继续提交支付，会支付失败，只能提示用户换卡。甚至会让用户陷入死循环，用户不仅无法支付成功，而且不知道原因，这样既影响支付成功率，也影响业务的成交。
如图2所示的界面设计，卡号在第一行（在有的App中，卡号甚至单独占一个页面），用户往往先输入卡号，这样的设计背后是有逻辑处理原因的。用户输完卡号，会针对卡号进行校验，判断此卡号路由下发的最优通道是否支持，如果支持则继续按照原有流程进行，如果不支持，会去找支持此卡号的通道。如果找到支持的通道，页面要素会换成此通道需要的要素。如果没有支持的通道，那么就直接提示“用户暂不支持该卡，建议更换其他银行卡”，不让用户再继续下去了。这样的机制可解决卡号不支持问题。
支付要素二：证件类型。
支付要素中证件类型不仅有身份证，还有护照、兵证、回乡证、台胞证等。在支付中如果下发的最优通道不支持用户所选的证件类型，就需要事中路由进行再次路由，找出匹配的通道，从而避免用户因证件类型不被支持而无法完成支付。
为了避免前台进行无效请求，路由系统也会在事前路由阶段将下发证件类型分为两个字段：当前通道支持证件类型，其他通道可用证件类型。当前通道支持证件类型指的是下发的最优通道支持的证件类型，其他通道可用证件类型指的是支持当前交易的其他通道的证件类型全集。
例如，某交易有A、B、C三个通道可用，A通道支持证件类型为身份证，B通道支持证件类型为护照、身份证，C通道支持证件类型为护照、台胞证，那么事前路由下发参数时，就会下发类似如下结果：
最优通道为A通道，当前通道支持证件类型为身份证，其他可用证件类型为身份证、护照、台胞证（B+C证件类型的全集）。这样用户在选择不同的证件类型时，前台就会知道通道是否支持，是否需要直接提示用户换卡等，从而避免无效请求路由，提升效率。
还是用例子来说明，假设交易背景如下。
·用户选择招商银行信用卡，交易类型为消费。
·用户办理招商银行信用卡时用的证件为护照。
·路由系统规则有基础路由、按成本进行路由和风险路由。
·有A、B、C三个通道支持此交易：A通道支持证件类型仅为身份证，成本最低；B通道支持证件类型为护照、身份证，成本中等，仅适用于低风险交易；C通道支持证件类型为护照、台胞证，成本高，适用低风险、中风险交易。
交易时路由场景节点和结果如下。
场景一
背景：户进入支付收银台，选择招商银行信用卡。
路由阶段：事前路由。
风险等级：低风险。
路由结果：通道A。
原因：成本最低。
场景二
背景：用户选择证件类型为身份证。
路由阶段：事中路由。
风险等级：低风险。
路由结果：通道A。
原因：成本最低，事前路由下发的最优通道A支持该证件类型。
场景三
背景：用户选择证件类型为护照。
路由阶段：事中路由。
风险等级：低风险。
路由结果：通道B。
原因：事前路由下发的最优通道A不支持该证件类型，B通道和C通道均支持，但B成本更低。
场景四
背景：用户选择证件类型为护照。
路由阶段：事中路由。
风险等级：中风险。
路由结果：通道C。
原因：事前路由下发通道A不支持该证件类型，B通道和C通道均支持该证件类型，但只有C通道支持中风险交易。
场景五
背景：用户选择证件类型为临时身份证。
路由阶段：事中路由。
风险等级：低风险。
路由结果：不调用路由，前台直接返回用户“暂不支持该证件类型”。
原因：事前路由下发的其余可用通道证件类型全集均不支持临时身份证。
支付要素三：姓名。
在银行柜面办理银行卡时，护照的姓名录入方式为字母。但由于不同地区、不同阶段历史、不同柜面办理人员存在差异，以及历史上对于姓名英文录入规范的缺失，导致同一个姓名用字母录入后的结果多种多样，这会带来一些问题。下面以中国用户WANG XIAO HAN为例来说明。
1）大小写问题。有的系统对姓名是首字母大写，有的是全部大写，有的是全部小写。对于用户WANG XIAO HAN，系统就会存在WANGXIAOHAN、WangXiaohan、wangxiaohan等样式。
2）空格问题。在录入姓名时，有的业务人员在姓和名之间加空格，有的不加空格，还有的在每个字的字母之间都加空格。系统里就存在WANG XIAOHAN、WANGXIAOHAN、WANG XIAO HAN等样式。
3）姓和名位置问题。按照英文写法名在前，姓在后，但在实际操作时，由于业务人员的录入差异，会存在有的是名在前、姓在后，有的是姓在前、名在后。于是在有的地区是WANGXIAOHAN，而在别的地区可能就成了XIAOHANWANG。
以上三方面问题加在一起，一个姓名的排列组合有几十种。不夸张地说，当用户字母作为姓名时，支付时很可能要尝试好几十次。
结果就是支付成功率受到严重影响，用户体验很差，大多数人可能试了几次不成功后就放弃了。
对于上述情形，大多数情况下银行系统接口无法适配所有情况，因此对于支付平台而言，解决的办法就只有尽可能不让用户输入姓名，但前提是有支付通道支持。
我们在检索到用户输入姓名需要为字母的时候，可以优先路由不需要姓名的支付通道，从而规避掉此类问题。比如在外卡交易中，只需要用户输入卡号、有效期、CW的支付通道是比较常见的，那么当我们识别到卡号是外卡或者证件类型是护照时，让系统优先走不需要证件类型的通道。
3、事后路由
事后路由是指在支付交易过程中，识别通道方返回的交易码，将一些因为通道方原因（如通道超限）造成的交易失败进行重试以挽回交易。
这需要根据返回码进行精确筛选、区分，每个通道的返回码都不一样，这里不一一举例说明。
在路由调用的节点按照路由算法优先级做出最优支付选择，实现对交易决策的最优解，达到对支付成功率、支付体验满足度、支付收益、支付安全度等方面的收益管理。
