Guide to payment retries

Your customers want to buy. Your stock is ready for sale. Nothing should stand in the way. Except it does; glitches in payment technology can reject your customer’s credit card and the sale is lost. 

Unless your payment system automatically attempts a retry, that rejected transaction can turn off your customer.

We know that 45% of consumers won’t manually retry a payment following its failure. All the marketing, customer journey curation, and sales funnel investment goes to waste. Often due to preventable payment problems.

At scale, failed payments cost your business thousands, even hundreds of thousands of dollars. Potentially more.

What you need is a strong technical set up which minimizes the chances of rejecting legitimate payments. To increase the ratio of attempted versus successful payments, you must refine your payment retry strategy.

How do payment retries work?

If a transaction attempt fails, it can be automatically re-submitted. Sometimes this involves tweaking something about the initial transaction message to try and ensure it succeeds the second time around. Examples of such “optimizations” include adding in extra data fields or formatting the payment message in a different way.

Exactly how this happens depends on your retry logic, i.e. the rules you have assigned for declined payments to follow. You can also use a decision engine that runs on artificial intelligence to calculate the possibility of success for each payment retry.

Retry transaction fees

The merchant pays for every payment retry attempt. There is a fee to pay the payment services provider (PSP) for the use of their payment gateway, as well as the cost of scheme and interchange fees.

In addition, card schemes apply extra fees if too many retries are attempted within a 24-hour or 30-day period. Costs vary in the range of $0.10USD and €0.55, depending on the network, region, and the number of retry attempts made on the same transaction. Mastercard will increase its retry fee (per transaction after 35 retries within 30 days) to $0.50 from January 2025. 

That’s why you need to be particularly careful not to set your systems to automatically retry payments too aggressively. You need to carefully choose which payments to retry in order to maintain profitable payment processing. Let’s look at some reasons that payments can fail, and consider whether to retry these.

Why do online payments fail?

A payment request must pass criteria set by the cardholder’s bank (the issuer). There are plenty of reasons why the issuer rejects an attempted card payment.

Some payments must be rejected: insufficient funds, a strong chance of fraud or a blocked payment card. These payments cannot be “rescued” and should not be automatically retried. 

Let’s look at the most common reasons for failed payments and whether or not you should retry them:

Insufficient funds

The most common reason for payment failure is a lack of available funds in the chosen account. It’s possible to schedule payments for retry at a time when the customer is likely to have funds again (see section below “When to retry a payment”). 

Retry? Yes, but not immediately, and only for card-on-file transactions (as you need authorization to retry a payment as a merchant-initiated transaction).

Suspected fraud

It’s important you allow payment processors to block fraudulent card-not-present payments because your business will bear the financial loss of criminal card use. You’ll need to reimburse the customer as well as losing the product you sent to the fraudster.

There are a range of nuances in fraud detection, however, which mean the system can wrongly categorize a legitimate payment as fraud. So you need to investigate the decline codes you’re receiving, and analyze any patterns of fraudulent behavior within your payments. 

Retry? It depends. Refine your fraud filtering.

Blocked card

The issuer can reject a transaction attempt because the payment card is disabled. This can be temporary – such as a lost card that the owner has frozen, and may unfreeze later. Other reasons for a card block can include security concerns, such as suspected criminality or mismatched identity credentials. Or the bank may have closed the account (and therefore blocked the payment card) due to inactivity, missed payments, or simply because the account owner requested it.

Retry? It depends on the reason.

Learn more: Bank response codes explained

Best practices for payment retries

Done correctly, a payment retry can improve customer experience, strengthen customer loyalty, and increase revenue. This is because it prevents payment failure.

These are the essentials of designing your payment retry strategy:

Which payments to retry

You must only retry payments with a reasonable chance of success. That means focusing on one category in particular: false declines.

When a legitimate payment fails, it’s called a false decline. That means the customer had enough funds to cover the purchase, their card was not blocked, but somehow, somewhere, the payment technology failed.

It’s a significant problem. Over half (56%) of US shoppers had their payment declined during an online purchase in 2023. Research points to overly-zealous fraud prevention protocols causing false declines. Failing to access available network data about the cardholder can also contribute to outright payment failures.

Payment service providers (PSPs) can advise you on which payments are likely to succeed if you retry. For instance, Checkout.com provides Recommendation Codes to guide you on whether or not to submit a retry. That helps to convert the ambiguous “Do not honor” bank response code into a more practical course of action.

It pays to educate yourself on the reasons behind API response codes so you can figure out which payments are worth retrying. In some cases you will need to contact your PSP to gather more data on payment decline reasons.

‍“Do not retry” response codes

Some response codes mean you should not retry the payment. This indicates a “hard decline” which you can think of as a “firm no” from the bank. Response codes differ depending on the card scheme, adding complexity to their interpretation.

For instance, certain Visa response codes mean that there is no chance the payment can succeed (the issuer cannot accept it). One of these is 46, indicating the customer’s bank account is closed. So you should not reattempt the payment

In practice, some issuers will return “do not retry” codes for transactions which may actually be accepted on resubmission. It takes some detailed research and experimentation to work out which payments to retry based on their response codes. It’s best to work with an experienced PSP such as Checkout.com to figure out how to maximize transaction success.

When to retry a payment

Timing is a key factor in payment retries. The reason for the payment decline should dictate how and when to retry it.

For example, Visa response code 96 indicates a system malfunction. It’s possible the payment may succeed if reattempted. Further investigation into the problem should be investigated if multiple declines occur.

On the other hand, a payment declined for insufficient funds is not going to go through if you immediately retry it. Instead, you pay an extra fee with no hope of rescuing the transaction. It’s better to reattempt payment in a few days’ time.

You can undertake a process called “smart dunning” to schedule your payment retry attempts. This means the payment will be reattempted at the optimal time, based on all the data we have about that account. This only works for card-on-file transactions, as you need authorization to take payments from your customer. This can be automated and informed by machine learning to improve the chances of success on the second attempt. 

Alternatively, Checkout.com can help you configure dunning (merchant-initiated transaction retry) logic with our scheduled retries feature. You may choose to reattempt payment at the beginning of the next month, when payments of this type are more likely to succeed, on average. This use case is best suited to recurring payments, such as a gym membership or streaming service subscription. We have rescued 20% of payments entered into our dunning mechanism, contributing to hundreds of thousands of dollars in revenue uplift for our merchants.

What’s the difference between a refund, return, and retry?

Unless you’re thinking about payments all day, these terms can sound interchangeable and it’s easy to get them mixed up. Sometimes it appears the bank “takes back” a payment, and it’s confusing to figure out why. The main difference between a refund, return and a retry is in the journey the payment takes. 

A refund means the merchant initiates a new transaction with the customer, to reimburse them for a purchase amount (either fully or partially). By contrast, a return is a payment which is sent back in the direction it came from; it never reached the destination account in the first place. For example, a customer’s payment for their monthly water bill is returned due to insufficient funds. 

A retry is a payment which is reattempted after a failure (for a variety of reasons, including technical malfunction or because the cardholder canceled the first payment). For example, the water company may retry the bill payment a week after the initial failed payment.

ACH retry rules

You can retry failed ACH payments as well, also referred to as ACH Returns. The ACH retry must take place within 180 days after the settlement date of the original entry.

The Nacha operating rules refer to an ACH retry as a “Reinitiated Entry”. The Originator can reinitiate an entry up to two times if it was returned for insufficient funds (or uncollected funds). 

You can also resubmit an entry that was returned for stopped payment which the Receiver then authorizes for reinitiation. The third circumstance for reinitiation is if the Originator takes corrective action on the reason for the return.

Reinitiated Entries must be submitted as a separate batch that contains the word “RETRY PYMT” in the Company Entry Description field. The Nacha operating rules contain full guidance on ACH retries.