Smart Retry Integration Guide

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

Transactions:

---

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.

Sample request:

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)

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

Transactions:

---

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.

Sample request:

2. Redirect to SCA

To redirect the account holder for Strong Customer Authentication (SCA), initiate a server-to-server request. The shopper will authenticate to proceed with the payment completion. Follow these steps to facilitate the redirection:

• Interpret the JSON Redirect: Extract the redirect information from the response of the initial authorization payment.
• Use Redirect Response Parameters: Utilize these parameters with an HTML form to perform the shopper's redirect.

Redirect Response Parameters

Parameter	Description
url	The HTTPS URL for redirection, used as the form’s action attribute.
method	The form submission method, defaults to HTTPS POST.
parameters	Appended to the URL for HTTPS GET, or included in the body for HTTPS POST. For 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: