路由的设计与职能，概括来说就是根据已有条件找最优通道，并将计算结果返回给平台。这个过程可以拆解成三步：
1）准备数据和清理数据，包含商户信息、交易信息、用户信息等；
2）计算最优通道，根据准备数据去匹配路由算法，得出最优通道，获取最优通道所需要素；
3）返回计算结果，路由将最终的计算结果（是否有通道可用、要要素情况、不支持原因等信息）返回给支付平台。
有了重试服务这样的应用场景后，路由做事的目的没有变，但过程变得复杂了许多。下面我们就看看这些步骤复杂在哪里。
1、准备数据和清理数据
在没有重试服务的时候，在支付平台与路由的交互中，路由的目的是告诉支付平台什么通道可用，让用户提交什么支付要素，路由并不会主动挖掘数据。交互过程的时序步骤如下：
1）平台提交商户信息、交易信息；
2）路由收集这些信息准备计算，最终返回各支付品牌下通道所需支付要素。
而在重试服务的场景里，路由的目的是根据已有要素计算最优通道，其中已有要索既包括事先缓存的、此次上游上送的，也包括路由自己去常用卡服务等存储用户数据的地方挖取的。
支付系统为了保证要素的准确性，准备满足通道计算的要素，路由甚至需要通过鉴权渠道对要素进行鉴权数据正确性。因此路由也多了一些工作，需要定时去清理缓存数据，以免数据冗余。时序步骤如下。
1）缓存订单风险数据。调用风控，根据风险情况计算通道是由路由调用执行的。没有重试服务的时候，每笔订单的请求只需要实时计算就可以；而有了重试服务后，一笔支付订单可能会进行多次路由重试，这就需要提前把订单的风险结果存储下来，存储的数据包括支付订单号、风险结果。
2）上游上送用户数据。上游上送给路由服务用户卡要素或者协议号等信息，以及已经支付失败过的通道合集，以便路由计算最优通道时将这些排除在外。
3）路由服务挖掘系统已有数据。存储用户支付要素数据的服务称为“卡服务”。卡服务存储卡要素的具体值、卡要素的验证情况（如已验证或未验证）及协议支付通道对应的协议号。
路由系统需要将用户已存储的数据从卡服务中挖掘出来，并将其与上游上送用户数据一起拼成全面的数据。拼成的数据可用报文表示，举例如下。
卡号888888888888；来源：本次交易；是否已验证：未验证。卡号8888888888888；来源：卡服务；是否已验证：已验证。姓名：王小憨；来源：卡服务；是否已验证：未验证。姓名：王小憨；来源：卡服务；是否已验证：已验证。证件号码：1111111111111；来源：卡服务；是否已验证：已验证。
补充一句，对于交易失败，即使是因为卡信息有误，支付通道也不会告知具体是哪个要素错误，目的是防止盗刷者撞库、穷举值进行交易。因此，这里所说的已验证就是指验证正确，未验证包括验证错误和未验证。
为了方便理解，上述例子只举了三个要素：卡号、姓名和证件号码。例子中的报文表明，这次重试服务用户主动填写的要素只有卡号和姓名，因为交易失败，所以系统将其视作未验证。同时常用卡里保存了卡号，是已验证情况，两个卡号一致。除此之外，常用卡里面还保存姓名、证件号码和验证结果。
实践中，对于同一个字段验证结果的处理会有多种情况。以姓名为例，同样卡号，姓名是未验证，常用卡的不同情况举例如下。
第一种情况：用户提交的姓名与常用卡服务中存储的姓名一致。
那么可以认为用户提交的姓名是正确的，姓名这个参数视为已验证情况。
第二种情况：用户提交的姓名与常用卡服务中存储的姓名不一致。那么必须将用户提交的姓名视为未验证的，将姓名这个参数视为未验证情况。之后上送交易必须支持验证姓名通道或者先通过鉴权通道验证姓名，验证正确后才送支付通道。
4）鉴权数据。支付要素有卡号、姓名、证件类型、证件号、手机号码、有效期、CW等。根据上面所提到的，要素除了本身的具体值外，还有验证结果，同时会根据用户填写数据与系统数据是否一致判断是否可视为已验证，对于未验证要索要先进行鉴权，验证正确后可重试。
5）根据鉴权结果，得到所有要素的来源和是否已验证情况。
6）定时将订单风险缓存结果清空。
2、计算最优通道
没有重试服务的时候，在支付平台与路由的交互过程中，路由存在两种计算模式：一种是按照交易信息、商户信息匹配算法通道；另一种是按照要素找通道，在交易信息、商户信息基础上根据卡BIN、证件类型要素匹配适合的通道。时序步骤如下：
1）路由服务接收交易信息、商户、户等信息；
2）路由服务根据自身算法（基础路由、短路路由、分组路由、风险路由）匹配最优通道。
在非重试服务的场景里，根据要素匹配支持的通道，每次计算要素是确定的，也是相对较少的，计算的模式和目的也不一样，而这些在重试服务中都不一样。在重试服务的场景里，路由计算的复杂度体现在两方面：计算要素增加，匹配模式改变。
（1）路由计算的复杂度
复杂度体现点一：计算要素增加。
计算要素数量不同。在非重试服务中，计算要素数量是确定的，比如一个或两个，而且在进行要素计算时不需要区分来源方，相比后面的重试服务，计算要素较少。
重试服务中计算维度不仅需要考虑卡号、姓名、有效期、证件类型、手机号码、验证码发送方这些参数，还需要区分要素来源（来自卡服务还是用户提交），判断要素验证结果（已验证还是未验证）。
这三个维度排列组合出来的结果会有很多，路由需要根据这些结果做出不同处理。
计算要素确定性不同。在非重试服务场景里，路由计算支付要素的模式是确定的，比如根据卡号匹配通道或者根据证件类型匹配通道。
根据卡号中卡BIN匹配支持的通道，要素是卡号；根据证件类型的具体证件类型（如护照）匹配支持的通道，要素仅是证件类型或卡号+证件类型，要素是确定的。而在重试服务场景里，路由计算支付要素是不确定的，取决于用户提交的结果、卡服务中存储的结果、鉴权验证通过的结果。
复杂度体现点二：匹配模式改变。
匹配模式改变。在非重试服务场景里，路由计算的目的是告诉支付平台此次交易需要哪些要素；匹配的逻辑是路由根据用户提交的要素匹配最优通道，通道所需要素大于用户提交要素。
比如用户提交的证件类型是护照，支付平台向路由请求结果，路由计算出来的通道就需要支持要素证件类型，且证件类型必须支持护照。除此之外，通道还需要什么要素并不在算法考量范围之内。计算完成后，返回请求方所计算最优通道及所需要素。
而在重试服务里，路由计算的目的和模式几乎是与非重试服务相对的。计算的目的是告诉支付平台根据现有要素哪些通道可用。模式是根据现有的要素去找支持的通道，现有要素需要大于通道所需要素。另外，重试服务的计算逻辑也不一样，而且多了一些额外的处理流程（如对于数据的缓存处理及应用与定期清理）。
比如从用户提交的要素和卡服务中获取的要素有卡号、姓名、有效期、证件类型、证件号，路由在重试服务场景中计算逻辑是匹配符合要求的通道且需要要素不多于这五个要素（因为要让用户无感，用户不参与其中，没有机会让用户补填要素），而在非重试服务场景中是看哪些通道包含这五个要素，两者是有很大差异的。
（2）路由计算数据准备
在数据准备阶段，用户提交的要素验证结果不管是经过鉴权通道验证还是通过与卡服务匹配获取的，最终对于整体数据我们可以得到两个结果：全部验证和部分验证。前者是指所有要素都经过验证且正确的情形，后者是指有一些要素验证错误或无法验证的情形。
通道形态有快捷协议支付通道、代扣/代付通道、无磁无密通道等。根据用户要素验证结果，这些不同类型通道是否可以进行重试必须按照表1中的原则进行，以保证在支付中安全。下面展开介绍表1中的原则。
表1 验证结果参与通道重试表
在路由计算通道是否可以参与重试时，只要通道所需要素少于或者等于已收集要素（用户提交要素+卡服务数据）就符合要求，那么就会出现通道只需要三要素，而用户提交了五要素的情况。这时如果未全部验证，未验证项又是通道不需要的要素，支付就会成功。但可能有用户提交要素错误的情况，用户可以凭借此要素错误选择拒付。
下面我们就重试服务在各验证结果与不同通道类型结合适用的情况展开具体说明。
适用情况一：全部验证快捷协议支付。
快捷协议的特性是凭借协议号或者Token就可以支付。如果用户提交要素都验证正确，卡服务中又有某些通道的协议号，那么有协议号的通道就可以使用。注意，如果某快捷通道要素匹配，但卡服务无此通道协议号，若在交互流程中需要该通道发送短信验证码，则该通道不可用，因为需要用户参与。
示例1
前提条件：用户提交要素卡号、姓名、有效期，要素全部验证正确，卡服务中有A通道协议号，交易环节A通道不发送短信验证码。
重试计算结果：A通道可用。
原因：A通道需要什么要素都没有关系，因为该卡协议号已经存在，而用户提交的要素已验证，保证了正确性。
示例2
前提条件：用户提交要素卡号、姓名、有效期，要素全部验证正确，卡服务中有B通道协议号，交易环节B通道发送短信验证码。
重试计算结果：B通道不可用。
原因：虽然B通道协议号存在，但是B快捷通道交易时除了协议号还需要短信验证码，而重试的宗旨是在安全的前提下让用户无感知，所以该通道不适用于重试场景。
示例3
前提条件：用户提交要素卡号、姓名、有效期，要素全部验证正确，卡服务中无C通道协议号，C通道是快捷通道且要素只需要卡号、姓名、有效期。
重试计算结果：C通道不可用。
原因：因为大多数快捷签约通道都需要通道方发送短信验证码，用户收到短信验证码就会有感知。即使签约环节不需要短信验证码、要素齐全，系统自动上送通道要素签约，也不可以用于重试服务，因为签约时通道经常会下发短信如“某某，你的卡号111111111111在xx平台签约快捷支付成功。（xx银行）”，这会让用户有感知并产生困惑。
适用情况二：全部验证-代扣/代付支付。
代扣和代付类通道的特性是凭借卡号+姓名就可以扣款或者付款，与快捷支付凭借协议号本质上一样，因为其不需要签约的特性，所以比快捷协议通道重试应用更广。
在用户提交要素全部验证正确时，该通道可用。
示例4
前提条件：用户提交要素卡号、姓名、有效期，要素全部验证正确；卡服务中要素有卡号、手机号，验证状态正确；代扣通道A可用，要素只需要卡号、姓名。
重试计算结果：A通道可用。
原因：用户提交要素都已经验证正确，且满足代扣通道要素要求。
适用情况三：全部验证无磁无密支付。
无磁无密支付的特性是每次都要单独验证卡信息。无论用户提交什么信息，只要与卡服务中拼出来的支付要素集合满足无磁无密支付通道要求就可以重试，因为如果要素信息有误，无磁无密通道会验证不成功，交易失败。
示例5
前提条件：用户提交要素卡号、姓名、有效期，要素全部验证正确；卡服务中有卡号、手机号，验证状态为已验证；存在支持该卡的无磁无密通道A，要要素卡号、姓名、有效期、手机号。
重试计算结果：A通道可用。
原因：户提交的要素都已经验证正确，且与卡服务存储要素组合结果满足无磁无密通道要素要求。
适用情况四：全部验证通道发送短信验证码。
重试的宗旨是在安全的前提下让用户无感知，因此不管验证情况如何，只要交易环节通道需要发送短信验证码，都一律不参与重试，举例见示例2。
适用情况五：部分验证-快捷协议支付。
快捷协议凭借协议号或者Token就可以支付，在已有协议号的情况下，支付过程中不再验证卡要素。在用户提交的部分要素未验证的情况下，直接用协议号支付，会支付成功。为了避免此情况带来的后续拒付及安全性问题，不可用于重试服务。
示例6
前提条件：用户提交要素卡号、姓名、有效期，未验证；卡服务中有A通道协议号；存在支持该卡协议的通道A通道。
重试计算结果：A通道不可用。
原因：不能保证要素正确性。比如由于卡服务协议号的存在，如果提交到A通道重试，会支付成功。但实际情况是用户卡号和姓名是正确的，但有效期错误，如果用户发起拒付，银行调单后会发现用户提交信息确实不对，就会支持用户拒付，从而进行退款，由商户担责。
对于公司来说这是支付中巨大的风险，轻则造成资损，重则造成公司被产“薅”到破产。
适用情况六：部分验证代扣/代付支付。
代扣/代付通道特性前面已经介绍，不再赘述。由于无法保证要素正确性，它不可用于重试支付。
示例7
前提条件：用户提交要素卡号、姓名、有效期，未验证；卡服务中有A通道协议号；存在支持该卡协议通道A通道。
重试计算结果：A通道不可用。
原因：不能保证要素正确性。同示例6。
适用情况七：部分验证无磁无密支付。
前面说过无磁无密的特性是会验证所有卡信息，所以可以使用部分验证情况。但需要注意，适用情况是，无磁无密通道支付所需要素包含胪提交的所有未验证要素（际例8）。如果只包含部分未验证要素，那么遗留下来的要可能就是错误的，所以不能用于重试（见示例9）。
示例8
前提条件：用户提交要素卡号、姓名、有效期，未验证；存在类型为无磁无密的A通道，需要要素为卡号、姓名、有效期。
重试计算结果：A通道可用。
原因：无磁无密在支付过程中进行要素正确性校验，且保证了用户提交的卡号、姓名、有效期均得到验证。
示例9
前提条件：用户提交要素卡号、姓名、有效期，未验证；存在类型为无磁无密A通道，需要要素为卡号、姓名。
重试计算结果：A通道不可用。
原因：无磁无密类型通道虽然在支付过程中进行了要素正确性校验，但不支持验证有效期，重试的话无法保证有效期正确。
适用情况八：部分验证通道发送短信验证码。
在适用情况四中已阐述不可用于重试服务的原因，这里不再赘述。
3、返回计算结果
路由将重试计算结果按照报文返回给上游调用方，这与之前讲过的路由类似。概括一下，返回的结果有两类。
一类是重试计算结果状态，比如重试成功、无可用通道、卡BIN不支持等按照需要给出的返回原因。另一类是返回具体的明细，比如重试结果可用的具体通道是什么、需要哪些验证要素、通道限额等，以便于支付引擎准备交易信息及上送交易。
一个重试服务是有效还是无效，是需要通过数据来体现的。表2和表3是日常工作中所用的表格，供大家参考。
表2 重试服务日汇总数据
表3 重试订单明细情况
