- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Sender
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- Release Notes
- API Reference
- Support
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.
Manage the payment
Send the back-office payment request to the fallback acquirer if the original payment was processed there.
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 anid
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.
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 theamount
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 yourshopperResultUrl
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: