If you're running payments across more than one PSP, you already know the problem: every provider speaks its own language. Each has its own API, its own decline codes, its own idea of what a "soft" failure looks like, and its own retry behaviour.
Add a handful of payment methods: cards, wallets, bank transfers, local schemes like PayNow or Pix — and the coordination burden multiplies.
Without a unified layer sitting above your providers, fallback logic has to be hand-coded. Your engineers write the rules that say "if Processor A soft-declines, retry on Processor B," then maintain those rules every time a provider changes its API, every time you add a market, and every time a new payment method joins the checkout. The logic lives in your codebase, it's brittle, and the person who wrote it eventually leaves.
That's the problem payment orchestration platforms exist to solve. This article lays out a practical framework for evaluating them, and explains where Primer fits, with real merchant results rather than adjectives.
Why fallback logic is harder than it looks
On a whiteboard, fallback routing is simple: payment fails on the primary processor, so you retry it on a backup. In production, it's anything but.
- Decline codes aren't standardized. A "do not honour" from one acquirer and an "insufficient funds" from another may both be retryable, or neither. You need to normalize failure reasons across providers before you can write sensible retry rules.
- 3DS authentication complicates retries. If a customer completed 3D Secure on the first attempt, a naive retry on a second processor forces them through authentication again or fails outright. Preserving authentication results across a fallback attempt requires the orchestration layer to handle 3DS independently of any single processor.
- Retries can make things worse. Blindly retrying hard declines (stolen card, closed account) damages your standing with issuers and schemes. Good fallback logic distinguishes recoverable failures from unrecoverable ones.
- Every new method multiplies the matrix. Fallback rules that work for Visa card payments don't translate to a bank-transfer method with no equivalent backup. Each method-processor pairing needs its own logic.
Hand-building and maintaining this in-house is a permanent engineering tax. The question is which platform takes it off your plate best.
How to evaluate a payment orchestration platform
Five criteria separate the platforms worth shortlisting.
1. Multi-PSP connectivity
The core promise of orchestration is one integration, many providers. Check how many PSPs, acquirers, and payment methods the platform connects to out of the box, how quickly new connections ship, and whether adding a provider requires engineering work or a dashboard toggle. Ask specifically about the markets and local methods you plan to launch in over the next two years: the gap between "supported" and "supported well in your region" can be wide.
"If I were building my ecommerce business tomorrow, my first reflex would be to not get stuck with a single provider. I'd want a panel of providers to secure the business, and that alone lets me challenge my main provider's costs. That's the entry door, and once you're in you find all the options that also lift conversion, so you win on both sides." – Christophe Smol, Acceptance Product Lead at Primer
Learn more: Why you need multiple payment processors (and how to do it)
2. Visual workflow builder
Routing and fallback rules change often: a processor's performance dips, fees change, you enter a new market. If every rule change is an engineering ticket, you lose the agility orchestration was supposed to buy you. Look for a no-code, visual way for payment and operations teams to build, edit, and test routing logic themselves, and check whether it covers fallback rules specifically, not just primary routing.
Learn more: What are the benefits of smart routing?
3. Fallback automation
This is where platforms differ most. Questions to ask: Does the platform automatically retry soft-declined transactions on a backup processor? Can you control which failure codes trigger a retry? Is 3DS authentication preserved across the retry, or does the customer get challenged again? Can fallback behaviour differ by market, card type, or payment method?
4. Unified analytics and monitoring
You can't manage what you can't see. A good platform gives you one view of authorization rates, decline reasons, and volumes across every provider — normalized so you're comparing like with like. The stronger platforms go further with real-time monitors and alerts, so you learn about a processor degradation from your dashboard rather than from your customers.
5. Compliance and vaulting
Multi-PSP setups only work if your customer payment credentials aren't locked inside one provider's vault. Look for PCI DSS Level 1 compliance, an agnostic vault that lets you use stored credentials with any connected processor, and support for network tokenization to keep credentials current.
The case for Primer: why use us?
Primer’s case is not just that it connects multiple PSPs. It helps merchants recover more revenue, give payment teams more control, and manage the wider payment operation from one place.
Recover more revenue from failed payments
Primer’s Fallbacks automatically retry soft-declined transactions on a backup processor, using rules you define in Workflows. Because Primer 3DS handles authentication at the orchestration layer, authentication results can be preserved across fallback retries. That means the customer does not need to be challenged twice, and the retry is less likely to fail because authentication is missing.
This has a direct revenue impact. Banxa recovered US$7 million in failed payments in six months using Primer. Dabble reached a 96% authorization rate and recovered $70k AUD in a single month through fallbacks alone.
For merchants processing payments across multiple markets, this matters because PSP performance is rarely consistent. A transaction that fails with one provider may succeed with another. Primer gives teams the logic to act on that automatically.
Give payment teams more control
Primer Workflows is a no-code visual builder for routing, fallback, and notification logic. Instead of asking engineering to hard-code every payment change, payment teams can build and adjust rules themselves.
That helps teams move faster. They can test new routing strategies, respond to processor issues, add backup logic, and change how payments flow without waiting for development work.
Primer Observability and Monitors add the visibility needed to make those decisions. Teams can see normalized performance data across providers, spot drops in authorization rate or payment count, and send alerts to Slack, email, or webhooks when something changes.
Manage the wider payment operation
Primer also helps with the parts of payments that sit beyond orchestration.
Reconciliation gives finance teams a clearer view of transactions, settlements, and provider reports across PSPs and payment methods. Costs Overview shows what providers are charging across processor fees, scheme fees, FX, and other payment costs, helping teams understand margin leakage and compare providers more accurately.
For global merchants, Primer’s Agnostic Vault keeps payment credentials portable across processors, while Network Tokenization helps keep card credentials up to date. Global Accounts adds more control over how money is collected, converted, and moved across markets.
Primer AI Companion brings intelligence into the platform, helping teams surface issues, investigate performance changes, and identify opportunities faster.
So Primer is not just a payment orchestration layer. It is infrastructure for running payments more effectively: recovering failed revenue, giving teams more control, improving visibility, and helping merchants scale across providers, markets, and currencies.
Build a payment stack that recovers revenue, reduces complexity and scales with you
Primer is for merchants that need more than a basic PSP connection layer. It helps payment teams recover failed revenue, control routing and fallback logic without engineering, see performance across every provider, and manage the operational work that happens after checkout. For businesses operating across multiple markets, processors, currencies or payment methods, Primer gives you the infrastructure to run payments with more resilience, visibility and control.
FAQs: Payment orchestration and fallback logic
What are the leading payment orchestration providers?
Leading payment orchestration providers include Primer, Spreedly, IXOPAY and Gr4vy. The right choice depends on the PSPs and payment methods you use, the markets you operate in, and how much control you want payment teams to have over routing and fallback rules.
How does payment fallback logic work?
Fallback logic sends a failed payment to a backup processor when the original failure is considered recoverable. The platform can use factors such as decline reason, geography, payment method and card type to decide whether to retry the transaction and where to send it next.
Can payment orchestration preserve 3DS authentication during a fallback?
Some platforms can preserve authentication results when a payment is retried through another processor. Primer 3DS operates independently of individual processors, allowing eligible fallback attempts to reuse the original authentication rather than asking the customer to complete 3DS again.
Does payment orchestration replace payment processors?
No. A payment orchestration platform sits above your PSPs, acquirers and other payment services. It gives you one place to connect providers, control routing and fallback logic, and compare performance across them.
What should I look for in a platform for managing multiple payment methods?
Look for broad PSP and payment-method connectivity, configurable fallback rules, normalized decline data, provider-independent vaulting and clear cross-provider reporting. It is also worth checking whether payment teams can update logic themselves or whether every change requires engineering support.
.png)
.avif)