Smart Retries

Smart retry is a Hyperswitch feature to improve the payment success rates in a single or multi-processor setup. If the payment fails through the primary processor due to specific reasons, the payment will be retried with the same or an alternative payment processor to increase the chances of making the payment successful.

The Auto Retry engine handles varied Retry strategy based on the type of error encountered such as:

1. Cascading Retry - Re-attempting an authorization request to an alternate processor with the same or enhanced payload
2. Step-Up Retry - Re-attempting an authorization request to the same/different processors with additional authentication data (frictionless and challenge flows)
3. Clear PAN Retry - Re-attempting a tokenised authorization request with a Clear PAN in case of de-tokenisation failures
4. Global Network Retry - Re-attempting an authorization request with a signature network in case of debit network failure

Hyperswitch’s error handling engine is enriched with mappings for error codes and error messages across 100+ processors, acquirers, issuers. Processors have anywhere between 400 to 1,000 and at times more error codes. The database contains these combinations of error code and error messages for every processor and is constantly refreshed with newer codes that are encountered.

Error code segregation

1. For each PSP all the published + encountered error codes are segregated in two categories “Retriable” and “Non-retriable”
2. This is a dynamic list and continue to grow for each PSP as they change their error mapping or introduce new errors
3. We’re also implementing a feedback loop from “Non-retriable” errors to “Retriable” errors basis retry exploration (bottom branch on the image above)

Each of the error codes are mapped individually as to whether they are eligible for the various retry capabilities.

Merchant config enablement

1. Merchant needs to be enabled across the required flows
2. Merchant can be eligible to all 4 or some of retry flows - Cascading Retry, Step-Up Retry, Clear PAN Retry, Global Network Retry
3. Merchant needs to specify N = Number of retries permitted

Retry Decision Flow

1. Payment fails → GSM lookup determines retry eligibility retry
2. Check retry flags:
   1. step_up_possible → Attempt 3DS if no 3DS was used
   2. clear_pan_possible → Retry with PAN for network tokens
   3. alternate_network_possible → Try different debit network
3. Execute retry via do_retry() function retry with SAME or ENHANCED payload
4. Exhaustion handling → Stop when retries/connectors depleted retry

How it all comes together

Use Case 1

Use case 2

Use case 3

Use case 4

Use case 5

User Consent-based Retries: These retries are applicable for payment flows that need an additional level of user authentication (example: Apple Pay, Google Pay, 3DS cards, bank transfers). Such payment flows need an additional authentication from the user. Hence smart retries are not possible for such scenarios.

How to enable Smart Retries?

Step 1: Ensure that you have enabled the pecking order of payment processors on the Hyperswitch dashboard. You can access the settings from Routing > Default fallback > Manage.

Step 2: Drop a request to hyperswitch@juspay.in with the below information.

• Confirmation on the retry flows to be enaled
• Maximum number of payment retry attempts

#

FAQs