When a customer-initiated transaction (CIT) gets declined, it’s more than just a bump in the road—it’s a missed opportunity and a source of potential frustration for your customers. For merchants, it’s not just about losing a sale; it’s also about managing the repercussions of an incomplete transaction.
But don’t worry—a declined payment isn’t the end of the story. You can often recover these payments and turn the situation around with the right strategies.
In this article, we’ll explore why CITs fail and reveal effective fallback solutions to help you recover lost revenue and keep your customers satisfied.
Decoding payment declines
Payment declines can happen for various reasons, from technical glitches like network outages or misconfigured gateways to simpler issues such as expired cards, incorrect card details, or suspected fraud.
Learn more in our blog exploring payment declines.
These declines fall into ‘hard’ and ‘soft.’
A hard decline happens when the issuing bank outright rejects the payment due to an unsolvable issue like a stolen card. A soft decline, on the other hand, is a temporary authorization failure where a glitch in the process causes the transaction to fail. Merchants can retry soft declines to try and recover the transaction.
Our network data reveals that approximately 25% of payment declines are soft declines, presenting a significant opportunity for merchants to retry these transactions and recover revenue.
What is a fallback?
A fallback, also known as a cascading payment, is a strategy where you retry a failed payment immediately through the same, or an alternative processor to secure a successful authorization.
This is a powerful tool for merchants, especially since, as we mentioned, most payment failures are soft declines—meaning there’s a good chance they’ll go through if you try again.
Many of our merchants using Primer’s Fallback solution are seeing impressive results, with an average recovery rate of 20% when immediately retrying payments with an alternative processor. That’s a significant boost that directly impacts the bottom line.
Take Banxa, for example. In the first six months of 2024, it recovered over $7 million in revenue using Fallbacks.
Considerations when building a fallback strategy
Implementing a fallback strategy is often a no-brainier, but there are still a few key considerations to keep in mind.
First, are you working with multiple payment processors? As mentioned, a fallback strategy typically involves retrying a payment with an alternative processor. While some merchants attempt fallbacks with the same processor, the success rate is lower—around 9% on average when using an alternative merchant account and 2% when the same merchant account.
.jpeg)
You’ll also need to consider the costs involved. Depending on your payment service provider, a fallback is usually treated as an additional payment request, which can incur extra costs. The key is finding the right balance between maximizing potential recovery and managing the cost of retrying a payment, which could still fail.
This balance is unique to every business. Some merchants choose to attempt fallbacks on every soft decline—and even hard declines, but this is not recommended—while others are more selective, retrying payments based on specific decline codes.
Latency is another crucial factor. Rerouting a transaction to another processor using fallbacks adds to the time a customer spends waiting to see if their payment is successful. While this might only add a fraction of a second—which likely won’t be noticeable—in cases where additional checks like 3DS are involved, it could take a few seconds. And in those few seconds, a customer might refresh the page or abandon the payment altogether.
Why do merchants use Primer for fallbacks
Primer’s fallback functionality is one of the key reasons merchants choose us. We make it incredibly easy for any business to use fallbacks to recover revenue.
Setting up a fallback is straightforward and takes just a few clicks. You can create a payment workflow, add an authorization action, and configure exactly how you want to route a payment—including selecting a fallback processor. Simply choose your fallback processor from your existing connected processors and assign a merchant account.
And that’s it. When a qualifying payment fails, it will automatically be retried through your selected alternative processor.
It’s that simple because of Primer’s extensive work behind the scenes. We’ve developed a unified decline code mapping standard that standardizes decline codes across all your processors, so you don’t need to build complex logic yourself.
We also use the term ‘qualifying payment’ because our extensive data set targets transactions with a high likelihood of successful authorization through an alternative processor. This approach reduces the chances of incurring costs for retrying payments that are likely to fail.
And finally, with our agnostic 3DS solution, you don’t have to worry about latency affecting the customer experience. We handle the 3DS check ourselves, not your underlying processor. This allows us to seamlessly pass the result to the original and fallback processors without requiring your customer to re-authenticate.
Fallbacks are a safety net
At Primer, we see fallbacks as a crucial safety net. Our advice to merchants is to use fallbacks where they make sense. As we’ve seen from Banxa’s example, they can lead to significant revenue recovery. However, the ultimate goal should be to prevent payments from failing in the first place. This means analyzing decline codes and building dynamic workflows that give every transaction the best possible chance of success.
Learn more about Primer Fallbacks and the other ways we enable merchants to realize more revenue.
(1).jpg)
