The real problem
If you’ve managed online payments for any length of time, you know the truth: cards were never designed for the internet age. They were built for physical terminals, face-to-face transactions, and simple risk models. While the ecosystem has improved over the past 25 years, it remains deeply under-optimized for modern e-commerce.
Nowhere is this clearer than in issuer decisioning. Too few trust signals are passed. Too much context is lost. The result is blunt, defensive decisions in a world that demands precision.
The cost is enormous. In the United States alone, more than $300bn in legitimate card payments are declined every year. For many online merchants, that means 10–20% of potential revenue disappears. Not because of fraud but because the system still can’t reliably tell good customers from bad ones. If you’re seeing lots of “05 – Do Not Honor” declines, you’re not unlucky. You’re paying for a system that still doesn’t trust itself.
Why the schemes didn’t solve it
The schemes know this. They’re incentivized to fix it: better approvals mean more volume and more revenue for everyone. But progress hasn’t been smooth.
Early tools like 3D Secure tried to force a chip-and-PIN world onto the internet. Fraud dropped, but conversion dropped too. Online, there’s no cashier to help when a payment fails. Friction kills sales. That’s why, outside of mandated markets, 3DS has always been unpopular with merchants.
More modern initiatives like network tokenization and passkeys could finally close the gap between online and in-store approvals. But adoption is slow. Much of the issuing stack was never built to use these data-driven tools properly, and progress isn’t keeping pace with the demands of today’s digital economy.
And through all of this, the biggest improvement in online merchant approval rates over the last decade didn’t come from the schemes at all. It came from organic technological progress outside their ecosystem: orchestration.
What orchestration is
The core purpose of payment orchestration is to make payment acceptance more dynamic and more merchant-centric, addressing the fundamental breakages in online card payments. What began about a decade ago as light logic layered on top of gateways has, in the 2020s, become a critical layer of the payments stack.
At its heart, orchestration manages routing, cascading, retries, and PSP selection, optimizing how a payment is attempted in the first place, with approval-rate uplift as its primary goal.
The first orchestration cohort, around 2015, added business logic to gateways: conditional routing, smart retries, and broader PSP connectivity. That was the real differentiation, and enough to attract venture capital to a space gateways had defined and consolidated years earlier. Payments moved from static pipes to something dynamic. The value was simple: better approvals through optionality, and more leverage through easier switching.
The second cohort, over roughly the last five years, has been cloud-native, more product-driven, significantly expanding the original value proposition. They improved UX, configuration, and checkout flows, and added services like reconciliation, disputes, observability, and reporting. Regardless of the naming, they’re effectively SaaS payments platforms with orchestration as one part of the value proposition. Orchestration became part of a broader platform story, not just a smarter gateway.
But orchestration alone has limits.
What recovery is
Payment recovery focuses on what happens after a transaction fails, when all normal routing and cascading strategies have already been exhausted. Think of orchestration as the first layer of approval optimization. Recovery sits on top of it. You don’t use recovery instead of orchestration. You use it because orchestration alone has reached its limit.
In many ways, recovery isn’t new. For centuries, banks and merchants have used factoring and collections when payments fail and internal teams can’t solve the problem. A specialist steps in to recover value the merchant can’t efficiently handle themselves. It reduces internal effort, brings outside expertise, and makes financial sense. Payment recovery, as Paymend practices it, is the digital version of that model.
In online payments, recovery platforms use technology to do this at scale. They use data, intelligence, and alternative rails to retry or reprocess failed payments in ways orchestration alone can’t. Some focus purely on smarter retry logic: optimizing timing, messaging, and sequencing. Others go further, adding alternative processing rails and sometimes fully owning the payment flow, which brings deeper visibility and more control. That’s where Paymend operates.
Like orchestration, recovery has evolved in clear cohorts over the last decade. Advances in technology - especially AI and machine learning - have pushed uplift from single-digit gains to double-digit approval improvements, with a direct impact on top-line revenue. Different players now offer very different capabilities, largely shaped by when they were founded and the technology they were built on.
Orchestration and recovery as a system
With the rise of recovery platforms alongside advances in orchestration, approval-rate optimization is entering a new phase. Orchestration is no longer the only game in town. The complementary layer of recovery has emerged.
That doesn’t make orchestration any less important. It remains the central technical layer of your payments strategy, but it’s no longer the finish line. Recovery plugs into orchestration and focuses on what happens after a transaction fails, adding uplift beyond routing and cascading.
Maximum uplift only happens when both work together: orchestration handles real-time routing, cascading, and retries, while recovery adds deeper intelligence and alternative rails to rescue transactions that simple cascading can’t fix.
You can see this in practice. A customer reaches the checkout and a payment fails. Orchestration steps first, routing through the best-performing PSP, cascading to others, and retrying with different rules in real time. Most of the time, that works.
But sometimes even the smartest orchestration runs out of options. That’s when recovery takes over. Instead of acting only at checkout, recovery platforms use alternative rails, large-scale data, and intelligent timing and messaging to retry, either in real time or later, depending on the business model. Orchestration owns the moment of checkout. Recovery owns what happens after failure. Together, they turn more declines into revenue.
Why merchants need both
Orchestration and recovery solve different parts of the same problem.
Orchestration is about efficiency. It optimizes routing, reduces dependence on any single PSP, lowers cost, and maximizes success at checkout. Recovery is about retention, when everything you control has failed and it’s time to hand the problem to a specialist. It rescues failed payments, reduces involuntary churn, and brings back revenue that would otherwise be lost.
Payments teams should optimize in-house first. Most do. But dedicated recovery platforms consistently outperform internal solutions because they operate on far larger datasets and have access to rails individual merchants don’t.
That’s why recovery shouldn’t replace internal optimization. It should come after it. In-house improvements are the first step. Orchestration is the foundation. Recovery is the final leg: the work that isn’t cost-effective to do internally.
If you’re already using orchestration, whether in-house or through a partner, start thinking about recovery as a no-win, no-fee layer: zero downside, all upside. The real risk isn’t adding recovery. It’s leaving revenue on the table.
Talk to your orchestration partner. See what’s already integrated. Then test, measure, tweak, and refine, until more declines turn into revenue.
Orchestration helps you accept more payments. Recovery helps you keep more customers. If you only do one, you’re leaving money behind.
