> ## Documentation Index > Fetch the complete documentation index at: https://docs.slm.m1amdocs.com/llms.txt > Use this file to discover all available pages before exploring further. # Retry Policy Retry policy is the mechanism to address transaction capture attempts (payment attempts) that failed. Typically, when a Transaction fails, capture attempts are made, while the subscription is still entitled and the user continues to receive service although was not successfully charged. The retry policy lets the merchant perform additional attempts at capturing the required payment, when relevant. The merchant-defined grace period sets the total amount of time a customer can receive the service without payment whether successful payment will eventually be captured or not. **The grace period should therefore be longer than the defined retry period.** Vindicia maps failed transaction response codes into two categories: soft failures (Decline) and hard failures (Reject). Hard failure transactions are never retried and soft failure transactions are retried. The retry cadence can be either fixed or custom. * Fixed Retry policy - use the merchant options configuration as explained in the table below. * Custom Flexible option - use retry decision rules for merchant-specific retry configuration such as: * Dynamic retry interval - see [Custom Retry Interval](retryPolicy#) below. * Rerouting retry attempts to different payment provider - see [Custom Retry Rerouting](decisionRulesRetryProviderRouting_r) below. ## Visa category codes * **Category 1**: Issuer will never approve transaction (reattempt not allowed) - Hard fail (Reject response) * **Category 2**: Issuer cannot approve the transaction at this time (reattempt allowed) - Soft fail (Decline response) * **Category 3**: Data Quality concern (re-validate data prior to reattempt) - Soft fail * **Category 4**: Generic response code (reattempt allowed) - soft fail (Decline response) Vindicia will attempt retry only for transactions with response codes in category 2, 3, and 4. In addition, to these categories the card networks rules also define that when re-attempt is allowed, there is a limitation of **15 attempts over 30 days**. This is not enforced by the system and is the merchant's responsibility to track.. When payment providers codes are used, merchants can decide to override their payment provider categorization of certain failures and define them as soft fails or hard fails . This is performed as part of the soft fail codes override section in the configuration page. Credit card networks update their policies periodically and it the merchant's responsibility to change or update their overrides accordingly. For more information on best practices for grace period, see [Grace Period Use Case](https://docs.vindicia.com/bundle/subscribeUseCases/page/topics/2803_r_manageGracePeriod.html). * **[Retry Merchant Options](../topics/retryPolicy#)** * **[Retry Behavior with Authorization Code Response Priority](../topics/retryPolicy#)**\ Retry Behavior allows you to determine the order in which authorization code responses should be used. * **[Custom Retry Intervals](../topics/retryPolicy#)** ## Retry Merchant Options Following are the fixed Retry policy merchant options: | Field | Required/Optional | Description | Valid values | | - | - | - | - | | RETRY\_STRATEGY\_ENABLED | Optional | Defines whether the retry strategy is defined using decision rules or the settings below (Default null). | Null (default)1- use decision rules | | CASHBOX\_FIRST\_RETRY\_DAYS | Required | Defines the number of days after a billing failure to process the first retry. When Retry Interval decision rule is defined, this setting can be overridden by the decision rules | Enter a number1 - default. 0 - retry on the same day. | | CASHBOX\_OTHER\_RETRY\_DAYS | Required | Defines the number of days between each retry attempt after the first retry. When Retry Interval decision rule is defined, this setting can be overridden by the decision rule . | Enter a number1- default. 0 - retry on same day | | CASHBOX\_MAX\_RETRIES | Required | Defines the maximum number of retry attempts to process. After this number, the system stops further attempts. | Enter a number1- default | | CASHBOX\_EXPIRATION\_OFFSET | Required | This is the general merchant-defined grace period, the period in which a subscription will continue to be entitled for service, although capture was not successful and customer did not pay for service. The grace period should be longer than the defined retry period. | Enter a number | | OPTIMISTIC\_ENTITLEMENT | | Calculate the entitlement as if all future billing events will be successful, so entitlements extend to the end of the billing plan period (possibly forever) from the start.In this case, we would only update them due to billing failure, subscription cancellation,or other such causes. Some merchants have a retry cycle that potentially lasts longer than the grace period for their entitlements (the cashbox\_expiration\_offset set in merchant\_options). For these merchants, if we end up in the situation where the next\_activity date for the current TransactionBilling (the one in Soft Error) is beyond the end\_date on the subscription, we want to end the entitlements at the end\_date, even in the "optimistic" case. | null 0,1 (default)**Note:** Recommended- leave as default (1). Use this field with care. | | ART\_RETRY\_THRESHOLD | N/A | Defines which attempt to process Retain **Applies to Subscribe merchants with Retain enabled (known as ART), not Retain Only merchants** | should be set to 0 | | Using the merchant options above you could define a **Retry interval**. It is composed of: | | | | Retry Interval = Max number of retries X Retry number of days where Max number of retries - define in `cashbox_max_retries` merchant option Retry number of days - define in `cashbox_other_retry_days` merchant option **Parent topic:**[Retry Policy](../topics/retryPolicy#) ## Retry Behavior with Authorization Code Response Priority Retry Behavior allows you to determine the order in which authorization code responses should be used. ### Authorization Response Codes Vindicia receives response codes that allow us to determine whether we can retry a transaction. These response codes can come from different sources and may not always be available. Vindicia supports the following response codes: * **Payment Provider Response (P)** - The default response code that is used and will always be available. The specific payment provider publishes these codes as part of their integration specification. The definition of hard fail vs. soft fail is taken directly from the payment provider integration specification. We store these codes in the SML database in the table **payment\_provider\_responses**. * **Merchant Advice Code (M)** - Based on Visa's guidelines, four categories are defined for Transaction processing and described below. Accordingly, some Payment Providers are adding their own specific Merchant Advice Codes. This is a short list of responses, with values such as **OK to Retry**, or **Do Not Retry**. These codes may also be referred to as Response Code Category. * **Network Response Code (N)** - These are the response codes from the credit card issuers such as Visa, MasterCard, Discover, and JCB. **Note:** Payment providers are slowly starting to provide the Merchant Advice Codes and Network Response Codes. By default, our payment provider integrations use Payment Provider Response to determine if a response indicates that the transaction can be retried (soft failure / decline) or if the Transaction should not be retried (hard failure / reject). Vindicia also considers two other types of response codes – Network Response Codes and Merchant Advice Codes. Merchant Advice Codes are supported across more payment providers than Network Response Codes. The benefit of using the Merchant Advice Code to determine whether to retry failed Transactions is that it gives us a new level of granularity to make the determination. For example, in some cases, the same Payment Provider Response can have different Merchant Advice Codes from the issuing bank. A `401` Payment Provider Response code can sometimes return a **Do Not Retry** Merchant Advice Code or an **Ok to retry**. ### Merchant Advice Codes per Payment Provider Merchant Advice Codes can be different for each payment provider. The following is a list of the response codes available for each payment provider that supports Merchant Advice Codes. | Response Code | Description | | - | - | | 1 | Issuer will never approve | | 2 | Issuer cannot approve at this time (Reattempt allowed) | | 3 | Data quality (revalidate data prior to reattempt) | | 4 | Generic response codes | | N | Response code not available/Failover/Error | | A | Approved transaction | | X | Non-Visa transaction | | Response Code | Description | | - | - | | 0 | No information or response not provided. | | 1 | New account information available | | 2 | Cannot approve at this time. Try again later | | 3 | Do not try again | | 4 | Problem with a token or a partial shipment indicator. Do not try again | | 5 | Payment blocked by card scheme | | 8 | Payment blocked by the payment card company | | 21 | Recurring payment cancellation service | | 99 | An unknown value was returned from the processor | | Response Code | Description | | - | - | | 1 | New account information available. Obtain new account information. | | 2 | Try again later. Recycle transaction in 72 hours. | | 3 | Do not try again. Obtain another type of payment from customer. | | 4 | Token requirements not fulfilled for this token type. Resubmit with proper cryptography. | | 21 | Do not try again. Issuer has blocked recurring payment transaction. | | 22 | Merchant does not qualify for product code. Obtain another type of payment from customer. | | 24 | Retry after 1 hour | | 25 | Retry after 24 hours | | 26 | Retry after 2 days | | 27 | Retry after 4 days | | 28 | Retry after 6 days | | 29 | Retry after 8 days | | 30 | Retry after 10 days | | Response Code | Description | | - | - | | 0 | No information or response not provided | | 1 | New account information available | | 2 | Cannot approve at this time. Try again later | | 4 | Problem with a token or a partial shipment indicator. Do not try again | | 8 | Payment blocked by the payment card company | ### Merchant Response Code Priority For supported Providers, merchants can set the priority order in which we consider these codes to determine if the failure is a soft fail (can be retried) or a hard fail (cannot be retried without a new payment method). The priority is set through `auth_response_priority` Name/Value Pair for merchants. The `auth_response_priority` Name Value Pair can be set in Subscribe Merchant Portal 1.0 using your admin account in **Admin** > **Merchant Configurations**. The order priority is read left-to-right, using the value for each type of code: * M for Merchant Advice Code * N for Network Response Code * P for Payment Provider Response Code A payment provider response will always be available, other code types may be available depending on the payment provider- see supported list below. For Name/Value Pair, include the supported payment provider as the name and for value, define the priority. | Name | Value | | - | - | | Paymentech:auth\_response\_priority | MNP | In this example, the priority for using hard/soft failure response codes for transactions processed with Paymentech would be : **Merchant Advice Code** > **Network Response Code** > **Payment Provider Response Code** The first match determines which code type is used. If there is no response code stored on the Transaction for that code type, the next response code type in order is considered. A Payment Provider Response is always available and is used if there is not a Merchant Advice Code or Network Response Code available. ### Payment Providers Supporting Auth Code Response Priority The following payment providers support the Auth code priority feature: | Payment Provider | Supports any order of | Name for NVP | | - | - | - | | Adyen | P, M, N | Adyen:auth\_response\_priority | | Braintree | P, M, N | BrainTreeMS:auth\_response\_priority | | Chase Paymentech | P, M, N | Paymentech:auth\_response\_priority | | CyberSource | P, M | Cybersource:auth\_response\_priority | | Orbital Stratus | P, M, N | Orbital:auth\_response\_priority | | PaySafe | P, M | PaySafe:auth\_response\_priority | | SmartPay | P, M | Smartpay:auth\_response\_priority | **Parent topic:**[Retry Policy](../topics/retryPolicy#) ## Custom Retry Intervals These decision rules enable to modify the retry interval defined in the merchant config rules above. To understand them, first read, [Configuration Method - Decision Rules](decisionRulesAbout). Since some banks cannot operate on weekends, we can configure the system to not retry on a weekend. Alternatively, we can configure to retry on a specific day of the week. The decision rule operates on the transaction object, and therefore can asses different values available through the transaction like: * The retry attempt number (transaction-index) - this allows you to define a different interval for the next attempt * The retry attempt number and day - if its the forth retry and original transaction submission took place on Monday, set next attempt to 3 days. **Remember:** Retry 1 will be on day of submission. * The transaction billing plan - you can set a specific retry policy per Billing plan - e.g for yearly plans try only once. | Merchant | Order | Example of rule | Description | | - | - | - | - | | A | 1 | IF \_.transaction\_index = 4 THEN ans = '1 days' STOP | The interval between the fourth and the fifth retry will be one day. | |   |   |   |   | | B | 2 | IF \_.transaction\_index = 4 THEN ans = (\{'Mon' => '5 days', 'Tue' => '5 days', 'Wed' => '5 days', 'Thu' => '6 days', 'Fri' => '4 days', 'Sat' => '4 days', 'Sun' => '4 days'}\{\_.billing\_day} \|\| '5 days') STOP | The interval between the forth and fifth retry, if original failed transaction was submitted on Monday, Tuesday, or Wednesday will be 5 days, if original submitted Trasaction was on Thursday will be 6 days and if was originally submitted on Friday, Saturday or Sunday - it will be 4 days. | | B | 1 | IF \_.transaction\_index = 3 THEN ans = (\{'Mon' => '6 days', 'Tue' => '6 days', 'Wed' => '6 days', 'Thu' => '6 days', 'Fri' => '6 days', 'Sat' => '5 days', 'Sun' => '6 days'}\{\_.billing\_day} \|\| '6 days') STOP | The interval between the third and forth retry, if original failied Transaction was submitted Monday, Tuesday, Wednesday,Thursday or Friday, will be 6 days, if original submitted Transaction was submitted Saturday, then 5 days and if submitted Sunday, 6 days | |   |   |   |   | | C | 4 | IF Entity::BillingPlan(id=@.autobill.billing\_plan\_id).merchant\_plan\_identifier = 'ONE\_TIME\_RETRY' THEN := 'OneRetryOnly' | If the billing plan for this transaction is "One\_Time\_Retry" go to the label on row 1 | | C | 3 | IF \_.transaction\_index \< 7 THEN ans = '6 days' STOP | For all retries up to the 7 retry, set the retry interval for 6 days | | C | 2 | IF \_.transaction\_index = 7 THEN ans = '1 days' STOP | After retry 7 set the retry interval for one day | | C | 1 | :OneRetryOnly IF \_.transaction\_index = 1 THEN ans = '2 days' STOP | This will be executed only for billing plan 'One\_Time\_Retry' and will set the retry interval to 2 for the first retry | **Parent topic:**[Retry Policy](../topics/retryPolicy#) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.