“重试服务”的定义为：已有要素（用户此次提交和系统之前已存储要素）在准确性得到验证的基础上，根据返回原因确定决策交易是否可以再次支付，以提升用户体验、挽回成功率的机制。
重试服务由两部分组成：重试规则建立和重试规则匹配。重试规则匹配的基础就是重试规则的建立，服务根据建立的规则内容进行匹配。匹配成功，参与重试；否则不参与。
重试规则的建立其实是配置规则的建设，规则分为两类：一类是内因，一类是外因。内因是自身的限定，比如重试次数、重试时间、参与重试商户、参与重试交易类型的约束；外因是通道响应码的处理，比如枚举哪些响应码可以参与重试，哪些响应码不可以。
1、重试规则的关键项
我们通过下面的配置示例来了解重试规则里有哪些关键项。
1）规则号：001。每个重试规则有唯一的编号。
2）商户号：m0000001。设定规则适用的具体商户，可以为空。不是每个商户都要单独设立规则，商户号为空代表采用该商户对应的行业规则。
3）行业类型：旅游。设定规则适用的具体行业，可以为空。如果不设置商户，则代表对整个行业适用；如果同时存在该行业下的具体商户规则和该行业通用规则，以具体商户规则为准。
4）支付通道：农行直连通道。配置具体交易失败后能够重试支付的通道范围，也就是只有这些通道交易失败才可以重试。
5）支付品牌：农业银行信用卡。配置具体交易失败后能够重试支付的品牌范围，也就是只有配置的支付品牌交易失败才可以重试。
6）币种：CNY。配置参与重试服务的币种。
7）交易类型：消费。配置参与重试服务的交易类型。
8）适用响应码：01、02、03。配置该支付通道参与重试服务的响应码。响应码的配置取决于重试服务的设计思路：如果偏向保守，采用白名单设计思路，那么只有返回的是配置的响应码，交易才能重试；如果偏向激进，采用名单设计思路，那么只要返回的是配置之外的响应码，交易均可重试。
9）适用渠道：线上、App。商户或者行业存在多渠道应用，该项配置重试规则适用的渠道范围。
10）流量控制：100%。配置重试规则在一定条件下适用的流量比例，可用于对比效果、验证可用性。
11）允许重试次数：3次。配置一笔支付允许订单重试的次数。出于用户体验的考虑，即使支付通道足够多，也不应无休止地重试。因为每次重试都需要各服务重新握手、交互信息，重试次数过多会让用户等待时间过长。
12）系统等待最长时间：10s。配置重试服务最长等待时间。前面配置了重试次数，这项进一步明确限定了时间。
13）是否开启：开启。配置规则有效状态。
14）生效时间：2019.01.01-2020.01.01。配置规则有效时间。
上面列举了商户m0000001关于农行信用卡可以重试的规则，大家可以结合自己实际遇到的场景，试着列出几个规则，加深对重试服务规则的理解。
2、重试服务原则
除了重试规则的具体内容外，重试服务还有一些原则。
原则一：参与对象一般只有银行卡类交易。
我们知道支付品牌里存在的对象包括银行信用卡、借记卡、账户类支付（各类钱包，如微信、支付宝、电商自有账户等）、储值卡等。
通常账户类支付和储值卡的支付通道是唯一的，没有备份通道，为了避免后续路由进行无用计算，在重试规则这里就直接只配置支持银行卡类交易。
原则二：鉴权类交易、风险类订单交易、人工置失败交易、出款类交易不参与重试。
失败订单场景有这几类：鉴权类交易、风险类订单交易、人工置失败的订单、无风险客户的扣款交易、无风险客户的出款交易。重试交易的原则是在保证交易安全的前提下，客户主观希望交易成功。在这个原则下，对于参与重试的交易种类是有限定的。
鉴权类交易本质上是为了验证信息的准确性，不管是信息不对还是服务异常等原因，都不会进行重试服务。这主要是出于谨慎性原则考虑。各家通道进行鉴权交易背后验证的逻辑可能会不一样，有些通道会存在验证要索不全面的情况。
举个例子，一笔鉴权交易需要验证五要素，有A、B两个通道均支持此交易，这笔交易同时上送给这两个通道进行验证。验证结果是：
A通道返回结果“验证正确”，B通道返回验证结果“验证不正确”。
为什么会出现这样的结果？情况可能是。一家验证的是实时数据，另一家验证的是自身系统历史数据。
鉴权和支付交易一样，在进行交易受理时，通道背后的服务商会收取通道方手续费。出于节省成本考虑，通道方会先与自身系统存储数据（之前验证过正确、存储在系统中的数据）进行比对。如果自身系统中存在此数据，与请求的鉴权数据也能够完全对上，那么通道就不会查询公安、银行等外部权威渠道的数据。
如果用户修改过姓名或者手机号码，在银行的数据已经发生过更新，但是B通道保存的数据还是原有旧数据，A通道用的是实时数据，每一笔鉴权都查询内外部最新的数据。那么此时哪怕用户的数据完全真实且正确，但结果会像上面所说那样：A通道返回结果“验证正确”，B通道返回“验证不正确”。但事实上，B的结果是错的。
反过来，如果A通道存储的是用户旧数据，B通道用的是实时数据，此次请求用户上送的数据是旧数据。结果A通道“验证正确”，B通道“验证不正确”，而事实是A通道验证的结果是错的。
由于验证处理机制存在差异，会出现不同的验证结果，而商户或者支付平台作为调用服务方是无法知道背后通道的处理逻辑的。所以对于鉴权通道，要在合同签署时要求支付通道对于其准确性承担责任。另外出于谨慎性安全考虑，鉴权类交易是不参与重试的。
另外，如果是网络掉线等原因，在通道层面有正常的补偿机制进行处理，不需要调用重试服务。
风险类交易本质上是为了加强验证或者进行拦截，也是不参与重试服务的。对于风险类交易，安全是优先级最高的，成功率与成本都是次要考虑因素。对于这类交易，会让用户进行更多要素的验证，或者转移到风险交易包赔的支付通道上。如果对于风险类交易也进行重试服务，不能达到验证更多要素或转移风险的目的。
人工置失败类交易本质上是出于某些考虑而人为将订单置为失败。人工置失败的原因可能是系统自动退款超过退款时间，客户无法操作，要平台人工操作；可能是对账后发现账单不对，要进行差账处理等。不管是什么原因，目的都是让订单无效和失败，如果这类订单失败了还要重试，就与目的相反了。
出款类交易是把资金款项付到客户账户，一旦资金进入客户账户，付款人就失去了对资金的控制权。如果此类型交易重试，会存在重复出款多笔的可能，进而造成资损。所以针对出款类账户交易方向的特性，基于保证安全及避免资损的考虑，出款类交易是绝对不允许重试的。
原则三：参与重试通道响应码有要求。
重试服务是在安全的前提下对能够通过重试挽救的订单进行重试，以提高成功率。基于这个目的，不安全的不能进行重试，明知道不成功的也不会进行重试。那么系统里不参与重试的通道响应码有哪些？枚举如下。
1）短信验证码错误。
2）有效期错误。
3）卡过期。
4）无效。
5）卡状态异常。
6）卡余额不足。
7）卡信息有误。
各家公司由于对风险交易的容忍程度、对成功率的看重程度和公司的行事风格都有差异，所以制定的重试服务对于响应码的具体规则也有差异，分成了黑名单、白名单两种指导规则。
黑名单方法是列出绝对不能进行重试的通道响应码，除所列出响应码之外的交易都可以进行重试。这样的好处是配置工作量较少，适用范围广；缺点是存在出错可能，因为通道响应码是会不定期更新的，且可能更新没有通知到商户或者支付平台。
如果新增的响应码属于名单响应码种类之一，此类响应码是不可以参与重试的。但由于之前黑名单重试规则库里没有配置此响应码，就会对此类不能重试的交易也进行重试，从而造成用户投诉、欺诈交易和资损可能。
名单方法是列出能够进行重试的通道响应码，除所列出响应码之外的交易都不能进行重试。这样的好处是安全性高，保证每一笔重试的交易都是符合原则的；缺点是配置大，适用范围小，通道中白名单响应码占比大，每个通道都有几十上百个响应码。在进行重试规则设定时需要占用大量的内容配置工作。
因为只能在配置的白名单响应码中应用重试服务，通道响应码即使如黑名单案例一样没有及时配置，其结果只会少挽回一些交易，但不会造成过错，使得不能重试的交易进行重试，从而造成用户投诉、欺诈交易和资损可能。
原则四：重试服务上送新通道之前，原则上原通道交易需要有个终态结果。
除了通道返回交易失败外，重试服务发生的场景还有系统间交互异常等原因造成的信息丢失，获取不到交易结果等失败。
交易中存在补偿机制，有查询、冲正、退款。这里特别说明，重试服务并不是这些服务的替代。原有的补偿机制依旧存在，需要先进行原有补偿机制处理，如冲正作废原交易或者查询原交易失败后再进行重试，否则很容易造成订单混乱、清结算账单对不平等问题。
以上是重试服务的设计，用来判断一笔交易能不能重试，后续选择重试通道还需要路由服务的参与。
