Retrying declined charges

Enhance payment success with retry logic

If a card payment transaction (charge transaction) fails, it can be attributed to various reasons, such as insufficient funds. However, if the payment is unsuccessful, it is not always necessary to cancel the order and lose the payment. Instead, a retry payment attempt can be made using a payment token.

A payment token is a unique identifier generated during a charge operation to identify data (such as credit card information) for future transactions.

If the payment fails due to a network error or a decline from the issuing bank, a recurring request must be made using the token from the unsuccessful first attempt. This allows for a seamless customer experience and can increase the chances of a successful transaction, avoiding the loss of payment.

It is important to note that our product enables merchants to organize retry logic on their part.

Retry logic	Retry only card payments: Retry logic should exclude Guide Improve your checkout conversion by accepting payments via Apple Pay. Apple Pay and Guide Improve your checkout conversion by accepting payments via Google Pay. Google Pay transactions (those with the `CRYPTOGRAM_3DS` data type `google_pay_allowed_auth_methods`). A payment token is issued exclusively for successful Apple Pay and Google Pay payments, eliminating the need to retry these payment types. Limit on the number of retries: Retry logic should be configured with a limit on the number of retries to prevent infinite retries and unnecessary charges to the customer's payment method. The system must stop retrying the payment after a certain number of retries. The interval between retry attempts: To avoid overloading the issuing bank with too many requests over a short period (which may be perceived as fraud), retry logic should include a back-off time between retries, such as waiting a few minutes before trying again or increasing the time between retries as the number of failed attempts increases.
Decline reasons	Retry logic allows customizable retry rules only on specific error codes. For example, repeating attempts when receiving a permissible error code (incorrect card number) and, at the same time, analyzing/counting and setting limits on identical decline codes.
Customizable rules	Retry logic allows customizable retry rules, such as retrying only on specific error codes. For example, if the payment fails after several retries, it is desirable to have a way to cancel or refund the payment to avoid multiple deductions from the customer's payment method.
Declined transactions	Retry logic must specifically handle declined transactions, such as prompting the customer to update their payment information or offering alternative payment methods.
Notification	On the merchant side, it is necessary to additionally notify the customer of the result of the transaction, successful or unsuccessful.
Retry history tracking	This information can be used to analyze transaction patterns and improve retry logic. The merchant should have a system that can track the history of retry attempts for transactions, including the number of retry attempts, the time of each one, and the result.
*It is important to note that retry logic must be implemented with caution to ensure that the customer’s payment details are secure and to avoid any unexpected charges. Retry logic can improve the success rate of transactions and provide a better customer experience. It is always recommended to test and monitor retry logic in production to ensure it is working as expected.

Handling of decline reason

The system can include error handling mechanisms to handle errors during the retry process and ensure that the customer is informed of the issue and provided with an appropriate resolution. Merchants should identify the reason for the payment decline when it occurs. The reasons for payment declines may vary, including insufficient funds, expired cards, or invalid card details.

Here is an example of specific reasons for a declined transaction when there is still a chance of a successful payment:

Guide
The general group of declines. The card issuing bank did not complete the transaction successfully. 0.01 General decline
Guide
The customer’s card balance has insufficient funds. 3.02 Insufficient funds
Guide
The transaction has been declined by the card issuer. Reasons for decline can vary, including limits on online payments, daily payment amounts, or daily transaction counts. 3.04 Transaction is declined by the issuer
Guide
The issuing bank blocked the transaction due to possible fraud. 3.10 Suspected fraud
Guide
The card cannot be used to make this payment (it is possible it has been reported lost or stolen). 4.03 Restricted card
Guide
The acquiring bank blocked the transaction due to possible fraud. 4.05 PSP antifraud
Guide
An antifraud rule was triggered. 4.07 Trusted antifraud system
etc.

However, it is important to note that after the first attempt, the probability of a successful payment may decrease by up to three times.

Based on the reviewed statistics, we can recommend not retrying transactions for the following reasons:

Guide
The customer entered an incorrect card number. 2.08 Invalid card number
Guide
Card is expired. 2.09 Invalid expiration date
Guide
This transaction should only go through 3D. 3.09 3D-Secure authentication required

Consider retrying payment with 3DS flow.
Guide
The payment card being used is listed on a security blacklist, often due to prior suspicious or fraudulent activities. 4.01 Card is in a black list
Guide
The card in use is stolen, all transactions are restricted. 4.02 Stolen card
Guide
We received an invalid/nonexistent card token. 5.02 Invalid card token
Guide
Processing error. 5.08 Invalid transaction

If these data have not changed, the payment will still be unsuccessful.

Looking for help? Contact us

Stay informed with Changelog