支付交易——重试服务

摘要

为了能在最大限度满足顾客要求的前提下尽可能降低成本，老王在开店的过程中想了很多方法。这充分体现出老王作为一个商人的特质:不放过一个订单，不浪费一分钱。

老王就这样在自己的生意上兢兢业业多年，想着应该不会有什么纰漏。但现实很残酷，在公司年终大会复盘时老王听到了员工反馈的问题。这些问题轻则造成订单损失、利润减少，重则导致客户流失。

问题一：供应商货不够或者限制批发数量。

很多时候，特别是品牌方有活动时，员工去拿货，供应商说货不够，让改天来。员工没有选择，只能第二天再来，但次数多了，员工就开始琢磨原因了。他们猜测原因可能有两种。

口供应商生意火爆，货不够了。原本一天能给老王提供一万箱的，现在只能给五千箱了。
供应商为防止“羊毛”，限定了活动期间的购买量。比如图书已经折上再五折，纯粹是做活动赚吆喝，要是让一家进货商全买走了，那别的进货商就无货可买了，所以只能限制批发量。

问题二：供应商太忙，没人处理业务

为了保证产品质量和用户体验，老王要求员工一律从最好的供应商那里进货。而老王认为好的，往往也是别的经销商认为好的，所以经常就会发生这样的情况:这边顾客催着要大宗订购，而老王指定的一直合作的供应商那边却因为生意好经常电话占线，邮件也没人回。员工不知道供应商到底有货没货，不能给顾客准确的答复，只能先让对方等待，改天再答复。这时，着急的顾客就直接去别的店买了。根据员工反馈，这种事情造成的顾客流失不在少数。

问题三：服务质风稍差但价格有优势的供应商．能否合作?

在前面老王的故事里提过，为了应对突发事件，不把鸡蛋放在一个篮子里，老王基本为每一款产品都备着多家供应商。但是老王要求员工去服务、质量、效益最好的供应商那里进货，哪怕贵一些;而被老王列为备选的供应商看上老王的生意在全国的影响力，愿意给老王最低价，期望能够与他长期合作,得到他的背书。

长期这样，员工也替老王心疼:一年多出那么多的成本，要是能省下来，拿出一点来发奖金多好。事实上，其他供应商提供的服务也不算差，长期合作的供应商十次有九次当天送货当天到，而其他供应商十次也有五六次能当天送货当天到。

老王一听就明白，是自己独断专行和矫枉过正了。问题其实挺好解决的，只是自己没有授权员工，发挥出员工的积极性，造成了员工委屈和客户不满。
老王当场就敲定了几条措施来解决问题。

第一条措施:把强制采用最好的供应商,改为优先采川最好的供应商。
第二条措施:同等条件下，可以向多家供应商询价。

这两条措施一出，员工反馈的问题就都解决了。下面来逐个问题分析。

问题一：供应商货不够或者不让买太多。

供应商卖得太好，货不够?员工可以联系别的供应商。
供应商有活动，怕被一家全买走了?每家供应商都有活动，一家限量了，可以再去另一家买，最多把每家能进的量都进满进足。

问题二：供应商有时候太忙,没人处理业务。

之前由于老王指定了必须去某一家进货，大家不敢忤逆。现在的原则是用户第一，不能让用户流失了。先向最好的（如离得最近、送货最快的）供应商订货，如果没人回应，再向其他服务也不错的供应商订货。这么一来，客户就不会流失，也不会抱怨了。

j问题三：服务质量稍差但价格有优势的供应商,能否合作?

既然允许选择其他供应商，那么要货不太急的时候，就可以先跟其他供应商沟通进货需求。反正老王要的都是标准品，能满足要求的就进货，不能满足的再找那个离得最近、送货最快的。这么一来，送货快的反而成了备胎，而老王的的确确省下了不少钱。老王拿出其中一部分给员工发奖金，员工的积极性更高了，创造的效益更多了，老王心里那个美。

故事中的老王和供应商的问题，其实就类似于支付平台利通道的问题

用户按照要求提交信息，会遇到通道单日限额超限的问题，也会遇到通道不稳定的问题。支付系统如果只能进行一次支付尝试，那么永远上送交易给成功率最高的通道，但是忽视了成本，这达不到全面的最优解。怎么解决呢?
老王遇到供应商限额、供应不够、通道不稳定的时候可以找其他供应商，那么支付里遇到通道单日超限、通道无响应的时候，是不是也可以不用等，而将支付信息提交给其他通道进行支付?
老王遇到有价格优势但可能距离远一点、送货慢一点的供应商，可以根据具体情况考虑向他们进货，甚至只要这些慢一点的供应商能满足要求，反而会优先向他们进货。那么支付通道可不可以也建立这样一个兜底机制，就像这种问询的形式，先选择成功率稳定、成本低的通道，如果支付不成功，再上送成功率高的通道?

一、重试服务的原因

支付的核心指标之一是支付成功率。提高支付成功率的方法 .有很多，比如提升通道质量、进行系统监控并针对问题通道进行自动熔断、进行队列处理控制并发量、事中路由保证交易可用、根据日切时间进行自动对账时增加处理时间、提升通道限额等，但是在实践中会发现,用了这么多方法提升支付成功率，依然有一些问题会造成交易失败。

1.1 通道限额问题

前面说过,通道有单笔限额、单日限额甚至单月限额,用户所在的发卡行也会有单笔、单日、单月限额。当用户需要在某日订购价格特别高的产品或服务时、比如公司团建，行政人员帮整个公司订购出行服务﹑很可能会遇到这样的场景:用户通道超过单日限额,无法支付，但用户本身在发卡行并没有设置限额。

遇到这种问题,在路由通道计算最优通道的时候（没有建立用户计数服务:实操层面用户计数服务影响性能且达不到触发阈值标准，绝大多数公司不太会建立)，此超限通道永远都是最优通道，用户会一直无法支付成功。

在没有重试服务的情况下，支付交易结果是只能建议用户换卡或者次日再试。但建议用户换卡是有问题的：

第一，无论是换卡还是次日再试，都已经造成支付失败，损害用户体验和影响支付指标;
第二，用户可能没有那么多银行卡，最终只能放弃;
第三，即便用户有其他银行卡或者次日再试，可能依旧会触发超限。

1.2 通道服务异常问题

在商户或者支付平台与通道握手、进行报文交互的过程中，可能会由于网络抖动等因素，某一方没有收到请求或者返回应答，迟迟无法收到结果，导致交易失败。遇到这种情况，一般有两种解决办法。

一种方法是采取补偿机制。商户或者支付平台一直查询交易结果或者发起冲正交易，但系统异常持续时间长，查询会一直无结果，而且并非所有通道都支持冲正交易。
另一种方法是先把原交易置为失败，前端界面显示提示信息:建议用户重新支付。然后再查询或者对账，如果原交易成功，扣用户款了，为用户进行退款处理;如果原交易失败，支付系统不做处理。但是这种方法会让用户感知到交易失败。

1.3 通道使用率的问题

有一些通道的特性是成本较低，但是质量相对较差，在追求可用性的前提下，这类通道被我们称为“备份通道”。在日常工作中，除了发生所有优先支付通道都不能用的极端情况，一般都不会用到备份通道。

但通道质量差是相对而言的,越是大商户，要求越严苛。比如对于大商户而言，可能98%的支付成功率是正常，95%的支付成功率已经低了;但是对于其他商户而言，95%的支付成功率已经很高了。在这个场景里出于成功率的考虑，在没有重试服务的情况下，无法将一些低费率的通道充分利用起来，最大可能降低支付成本。

由于上述问题的存在,在不断提升支付核心指标的过程中，需要找到一种方法，尽可能既保证支付成功率、用户体验，又能降低成本。

解决这些问题的方法或者服务称为“重试服务”。重试服务是指对于支付交易失败，分析并返回失败原因,根据返回原因重新组纵支付要素，送给交易通道的处机制。

1.4 重试服务解决方案

为什么这个机制可以解决上面提到的问题?我们再看看这几个问题，如果有了重试服务会怎么样。

问题一：通道限额问题。

假设招商银行信用卡这个支付品牌有A、B两个通道可用，其中较优的通道是A通道。上面提到某公司行政人员使用招商银行信用卡进行支付，该卡在银行未设置限额。该用户在A通道发起支付，触发单日限额，交易失败,原本应告知用户更换银行卡进行支付。但是在A通道单日限额超限，并不代表在B通道单日限额超限。通过重试服务将支付要素上送到另--个通道发起交易请求，如果另一个通道未融发单日限额,那么这笔交易失败的订单就能被挑救回来变成支付成功订单。

问题二：通道服务常问题

遇到通道服务异常，重试服务会根据通道的返回情况判断是否重新发起支付。比如交易发生“系统异常”或者“无交易结果返回”这样的情形。这样的结果与客户本身无关系，是平台或通道原因造成的支付失败。重试服务会将这个交易报文信息结合卡要素进行鉴权，验证正确后先重新发起支付或者将交易上送到其余稳定通道,后续再对原交易进行查询和采用退款、冲正等补偿机制，把原有失败的交易及时挽救回来，变成成功交易。经过这样的处理就不需要再等待，也不需要在前端界面告知用户重新支付，让用户感知到交易失败。

问题三：通道使用率问题

出于担心通道质量差、不能自身支付高可用的要求，不愿将‘具有成本优势的通道用于主交易。之所以不愿意，是因为在无重试服务的情况下，支付过程只有一次支付机会，不能失败后再次尝试。所以在成功率优先的原则下，只能路出至成功率指标最为出色的通道﹒而忽视其他指标

有了重试服务后，这个问题立即迎刃而解。还是以招商银行信用卡为例，假设该支付品牌有A、B两个通道可用，A通道成本低，但是质量差;B通道成本高，但是质量好。在每年成本KPI完成的基础上，如果无重试服务，那么交易都会上送到B通道，以保证支付可用性，提高支付成功率。但现在有了重试服务，相当于B通道给A通道做了兜底服务，可以大胆地将A通道用于交易，只要不是客户本身卡信息有误之类的问题造成的交易失败，就可以重新将支付要素上送到B通道进行支付。

这样的处理机制依然保证了支付的成功率，而A通道也能够最大可能发挥其成本优势，从而达到支付的最优解。

二、重试服务体系

重试服务的运转与应用核心在于两部分：重试服务自身的重试规则和路由系统针对重试服务的处理机制。在具体阐述每个关键部分之前，我们先看看一个完整的时序图是怎么交互的，如图所示。其中，参与的服务有支付平台、决策引擎、重试服务、路由服务、鉴权服务、收银服务、支付通道等。

2.1 重试服务整体流程

交易订单经过支付系统时，系统处理时序如下。

支付平台上送交易请求。上送商户信息、行业、交易金额、交易类型等，请求获取可用的支付方式、支付品牌及支付通道。
路由计算最优通道。路由根据上送参数及风险结果计算最优通道。由于重试服务的存在，路由需要缓存支付订单号、风险结果、最优通道ID，留作后用
返回可用支付方式。路由返回可用支付方式、通道及需要的支付要素。
提交用户支付信息。支付平台根据返回信息进行显示，用户输入支付要素之后，将支付信息提交给决策引擎。
收银处理支付请求。收银系统收到支付信息后，记录支付订单号、支付流水号和支付状态，将交易上送给支付通道。
支付通道返回交易结果。支付通道处理交易，并返回交易结果及报错明细（假定支付失败)。
收银系统更新订单状态。收银系统收到支付结果后，更新订单状态并将支付结果返回给决策引擎。
调用路由请求可用通道。根据重试服务的返回结果将订单号等要素上送给路由服务，再次请求可用通道。
路由重试获取缓存结果。路由根据请求订单号，获取缓存中订单的风险等级、之前的下发通道。
路由准备支付数据。路由系统为了有更多通道可参与重试，读取系统中已存储卡数据（包含协议号)，将此次上送要素中未验证要素提交到鉴权通道进行鉴权，以判断要索正确性。
匹配重试通道。根据已验证正确要素情况及路由规则计算最优通道。注意:只将验证正确要素用于重试计算。
返回二次路由可用通道及要素或者协议号。将获取可用通道及所需要素或者协议号并返回给决策引擎。
继续发起交易请求。决策引擎收到支付要素及最优通道后，将支付要素上送给交易系统，进而流转至支付通道;支付通道将支付结果返回给交易系统，进而给决策引擎。
支付结果后续处理。根据支付结果成功与否，决策引擎进行后续逻辑处理:展示支付结果或者继续调用重试服务。

通过以上内容我们了解了重试服务中各服务是如何运转的，接下来我们来看重试服务是如何设计的。

2.2 重试服务设计

“重试服务”的定义为:已有要素（用户此次提交和系统之前已存储要素）在准确性得到验证的基础上，根据返回原因确定决策交易是否可以再次支付，以提升用户体验、挽回成功率的机制。

重试服务由两部分组成：重试规则建立和重试规则匹配。重试规则匹配的基础就是重试规则的建立。服务根据建立的规则内容进行匹配，配成功，参与重试；否则不参与重试。

重试规则的关键项

规刚：001。每个重试规则有唯的编号。
商户号：mo000001。设定规则适用的具体商户，可以为空。不是每个商户都要单独设立规则，商户号为空代表采用该商户对应的行业规则。
行业类型：旅游。设定规则适用的具体行业，可以为空。如果不设置商户，则代表对整个行业适用;如果同时存在该行业下的具体商户规则和该行业通用规则、以具体商户规则为准。
“之讨通道：农行直连通道。配置具体交易失败后能够重试支付的通道范围，也就是只有这些通道交易失败才可以重试。
以时品牌：农业银行信用卡。配置具体交易失败后能够重试支付的品牌范围,也就是只有配置的支付品牌交易失败才可以重试。
币种: CNY。配置参与重试服务的币种。
交易少型：消费。配置参与重试服务的交易类型。
适用响应码：01、02、03。配置该支付通道参与重试服务的响应码。响应码的配置取决于重试服务的设计思路：如果偏向保守．采用白名单设计思路．那么只有返回的是配置的响应码．交易才能重试;如果偏向激进．采用黑名单设计思路，那么只要返问的是配置之外的响应码、交易均可重试。
合适的渠道：线上、App。商户或者行业存在多渠道应用，该项配置重试规则适用的渠道范围。
流量控制：100%。配置重试规则在一定条件下适用的流量比例，可用于对比效果、验证可用性。
允许重试次数:3次。配置一笔支付允许订单重试的次数。出于用户体验的考虑，即使支付通道足够多，也不应无休止地重试。因为每次重试都需要各服务重新握手、交互信息，重试次数过多会让用户等待时间过长。
系统等待最长时问: 10s。配置重试服务最长等待时间。前面配置了重试次数，这项进一步明确限定了时间。
是否开启:开启。配置规则有效状态。
生效川间:2019.01.01-2020.01.01。配置规则有效时间。

上面列举了商户mo000001关于农行信用卡可以重试的规则、大家可以根据前几章的内容和这个例子，再结合自己实际遇到的场景，试着列出几个规则，加深对重试服务规则的理解。

2.3 重试原则设计

除了重试规则的具体内容外，重试服务还有一些原则。

原则一：参亏对象一般只有银行卡类交易。

我们知道支付品牌里存在的对象包括银行信用卡、借记卡、账户类支付(各类钱包，如微信、支付宝、电商自有账户等)、储值卡等。通常账户类支付和储值卡的支付通道是唯一的，没有备份通道，为了避免后续路由进行无用计算，在重试规则这里就直接只配置支持银行卡类交易。

原则二：鉴权类交易、风险类订单交易、人工置失哎交易.出款交易不参与重试。

失败订单场景有这几类：鉴权类交易、风险类订单交易、人工置失败的订单、无风险客户的扣款交易、无风险客户的出款交易。重试交易的原则是在保证交易安全的前提下，客户主观希望交易成功。在这个原则下，对于参与重试的交易种类是有限定的。

鉴权类交易本质上是为了验证信息的准确性,不管是信息不对还是服务异常等原因，都不会进行重试服务。这主要是出于谨慎性原则考虑。各家通道进行鉴权交易背后验证的逻辑可能会不一样，有些通道会存在验证要素不全面的情况。

举个例子，一笔鉴权交易需要验证五要素，有A、B两个通道均支持此交易，这笔交易同时上送给这两个通道进行验证。验证结果是:A通道返回结果“验证正确”，B通道返回验证结果“验证不正确”。为什么会出现这样的结果?情况可能是。一家验证的是实时数据，另一家验证的是自身系统历史数据。

鉴权和支付交易一样，在进行交易受理时，通道背后的服务商会收取通道方手续费。出于节省成本考虑，通道方会先与自身系统存储数据（之前验证过正确、存储在系统中的数据)进行比对。如果自身系统中存在此数据，与请求的鉴权数据也能够完全对上，那么通道就不会查询公安、银行等外部权威渠道的数据。

如果用户修改过姓名或者手机号码，在银行的数据已经发生过更新，但是B通道保存的数据还是原有旧数据，A通道用的是实时数据，每一笔鉴权都查询内外部最新的数据。那么此时哪怕用户的数据完全真实且正确，但结果会像上面所说那样:A通道返回结果“验证正确”，B通道返回“验证不正确”。但事实上，B的结果是错的。

反过来，如果A通道存储的是用户旧数据，B通道用的是实时数据,此次请求用户上送的数据是旧数据。结果A通道“验证正确”，B通道“验证不正确”，而事实是A通道验证的结果是错的。

由于验证处理机制存在差异，会出现不同的验证结果，而商户或者支付平台作为调用服务方是无法知道背后通道的处理逻辑的。所以对于鉴权通道，要在合同签署时要求支付通道对于其准确性承担责任。另外出于谨慎性安全考虑，鉴权类交易是不参与重试的。

另外，如果是网络掉线等原冈、在通道层面有正常的补偿机制进行处理。不需要调用重试服务。风险类交易本质主是为了加强验证或者进行拦截。也是不参与重试服务的对于风险类交易，安全是优先级最高的，成功率与成本都是次要考虑因素。对于这类交易，会让用户进行更多要素的验证，或者转移到风险交易包赔的支付通道上。如果对于风险类交易也进行重试服务，不能达到验证更多要素或转移风险的目的。

人工置失败类交易本质上是出于某些考虑而人为将订单置为失败。人工置失败的原因可能是系统自动退款超过退款时间，客户无法操作，需要平台人工操作;可能是对账后发现账单不对，

要进行差账处理等。不管是什么原因，目的都是让订单无效和失败，如果这类订单失败了还要重试，就与目的相反了。出款类交易是把资金款项付到客户账户 ,一旦资金进人客户账户、付款人就失去了对资金的控制权。如果此类型交易重试.会存在重复出款多笔的可能、进而造成资损。所以针对出款类账户交易方向的特性，基于保证安全及避免资损的考虑，出款类交易是绝对不允许重试的。

原则三：参树重试通道响应码有要求

重试服务是在安全的前提下对能够通过重试挽救的订单进行重试，以提高成功率。基于这个目的，不安全的不能进行重试，明知道不成功的也不会进行重试。那么系统里不参与重试的通道响应码有哪些?枚举如下。

短信验证码错误。
有效期错误。
卡过期。
卡无效。
卡状态异常。
卡余额不足。
卡信息有误。

各家公司由于对风险交易的容忍程度、对成功率的看重程度和公司的行事风格都有差异，所以制定的重试服务对于响应码的具体规则也有差异，分成了黑名单、白名单两种指导规则。

黑名单方法是列出绝对不能进行重试的通道响应码、除所列:出}响应码之外的交易都可以进行重试。这样的好处是配置工作量较少，适用范围广;缺点是存在出错可能，因为通道响应码是会不定期更新的，且可能更新没有通知到商户或者支付平台。如果新增的响应码属于黑名单响应码种类之一，此类响应码是不可以参与重试的。但由于之前黑名单重试规则库里没有配置此响应码，就会对此类不能重试的交易也进行重试，从而造成用户投诉、欺诈交易和资损可能。
白名单方法是列出能够进行重试的通道响应码，除所列出响应码之外的交易都不能进行重试。这样的好处是安全性高，保证每一笔重试的交易都是符合原则的;缺点是配置量大，适用范围小，通道中白名单响应码占比大，每个通道都有几十上百个响应码。在进行重试规则设定时需要占用大量的内容配置工作。因为只能在配置的白名单响应码中应用重试服务，通道响应码即使如黑名单案例一样没有及时配置，其结果只会少挽回一些交易，但不会造成过错，使得不能重试的交易进行重试，从而造成用户投诉、欺诈交易和资损可能。

原则四：重试服务上送新通道之前，原则上原通道交易需要有个终态结果。

除了通道返回交易失败外，重试服务发生的场景还有系统间交互.异常等原因造成的信息丢失，获取不到交易结果等失败。

在“支付通道”中提到，交易中存在补偿机制，有查询、冲正、退款。这里特别说明．重试服务并不是这些服务的替代。原有的补偿机制依旧存在，需要先进行原有补偿机制处理，如冲正作废原交易或者查询原交易失败后再进行重试，否则很容易造成订单混乱、清结算账单对不平等问题。

以上是重试服务的设计，用来判断一笔交易能不能重试，后续选择重试通道还需要路由服务的参与。下面我们看看路由针对重试服务的处理机制。

2.4 路由重试服务设计

前面的博文过路由的设计与职能，概括来说就是根据已有条件找最优通道，并将计算结果返回给平台。这个过程可以拆解成三步：

准备数据和清理数据，包含商户信息、交易信息、用户信息等;
计算最优通道，根据准备数据去匹配路由算法，得出最优通道，获取最优通道所需要素;
返回计算结果，路由将最终的计算结果（是否有通道可用、需要要素情况、不支持原因等信息）返回给支付平台。

2.4.1 准备数据和清理数据

在没有重试服务的时候，在支付平台与路由的交互中，路由的目的是告诉支付平台什么通道可用，让用户提交什么支付要素，路由并不会主动挖掘数据。交互过程的时序步骤如下：

平台提交商户信息、交易信息。
路由收集这些信息准备计算，最终返回各支付品牌下通道所需支付要素。

而在重试服务的场景里，路由的目的是根据已有盛素计猝最优通道,其中已有要素既包括事先缓存的、此次上游上送的，也包括路由自己去常用卡服务等存储用户数据的地方挖取的。

支付系统为了保证要素的准确性，准备满足通道计算的要素，路由甚至需要通过鉴权渠道对要素进行鉴权数据正确性。因此路由也多了一些工作，需要定时去清理缓存数据，以免数据冗余。时序步骤如下。

缓存订单风险数据。第4章介绍过调用风控，根据风险情况计算通道是由路由调用执行的。没有重试服务的时候，每笔订单的请求只需要实时计算就可以;而有了重试服务后，一笔支付订单可能会进行多次路由重试，这就需要提前把订单的风险结果存储下来，存储的数据包括支付订单号、风险结果。
上游上送用户数据。上游上送给路由服务用户卡要素或者协议号等信息，以及已经支付失败过的通道合集，以便路由计算最优通道时将这些排除在外。
路由服务挖掘系统已有数据。存储用户支付要素数据的服务称为“卡服务”。卡服务存储卡要素的具体值、卡要素的验证情况（如已验证或未验证）及协议支付通道对应的协议号。
鉴权数据。支付要素有卡号、姓名、证件类型、证件号、手机号码、有效期、CVV等。根据上面所提到的，要素除了本身的具体值外，还有验证结果，同时会根据用户填写数据与系统数据是否一致判断是否可视为已验证，对于未验证要素要先进行鉴权，验证正确后才可重试。
根据鉴权结果，得到所有要素的来源和是否已验证情况。
定时将订单风险缓存结果清空。

路由系统需要将用户已存储的数据从卡服务中挖掘出来，并将其与上游上送用户数据一起拼成全面的数据。拼成的数据可用报文表示，举例如下。

卡号:8888888888888 ;来源:本次交易;是否已验证:未验证。卡号:8888888888888 ;来源:卡服务;是否已验证:已验证。姓名:王小憨;来源:卡服务﹔是否已验证:未验证。姓名:王小憨;来源:卡服务﹔是否已验证:已验证。证件号码:1111111111111111;来源:卡服务﹔是否已验证:已验证。补充一句，对于交易失败，即使是因为卡信息有误，支付通道也不会告知具体是哪个要素错误，目的是防止盗刷者撞库、穷举值进行交易。因此，这里所说的已验证就是指验证正确，未验证包括验证错误和未验证。

为了方便理解，上述例子只举了三个要素:卡号、姓名和证件号码。例子中的报文表明，这次重试服务用户主动填写的要素只有卡号和姓名，因为交易失败，所以系统将其视作未验证。同时常用卡里保存了卡号，是已验证情况，两个卡号一致。除此之外，常用卡里面还保存姓名、证件号码和验证结果。

实践中，对于同一个字段验证结果的处理会有多种情况。以姓名为例，同样卡号，姓名是未验证，常用卡的不同情况举例如下。

第一种情况: 用户提交的姓名与常用卡服务中存储的姓名一致。那么可以认为用户提交的姓名是正确的,姓名这个参数视为已验证情况。
第二种情况:户提交的姓名与常用卡服务中存储的姓名不一致。那么必须将用户提交的姓名视为未验证的，将姓名这个参数视为未验证情况。之后上送交易必须支持验证姓名通道或者先通过鉴权通道验证姓名，验证正确后才送支付通道。

2.4.2 计算最优通道

没有重试服务的时候，在支付平台与路由的交互过程中，路由存在两种计算模式:一种是按照交易信息、商户信息匹配算法通道;另一种是按照要素找通道，在交易信息、商户信息基础上根据卡 BlN、证件类型要素匹配适合的通道。时序步骤如下:

路由服务接收交易信息、商户、用户等信息;
路由服务根据自身算法（基础路由、短路路由、分组路由、风险路由）匹配最优通道。

在非重试服务的场景里，根据要索匹配支持的通道、每次计算要素是确定的、也是相对较少的,计算的模式和目的也不一样、而这些在重试服务中都不一样。在重试服务的场景里，路由计算的复杂度体现在两方面:计算要素增加与匹配模式改变。

1. 路由计算的复杂度

复杂度体现点-:计算要素增加。计算要素数量不同、在非重试服务中，计算要素数量是确定的，比如一个或两个，而且在进行要素计算时不需要区分来源方，相比后面的重试服务，计算要素较少。

重试服务中计算维度不仅需要考虑卡号、姓名、有效期、证件类型、手机号码、验证码发送方这些参数，还需要区分要素来源（来自卡服务还是用户提交)，判断要素验证结果（已验证还是未验证)。这三个维度排列组合出来的结果会有很多，路由需要根据这些结果做出不同处理。

计算要素确定性不同在非重试服务场景里，路由计算支付要素的模式是确定的，比如根据卡号匹配通道或者根据证件类型匹配通道。

根据卡号中卡BIN匹配支持的通道，要素是卡号;根据证件类型的具体证件类型（如护照）匹配支持的通道，要素仅是证件类型或卡号＋证件类型，要素是确定的。而在重试服务场景里，路由计算支付要素是不确定的，取决于用户提交的结果、卡服务中存储的结果、鉴权验证通过的结果。

复杂度体现点：匹配模式改变

匹配模式改变，在非重试的服务场景里，路由计算的目的是告诉平台此次交易需要哪些要素。匹配的逻辑的由根据用户提交的要素匹配的最优通道，通道所需要素大于用户提交的要素。

比如用户提交的证件类型是护照，支付平台向路由请求结果,路由计算出来的通道就需要支持要素证件类型，且证件类型必须支持护照。陶此.之外、通道还需要什么要素不在算法考量范围之内，计算完成后，返回请求方所计算最优通道及所需要素。

而在重试服务里，路由计算的目的和模式几乎是与非重试服务相对的。计算的自的是告诉支付平合根搪现有要素那些事通道可用，模式是根据现有的要素去支持的通道，现由需要大于通道所需的要素，另外，重试服务的计算逻辑也是不一样，而且多了一些额外的处理流程。（如对于数据的换成处理与应用的定期清理）

比如从用户提交的要素和卡服务中获取的要素有卡号、姓名、有效期、证件类型、证件号，路由在重试服务场景中计算逻辑是匹配符合要求的通道且需要要素不多于这五个要素（因为要让用户无感，用户不参与其中，没有机会让用户补填要素)，而在非重试服务场景中是看哪些通道包含这五个要素，两者是有很大差异的。

2. 路由计算数据准备

在数据准备阶段，用户提交的要素验证结果不管是经过鉴权通道验证还是通过与卡服务匹配获取的，最终对于整体数据我们可以得到两个结果:全部验证和部分验证。前者是指所有要素都经过验证且正确的情形，后者是指有一些要素验证错误或无法验证的情形。

通道形态在第﹖章介绍过，有快捷协议支付通道、代扣/代付通道、无磁无密通道等。根据用户要索验证结果，这些不同类型通道是否可以进行重试必须按照表中的原则进行，以保证在支付中安全。下面展开介绍表中的原则。

在路由计算通道是否可以参与重试时，只要通道所需要素少于或者等于已收集要素（用户提交要素＋卡服务数据）就符合要求，那么就会出现通道只需要三要素，而用户提交了五要素的情况。这时如果未全部验证，未验证项又是通道不需要的要素，支付就会成功。但可能有用户提交要素错误的情况，用户可以凭借此要素错误选择拒付。

下面我们就重试服务在各验证结果与不同通道类型结合适用的情况展开具体说明。

适用情况一：全部验证-快捷协议支付

快捷协议的特性是凭借协议号或者Token就可以支付。如果用户提交要素都验证正确，卡服务中又有某些通道的协议号，那么有协议号的通道就可以使用。注意、如果某快捷通道要索匹配、但卡服务无此通道协议号．若在交互流程中需要该通道发送短信验证码，则该通道不可用,因为需要用户参与。

适用情况二：全部验证——代扣代付支付。

代扣和代付类通道的特性是凭借卡号＋姓名就可以扣款或者付款，与快捷支付凭借协议号本质上一样，因为其不需要签约的特性，所以比快捷协议通道重试应用更广。在用户提交要素全部验证正确时，该通道可用。

适用情况三: 全部验证——无磁无密支付。

无磁无密支付的特性是每次都要单独验证卡信息。无论用户提交什么信息，只要与卡服务中拼出来的支付要素集合满足无磁无密支付通道要求就可以重试，因为如果要素信息有误，无磁无密通道会验证不成功，交易失败。

适用情况四：全都验证通道发送短信验证码

重试的宗旨是在安全的前提下让用户无感知，因此不管验证情况如何，只要交易环节通道需要发送短信验证码，都一律不参与重试，举例见示例2。

适用情况五：部分验证快捷协议支付

快捷协议凭借协议号或者Token就可以支付，在已有协议号的情况下，支付过程中不再验证卡要素。在用户提交的部分要素未验证的情况下，直接用协议号支付，会支付成功。为了避免此情况带来的后续拒付及安全性问题，不可用于重试服务。

适用情况六：部分验证——代扣/代付支付

代扣/代付通道特性前面已经介绍，不再赘述。由于无法保证要素正确性，它不可用于重试支付。

适用情况七：部分验证无磁无密支付

前面说过无磁无密的特性是会验证所有卡信息，所以可以使用部分验证情况。但需要注意，适用情况是，无磁无密通道支付所需要素包含用户提交的所有未验证要素。如果只包含部分未验证要素，那么遗留下来的要素可能就是错误的，所以不能用于重试。

适用情况八:部分验证——通道发送短信验证码

在适用情况四中已阐述不可用于重试服务的原因，这里不再赘述。

2.4.3 返回计算结果

路由将重试计算结果按照报文返回给上游调用方，这与之前讲过的路由类似。概括一下，返回的结果有两类。

一类是重试计算结果状态，比如重试成功、无可用通道、卡BIN 不支持等按照需要给出的返回原因。
另一类是返回具体的明细，比如重试结果可用的具体通道是什么、需要哪些验证要素、通道限额等，以便于支付引擎准备交易信息及上送交易。

一个重试服务是有效还是无效，是需要通过数据来体现的。表5-2和表5-3是日常工作中所用的表格，供大家参考。

博文参考

《支付方法论》