Skip to main content
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:

​
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.

​
Retry Merchant Options

Following are the fixed Retry policy merchant options: 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

​
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.

​
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. 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: Parent topic:Retry Policy

​
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. 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.
Parent topic:Retry Policy