Visa alone reported $12.3 trillion in payments volume for its fiscal 2024, per the network's annual report, and a growing share of the merchants behind that volume spread payments across several processors. A payment orchestration layer is the software that stands between checkout and those processors, deciding — transaction by transaction — which provider gets the request, what happens when it fails, and how the money is reconciled afterward.
Nuv Media publishes information, not financial advice.
What is a payment orchestration layer?
Orchestration is a routing and control plane for payments. The merchant integrates once, against the orchestration layer's API, and the layer connects outward to any number of payment service providers — acquirers, gateways, wallets, and local payment methods. Vendors in the category include Primer, Gr4vy, Spreedly, IXOPAY, and ACI Worldwide, alongside platform-level routing built into some enterprise PSPs.
The layer's core promise is neutrality: because no single processor sits in the middle of every transaction, switching providers or adding a market becomes configuration work rather than a re-platforming project. That neutrality is also its core cost — one more system in the payment path, with fees, latency, and its own failure modes.
What routing logic actually runs?
Routing decisions are rules plus models. Typical inputs include the card BIN and its issuing country, the transaction currency, the payment method, the merchant's cost with each provider, and — most valuably — each provider's historical authorization rate for a given issuer, market, and ticket size.
The payoff hides in those historical rates. Authorization performance differs by processor-issuer pair: a BIN that declines 8 percent of the time through one acquirer may approve reliably through another. An orchestration layer that has seen both patterns can send each transaction to the provider most likely to approve it, lifting total authorization rate without touching the issuer relationship.
Cost routing works the same way. Two providers may clear the same transaction at different effective cost after interchange qualification, scheme fees, and currency conversion, and the layer can weigh a small cost difference against a material approval-rate difference before choosing.
How do failover and decline retry work?
Failover answers outages. When the primary provider is down, returns timeouts, or reports a platform error, the layer cascades the transaction to the next provider in the waterfall, ideally within the same checkout session — the customer never learns a datacenter failed. For a merchant doing meaningful volume, minutes of processor downtime convert directly into lost sales, which is the simplest business case for orchestration.
Decline retry is subtler. A soft decline — insufficient funds, issuer unavailable — can be reattempted, sometimes through a different provider, and recover a payment that a single-PSP setup would have written off. The discipline is in the limits: retrying hard declines, retrying too fast, or retrying too often inflates processing costs and can push issuer fraud scoring against the merchant. Mature setups retry only soft-decline codes, space the attempts, and cap the sequence.
What about reconciliation?
Every provider reports differently: its own settlement file format, its own fee lines, its own refund and chargeback timing. With three processors, finance teams face three matching exercises daily before the ledger closes. Orchestration layers typically normalize settlement data into one schema and one reconciliation view, mapping every payout line back to the original order.
Unified reconciliation is unglamorous and frequently the loudest post-purchase justification for the layer. Multi-processor merchants that skip it end up building the same normalization in internal tooling anyway — an orchestration layer simply moves that cost into a product someone else maintains.
What does an orchestration layer not do?
It does not become the merchant of record. Every connected provider still onboards the merchant, still underwrites the account, and still owns its slice of interchange qualification and scheme fees. Orchestration changes who receives each request, not how the rails price it.
It also does not replace gateway features on its own. Tokenization, 3-D Secure handling, and fraud scoring still live somewhere — with the providers, with the layer, or with dedicated vendors — and the merchant must decide where each function sits so authentication data, network tokens, and risk signals follow the transaction across reroutes. When tokens stay trapped inside a single processor, portability quietly dies, and the layer routes among providers the merchant can no longer fully use.
When does a merchant actually need one?
The honest threshold test has three questions. Is the merchant selling in multiple regions where no single provider covers all local payment methods well? Has a processor outage or an authorization-rate gap cost real, counted revenue? Does payment volume give the merchant negotiating leverage that only exists if switching is technically cheap?
Three yes answers describe the orchestration buyer. Three no answers describe a merchant whose time is better spent tuning its single PSP — decline handling, account updater enrollment, 3-D Secure calibration — because orchestration adds integration work, a per-transaction or platform fee, and another vendor to manage.
| Capability | Single PSP | With orchestration |
|---|---|---|
| Provider choice per transaction | Fixed | Dynamic by cost, market, approval history |
| Processor outage | Checkout fails | Cascades to backup provider |
| Soft-decline recovery | One attempt, one provider | Scheduled retries, optional re-routing |
| Local payment methods | What the PSP offers | Any connected provider's catalog |
| Reconciliation | One format | One normalized view across providers |
| Added complexity | Low | Additional fee, integration, vendor |
Between the clear cases sits the mid-market gray zone: two markets, one dominant PSP, occasional outage pain. For those merchants, the practical first step is measuring — authorization rate by issuer country, outage minutes per quarter, and the revenue those numbers represent — before buying routing software to solve a problem that may not yet be sized.
For more context, read Where the FX Markup Hides in Cross-Border Payments.
For more context, read card decline codes.
For more context, read How Dunning Keeps Subscriptions Alive When Cards Fail.
