Retry Flow

The online and offline retries flows differ mainly on when the execution of retries are performed to the acquirers.

Online Retry Flow

In the online retry flow, the retry is performed during the transactional flow of paymnent and up to two retries are performed.

This retry flow allows you to set up retries that use more then one acquirer. If the retry is performed on more than one acquirer, it is necessary that your store has a contract with the desired acquirerers, and it must be registered accordingly in Carat Portal.

There are differences between the REST and HTML interfaces that will be detailed in the following sections.

REST Interface

Flux description:

1. The need or possibility of a retry will be evaluated after each response.
2. At the end of the process, the Merchant will receive the final response and will communicate it to the Buyer.

HTML Interface

Flux description:

1. First, the Buyer will request a checkout to the Merchant.
2. The Merchant will initiate a transaction with Carat Portal and will receive an URL to which the Buyer must be redirected.
3. The Buyer will interact directly with Carat Portal and will inform the payment data.
4. With the payment data, Carat Portal will start its payment tries. Every retry response returned, Carat Portal will evaluate if another retry is needed or possible.
5. At the end of this flux, Carat Portal will send a status notification to the Merchant and the Buyer will receive the final response.

Offline Retry Flow

In the offline retry flow, the retries are scheduled to run at a later time, and the payment response is "pay in process" with status RET.

If the offline retry is successful, the transaction changes status from RET to CON.

The retries are scheduled according to the configuration defined per routing:

• Maximum number of retries;
• Interval between retries (in days).

By default, 3 (three) retries will be performed with a one-day break between them.

To enable this functionality and change the default configuration, contact the Carat Portal production team.

Unlike the online retry flow, the offline retry flow can't perform the retry with more than one acquirer.

In this retry flow, the Merchant must estabilish agreements with the Acquirer to enable payments without the card security code.

There are differences between the REST and HTML flows that will be detailed in the following sections.

REST Interface

Flux description:

1. On the first try, Carat Portal will evaluate if an offline retry can be performed. If it does, Carat Portal will send a response with the transaction status RET to the Merchant and schedule the retry.
2. The retry is scheduled according to the configuration defined for the type of payment, on the day it was created. If the offline trial was created in one day and then the interval and / or quantity setting was changed, the old configuration will be kept.
3. The retries are attempted daily by Carat Portal.
4. At each retry response, Carat Portal will send a status notification to the Merchant and will evaluate if another retry is needed or possible. If the end of retries is detected, the transaction status RET is changed accordingly the last retry response.
5. At the end of each retry response, Carat Portal send a status notification to the Merchant.

HTML Interface

Flux description:

1. First, the Buyer will request a checkout to the Merchant.
2. After that, the Merchant will initiate a transaction with Carat Portal and will receive an URL to which the Buyer must be redirected.
3. The Buyer will interact directly with Carat Portal and will inform all his/her payment data.
4. With the payment data, Carat Portal will evaluate if an offline retry need to be scheduled. If it does, Carat Portal will send a processed payment response to the Buyer and will send a status notification RET to the Merchant.
5. The retry is scheduled according to the configuration defined for the type of payment, on the day it was created. If the offline trial was created in one day and then the interval and / or quantity setting was changed, the old configuration will be kept.
6. The retries are attempted daily by Carat Portal.
7. At each retry response, Carat Portal will send a status notification to the Merchant and will evaluate if another retry is needed or possible. If the end of retries is detected, the transaction status RET is changed accordingly the last retry response.
8. At the end of each retry response, Carat Portal send a status notification to the Merchant.

Important:

The customer can combine the use of Online and Offline retries. In this scenario, the offline retries flow will start if all the online retries are denied.