Smart Retry

Smart Retry Integration Guide

Last updated:September 26, 2024
Embark on your journey with our Smart Retry Integration guide, designed to optimize your payment processing. Smart Retry intelligently routes transactions to the most suitable acquirers, enhancing acceptance rates and conversion. This guide will walk you through the seamless integration process, ensuring you can leverage the smart retry feature to automatically resend failed transactions and maintain uninterrupted payment flows. Start integrating Smart Retry today and transform your payment operations for greater efficiency and success.

Use cases

Fallback acquirer

The merchant initiates the payment authorization with Acquirer A and due to a soft bank reject the payment is automatically retried with the fallback Acquirer B.

How it works

Smart retry with the fallback acquirer

Retry the payment request with the fallback acquirer upon a soft bank reject.

OPTIONAL

Manage the payment

Send the back-office payment request to the fallback acquirer if the original payment was processed there.

Transactions:
DB - Declined
DB - Declined
DB - Retried
DB - Retried
RF
RF
CB
CB
CR
CR
RB
RB

1. Smart retry with the fallback acquirer

Initiate a server-to-server POST request with the required payment data. If the default acquirer is temporarily unavailable, the transaction is routed to the fallback acquirer. The response to a successful request includes an id that should be stored and used in subsequent back-office operations.

Simulating a Soft Bank Reject


To simulate a soft bank reject, use the card.holder parameter in your request with the appropriate soft bank reject code. Select the desired code from the dropdown below to correspond to the type of soft bank reject you want to simulate.
Simulate decline:

2. Manage the payment

Initiate a back-office server-to-server POST request over the authorized payment. If the original payment was processed with the fallback acquirer, the request will be handled by the fallback acquirer.
  • refund either the full captured amount or a part of the captured amount (see refund)
  • reflect the chargeback processed by the bank (see chargeback)
  • reflect the chargeback reversal processed by the bank (see chargeback)
Operation:

Sample request:

SCA upon fallback

The merchant initiates the payment authorization with Acquirer A and due to a soft bank reject the payment is automatically retried with the fallback Acquirer B. The fallback acquirer soft declines the transaction requesting for Strong Customer Authentication (SCA).

How it works

Smart retry with the fallback acquirer

Retry the payment request with the fallback acquirer upon a soft bank reject.

Redirect to SCA

Redirect the shopper to perform Strong Customer Authentication (SCA).

Get the payment status

Find out if the payment was successful.

Transactions:
DB - Declined
DB - Declined
DB - Retried
DB - Retried
DB - Retried
DB - Retried

1. Smart retry with the fallback acquirer

To simulate a smart retry to the fallback acquirer, initiate a server-to-server POST request with the required payment data. If the default acquirer is temporarily unavailable, the transaction is routed to the fallback acquirer. A Strong Customer Authentication (SCA) is requested if the fallback acquirer responds with an issuer soft decline.

Simulating a Soft Bank Reject

To simulate a soft bank reject, use the amount parameter in the request. Based on the specified amount, different types of soft bank rejects can be simulated. Additionally, to simulate a soft decline with the issuer upon a soft bank reject with the fallback acquirer, use the card.holder parameter with the value 300.100.100. Select the desired code from the dropdown below to correspond to the type of soft bank reject you want to simulate.

Simulate decline:

2. Redirect to SCA

Initiate a server-to-server request to redirect the account holder for Strong Customer Authentication (SCA). The shopper authenticates to advance with the completion of the payment. To facilitate this redirection, you need to interpret the redirect object from the response of the initial authorization payment. This redirect object, along with its parameters, will be used in conjunction with an HTML form to perform the shopper’s redirect.
  • url: The HTTPS URL for redirection, used as the form’s action attribute.
  • method: Defaults to HTTPS POST, determines form submission method.
  • parameters: Appended to URL for HTTPS GET, or included in the body for HTTPS POST. In the case of an HTTPS POST, each parameter will be a hidden input field in the HTML form.

3. Get the payment status

Once the payment request is processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.
resourcePath=/v1/payments/{id}

Handling Soft Declines After Smart Retry

In simulation setups, you might see a soft decline status (e.g., 300.100.100>) even after a successful 3D Secure (3DS) authentication and Smart Retry. This is normal and expected. The simulation is designed to test the Strong Customer Authentication (SCA) process, and the soft decline status helps verify that the retry mechanisms are working correctly. In real-world scenarios, a successful SCA would typically lead to a completed transaction.

Sample request:


See also