Cascading payments are one of the modern payment systems’ essential features. It is a technology that can reduce declines and increase your approval rate. For merchants working with several acquirers, cascading can be especially important because it helps recover transactions that might otherwise be lost.
This article explains what payment cascading is, how it works, its value for efficient payment processing, and how it helps merchants and PSPs recover declined payments and grow revenue.
What are cascading payments, and why do they matter for revenue growth?
Cascading payments refer to a technology that automatically sends a declined or failed transaction to another acquirer or Merchant Identification Number (MID), one after another, during the same checkout session, so that the payment can be completed. Suppose the payment software provider does not offer cascading. In that case, the bank or payment provider can simply decline the transaction due to internal rules, such as a blocked countries list, or the transaction can fail because of a technical error at the moment of processing.
It gives the customer the choice: to enter their payment data once more with the risk that the payment will be declined a second time, or to leave the shopping cart and choose another site to order the goods or services from instead. Many customers choose the second option. According to a 2023 Checkout.com study conducted with Oxford Economics, 45% of consumers abandon a purchase rather than retry after a false decline, and 42% say a failed payment would make them shop elsewhere.
As a result, declined transactions hurt revenue growth and ruin the customer experience. Fortunately, modern cascading technology can recover a significant number of declined transactions. Let’s check out how it works!
How do cascading payments work?
Cascading technology comes into play after the transaction has been directed to the MID or acquirer, but, for some reason, the payment did not pass through. Its principal function is to automatically cascade the payment to another payment solution, and to the next ones on the list up to the attempt limit, to complete the transaction processing successfully during the same checkout session with no change in payment method for the end user.
In general, the process looks like this:
- Smart routing sends the transaction to the MID or acquirer that suits it best.
- The payment is declined by the issuer or the acquirer, or fails for a technical reason, and the system receives a decline or error code, or no response in time.
- The system checks this code against the cascading rules to see whether the transaction can be sent further.
- If it can, the transaction is cascaded to the next MID on the list with the same payment data, so the customer does not need to re-enter their card details.
- The cascade goes on until one of the MIDs approves the payment, a MID returns a decline code that cannot be cascaded, the attempt limit is reached or the list of MIDs runs out. Only then does the customer see a decline.
Now that we have examined the fundamentals, let’s look at how this technology works for different types of decline.
Hard declines
If a hard decline occurred, the transaction was rejected by the customer’s issuing bank. It means that the rejection is permanent, and this payment method cannot be processed by another payment provider as a card was reported as stolen or lost, expired, etc. Thus, cascading the payment to other payment connectors is useless since a transaction cannot be processed successfully under any terms. Visa does not allow reattempts on Category 1 (“Issuer Will Never Approve”) declines, and Mastercard prohibits retries after Merchant Advice Code 03 (“Do Not Try Again”).
Soft declines
If there was a soft decline, the error occurred on either the acquirer’s or the issuer’s bank side. If the problem is on the acquirer’s side, the transaction may be approved by another acquirer. Thus, cascading technology would cascade the transaction to another MID without any extra steps for the end user. Although in some cases the backup acquirer’s processing fee may be higher than at the initial MID, you will have the opportunity to complete this transaction smoothly, ensure your users have a pleasant experience, and encourage them to return in the future.
The issuer, however, stays the same, as it is defined by the card. So if the issuer itself declines the payment, another route will often not change its decision. Some issuer soft declines can still be approved through another acquirer, so the cascading rules should define which issuer codes are worth one more route. Other cases are better handled with retries, and we explain them in our article on decline codes and retry timing.
Technical errors and provider downtime
Sometimes a transaction is not declined at all but cannot be processed because of a technical problem, such as a timeout, a gateway error or an outage on the acquirer’s side. In this case, cascading works as a failover mechanism. The payment is automatically transferred to the next MID, so customers can still pay even when one of the payment providers is down.
3D Secure (3DS) transactions
If the transaction requires 3D Secure (3DS) authentication, payment software providers offer a different cascading mechanism than described above to transfer it to another acquirer or MID. Different payment software providers handle this in different ways, and there are two common approaches.
When cascading a transaction from one 3DS MID to another, some payment providers require customers to enter their payment information all over again. In turn, the merchant must resubmit the transaction processing request to their software vendor. In this situation, although the payment is cascaded and processed successfully, the customer takes the same actions as if the payment has failed, which takes plenty of their time and ends in a negative customer experience.
Alternatively, payment software providers like Akurateco offer 3DS MID cascading in which the customer does not re-enter their card details. If the next MID needs a new authentication, they confirm the payment with their bank once more, for example by entering a new one-time 3DS code. Akurateco transfers the payment data to the next MID on its side, so the merchant does not have to resubmit the processing request either. The switch between MIDs itself happens in the background, so instead of a failed-payment message and an empty checkout form, the customer sees one extra authentication step at most. This gives them less reason to abandon the purchase or decide that the payment has failed.
iFrame
Some websites and applications accept payments via the iFrame widget. To avoid redirecting customers to a third-party payment page, merchants embed it within their own websites in a small window. In this way, customers’ sensitive payment data is collected on the payment service provider’s (PSP’s) end, not the merchant’s, which reduces the merchant’s PCI DSS scope, although it does not remove PCI DSS obligations completely. However, iFrame functionality is limited when it comes to redirects.
The cascade itself runs on the server side, so the customer does not re-enter card details. However, 3DS authentication data includes the acquirer and merchant details used in the authentication request. Another acquirer may not accept it. When a transaction is cascaded to such a MID, a new 3DS authentication may be needed. The issuer decides whether it passes without customer action or requires a challenge, which the customer has to complete during the same checkout session.
There may be compatibility issues between different iFrames used by various payment processors, which can cause technical difficulties in payment processing. Redirects are another weak point. EMV 3DS challenges can be displayed inside an iFrame, but depending on the integration, the customer may still be redirected to the bank’s authentication page. In addition, some providers and payment methods do not support iFrames and switch to a full-page payment page instead.
To sum up, although the iFrame widget is used for transaction processing, its functionality is limited regarding 3DS transactions, cascading, and redirects, which can negatively impact customer experience and conversion rate.
Cascading vs smart routing and retries
Smart routing and cascading payments go hand in hand. Smart payment routing is a technology that is configured according to specific parameters by the merchant or PSP so that each transaction is sent to the payment provider that suits it best. To identify the best bank or payment provider for each transaction, the technology chooses a group of providers that will best suit each group of transactions according to several parameters (e.g., card brand, issuing country, currency, amount or provider performance), so that each transaction can be potentially processed by several solutions that correspond to these parameters. Thus, if one of the suitable providers declines the payment with a decline code that allows cascading, the payment can be automatically sent to the next provider in the group.
Retries are a different tool. A retry sends the same transaction through the same route again after some time, so it is used when the problem is temporary and lies with the card or the issuer. If the decline is caused by the route itself, cascading to another MID is usually faster than waiting.
| Method | What it decides | When it acts | Typical trigger |
|---|---|---|---|
| Smart routing | Which acquirer or MID gets the transaction first | Before the first attempt | Parameters set by the merchant or PSP |
| Cascading | Which MID to try next | Right after a decline or error, during the same checkout session | Acquirer-side declines, a timeout, or an outage |
| Retry | When to try the same route again | Later, as a new attempt | A temporary problem with the card or the issuer |
Payment cascading: the main benefits
Decreased number of failed transactions
Cascading minimizes the number of declines. Payment attempt failure is among the top reasons customers abandon their carts and do not return to the website in the future. By distributing declined transactions between multiple channels and processing them successfully, cascading increases the approval rate for merchants and PSPs.
Pleasant user experience
The technology provides a smooth payment flow and a pleasant user experience for merchants and their customers. The main benefit for merchants is that when a payment request is forwarded from one MID to another, they do not need to control this process, as their payment solution provider handles this independently.
Revenue growth
Cascading acts as one of the main revenue growth factors for merchants. With an increase in the number of approved transactions, merchants’ profits grow, and their customers are more likely to return repeatedly. In turn, payment service providers also benefit from a positive merchant experience, as their modern payment solution meets their needs and benefits their brand image and sales in the long run.
Cascade rules to set before going live
Cascading is important for modern payment processing. However, how it is configured also plays a critical role. Before launching cascading, merchants and PSPs should define the following rules:
- which declines can be cascaded: acquirer-side declines and technical errors, plus selected issuer soft declines;
- in which order the MIDs are used, if needed separately for different card brands, countries or currencies;
- how many attempts are allowed for one transaction;
- which fee level is still acceptable, so the transaction is not cascaded to a MID that is too expensive;
- how timeouts are handled, so the customer is not charged twice (for example, checking the transaction status with the first acquirer before cascading, reversing it if the status cannot be confirmed, and keeping one merchant order ID across all attempts);
- how card scheme limits on reattempts apply, counting cascade attempts towards them unless the acquirer confirms otherwise;
- which reports are needed to see which MIDs recover declined payments.
Thus, cascading can increase the number of approved payments, not just the number of attempts.
How Akurateco handles payment cascading
At Akurateco, we have developed our cascading to work efficiently, considering users’ needs, including 3DS MIDs. Akurateco does not process transactions itself. We provide the gateway and orchestration layer on top of acquirers, and cascading works across the acquirers and PSPs our clients connect from 700+ integrations. Clients can set the cascade order, the decline codes that trigger it, and the number of attempts themselves.
Enterprise merchants use cascading as part of our payment orchestration, while PSPs running our white-label payment gateway can set it up for their own merchants.
Cascading Payments FAQ
What is the difference between cascading and retrying a payment?
With a retry, the same payment is sent through the same acquirer again after some time. With cascading, the payment is sent to a different acquirer or MID right away, during the same checkout session. Retries help when the problem is temporary and lies with the card or the issuer, while cascading mainly helps when the decline is caused by the route itself.
Can payment cascading cause a double charge?
It should not, if timeouts are handled correctly. The main risk is a timeout. The first acquirer approves the payment, but the response does not arrive in time, so the payment is cascaded to another MID and approved again. To prevent this, the system checks the transaction status with the first acquirer before cascading and reverses the first attempt if its status cannot be confirmed. Keeping one merchant order ID across all attempts also lets the platform spot a duplicate approval and cancel it.
Which declines should not be cascaded?
Hard declines should not be cascaded. If the card was reported as lost or stolen, has expired, or the account is closed, no other acquirer will approve the payment. Besides, repeated attempts on such cards can break card-scheme rules on authorization retries. Cascading is worth using for acquirer-side declines and technical errors, plus selected issuer soft declines.
Does cascading work with 3D Secure?
Yes, a 3DS transaction can be cascaded from one 3DS MID to another. However, the customer experience depends on the platform. With some providers, customers have to enter all their card details again, while with Akurateco they do not re-enter their card details and, at most, enter a new one-time 3DS code, and the switch between MIDs happens unnoticed in the background. If you accept payments via iFrame, 3DS redirects need extra testing.
Is payment cascading the same as failover?
Not exactly. Failover is one of the cases where cascading is used. In failover, the payment is moved to another MID because of a technical problem, such as a timeout, a connection error, or an acquirer outage, and not because of a decline. Cascading covers both situations, so the same mechanism keeps payments going in both cases.
