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

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: