Smart Retries
Automatically retry payments with an alternative processor
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:
Cascading Retry - Re-attempting an authorization request to an alternate processor with the same or enhanced payload
Step-Up Retry - Re-attempting an authorization request to the same/different processors with additional authentication data (frictionless and challenge flows)
Clear PAN Retry - Re-attempting a tokenised authorization request with a Clear PAN in case of de-tokenisation failures
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
For each PSP all the published + encountered error codes are segregated in two categories “Retriable” and “Non-retriable”
This is a dynamic list and continue to grow for each PSP as they change their error mapping or introduce new errors
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.
Cascading retry
Refused, System malfunction, Processing temporarily unavailable
Step-up retry
3D Secure required, Strong customer authentication required, Suspected Fraud
Clear PAN retry
Invalid cryptogram, Network token not supported, Payment token expired
Network retry
Transaction not permitted on this network, Invalid card for selected network, Function not supported
Merchant config enablement
Merchant needs to be enabled across the required flows
Merchant can be eligible to all 4 or some of retry flows - Cascading Retry, Step-Up Retry, Clear PAN Retry, Global Network Retry
Merchant needs to specify N = Number of retries permitted
Retry Decision Flow
Payment fails → GSM lookup determines retry eligibility retry
Check retry flags:
step_up_possible → Attempt 3DS if no 3DS was used
clear_pan_possible → Retry with PAN for network tokens
alternate_network_possible → Try different debit network
Execute retry via do_retry() function retry with SAME or ENHANCED payload
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 [email protected] with the below information.
Confirmation on the retry flows to be enaled
Maximum number of payment retry attempts
FAQs
What is a primary processor?
Primary processor is the first choice of processor for the particular transaction to be processed. This is evaluated based on the smart routing rules configured in the Hyperswitch dashboard’s routing module.
Why can I not enable Automatic Retry from the Hyperswitch dashboard?
For reconciliation purposes, some merchants prefer having the same payment_id being passed to both Hyperswitch and the Payment Processors. Smart retry would not be feasible if such a use case exists. Hence, Smart retry is as an additional configuration that can be enabled only by contacting our support ([email protected]).
Since Smart retry involves multiple payment attempts for a single payment_id, Hyperswitch appends the attempt number to the payment_id that the merchant sends to Hyperswitch before passing it on to the processors.
For example, if the merchant had sent pay_abcd145efg, then Hyperswitch will send the following payment_id to the processors during each attempt:
Payment attempt 1: pay_abcd145efg_1
Payment attempt 2: pay_abcd145efg_2
Payment attempt 3: pay_abcd145efg_3
What will the user experience look like during Smart Retry?
The user experience will not be different from a regular checkout experience, since all retry attempts will happen silently in the background. However, there is a possibility of the user receiving multiple payment attempt notifications / sms from the card issuing bank due to the card payment being attempted for more than once.
What is the difference between fallback and smart retry?
Fallback is a pecking order of all the configured processors which is used to route traffic standalone or when other smart routing rules are not applicable for the particular transaction. You can reorder the list with simple drag and drop from the Routing > Default fallback > Manage section in the dashboard.
Smart retry is a feature to improve the chances of success of a payment by silently retrying with an alternative processor.
Last updated
Was this helpful?