What an orchestration layer is, and what it deliberately is not
Payment orchestration is the least well defined term in the acceptance stack, because almost every processor now claims to do some of it. The distinction that matters is structural: an orchestration layer sits in front of a merchant's payment providers rather than being one of them, and it does not settle money.
Spreedly states the boundary plainly in its own documentation: it never touches the merchant's money, which flows from the cardholder to the merchant's own gateway and merchant account. That sentence explains the entire commercial position. The merchant keeps its acquiring relationships, its underwriting, its settlement accounts and its chargeback liability. What it buys is credential custody and decision logic.
This is why an acquirer's routing features are not the same product, even when the marketing copy overlaps. Adyen, Checkout.com and Worldpay all optimize authorizations across their own connections, and Nuvei markets orchestration as a named line. Those features are valuable, but they route within one provider's estate. An orchestration layer routes between competitors — precisely the capability a provider has no incentive to sell you.
Routing: sending a transaction to the right place
Routing is the visible half of orchestration. A rule engine decides, per transaction, which provider receives the authorization request — based on card brand, issuing country, currency, card-present or card-not-present, transaction value, merchant entity, or measured historical performance for that issuer.
Two mechanisms drive real money. The first is cost routing: sending each transaction to whichever acquirer prices that particular combination most favorably. Where a merchant sells across borders, local acquiring in the cardholder's own market frequently produces both better economics and better acceptance than routing everything through a single home-market acquirer, because domestic transactions attract domestic interchange and issuers treat them as lower-risk.
The second is performance routing: sending transactions to the acquirer whose measured authorization rate for that issuer, in that market, at that ticket size, is highest. The gains here are usually small in percentage terms and large in absolute terms — an uplift measured in fractions of a percent, applied to every transaction a business processes forever.
The mistake most teams make is writing static routing rules and never revisiting them. Issuer behavior shifts, acquirer performance shifts, and a routing table configured at implementation and left alone becomes a slowly worsening decision engine. Routing is an operating discipline, not a configuration step.
Retries and cascading, and the rules that constrain them
When an authorization fails, the response code says why. A hard decline — stolen card, closed account, do not honor with a definitive reason — is final; the issuer will not approve it on retry, and hammering it wastes money and attracts network scrutiny. A soft decline — insufficient funds, issuer unavailable, velocity limit, temporary processing error — may succeed later or elsewhere.
Orchestration acts on that distinction in two ways. Retries resubmit a soft decline to the same provider on a schedule tuned to the decline reason and, for recurring billing, to payroll cycles. Cascading resubmits it immediately to a different provider, on the theory that a different acquirer, BIN routing and risk model may produce a different answer.
Cascading a hard decline is not clever, it is a violation waiting to happen. Both major networks operate limits on retry attempts against declined transactions and impose fees or penalties for excessive reattempts. Any retry strategy must be built on decline-code logic, not on a fixed number of attempts.
A business running subscriptions may already own most of this capability. Chargebee and Recurly both operate dunning, smart retry logic and failover across connected gateways. Buying an orchestration platform to obtain retries a billing system already performs is a common and expensive duplication.
The vault is the real reason to consider orchestration
Routing gets the attention. Tokenization portability is what actually changes a merchant's negotiating position.
When a merchant stores cards with its processor, the processor issues tokens — surrogate values standing in for the card number, so the merchant never handles the real credential and keeps its PCI DSS scope small. Those tokens are proprietary and meaningless to any other provider. A merchant with millions of stored credentials that wants to change processors therefore faces a choice: ask every customer to re-enter their card, churning a meaningful fraction of them, or arrange a PCI-compliant vault-to-vault token migration — a project requiring the incumbent's cooperation at precisely the moment it has been told it is being replaced.
An independent vault removes that hostage situation. Credentials are captured into the orchestration provider's PCI DSS Level 1 environment, and the same stored credential can be presented to more than one provider without re-vaulting. Spreedly built its business on exactly this and is a certified vendor-neutral network tokenization provider with Visa and Mastercard; Braintree documents vault portability as an explicit feature. Network tokens — credentials tokenized by the network itself rather than by a processor — push the idea further, since they survive card reissuance and update automatically.
The commercial consequence: vault independence converts processor pricing from a fixed cost into a negotiable one. A merchant that can credibly move volume in a week is a different counterparty from one that cannot move it at all.
What orchestration genuinely fixes
Three problems, and only three, justify the layer.
- Authorization rates. Every transaction an issuer declines that should have been approved is revenue that had a customer attached to it. Routing, cascading, network tokenization and account updater services each recover a slice of that.
- Redundancy. Processor outages happen, and a merchant with one acquirer and one gateway has no answer to them beyond waiting. A merchant with a second live connection and a tested failover path loses minutes rather than hours.
- Lock-in. Independence of credentials and integration is what makes a repricing conversation real. Without it, the merchant is asking; with it, the merchant is negotiating.
Notice what is not on that list. Orchestration does not reduce interchange, which is set by the networks and not negotiable by anyone in the chain. It does not reduce network assessments. It does not settle faster. It does not remove chargeback liability, which stays with the merchant and its acquirer. Anyone selling it as a way to reduce the cost of a card transaction is selling the wrong thing — the savings, where they exist, come from acquirer markup and from approving transactions that would otherwise have failed.
What it costs, including the parts that are not invoiced
The license fee is the smallest line. Orchestration vendors typically price a vault tier separately from an optimization tier, and because they do not settle funds, their fees are software fees sitting entirely on top of whatever the merchant's acquirers already charge. Nothing is netted out of settlement, so the cost is fully visible and fully additive.
The uninvoiced costs are larger:
- A second acquiring relationship. Routing across two acquirers means being underwritten twice, maintaining two sets of reporting, and satisfying two risk teams. Some acquirers price on committed volume, so splitting volume can worsen the rate on both.
- Reconciliation. Two settlement files, two fee structures, two chargeback workflows, two dispute deadlines. This is the cost finance teams consistently underestimate.
- Engineering. An orchestration layer is a new critical dependency in the authorization path. It needs monitoring, an incident runbook and a tested route around it.
- Fraud rule fragmentation. Risk models trained on one acquirer's traffic degrade when volume is split. Fraud decisioning generally needs to move up into the orchestration layer too, which is why vendors have been acquiring fraud capability.
The volume at which it starts paying for itself
There is no industry threshold, but there is a formula, and it is simple enough to run on the back of an envelope.
Annual benefit = processed volume × approval uplift × contribution margin. Compare that to the fully loaded annual cost: license, engineering, reconciliation headcount, second acquirer overhead.
Work it with illustrative figures. Suppose a merchant processes $50m a year and orchestration lifts the approval rate by 0.3 percentage points. That is $150,000 of additional captured revenue, of which perhaps a third is contribution — call it $50,000. Against a fully loaded program cost that plausibly reaches six figures once engineering and reconciliation are counted, the answer is no. Run the same arithmetic at $500m and the recovered contribution is around $500,000, and the answer changes. Push the uplift to a full percentage point, achievable for a cross-border merchant gaining local acquiring it did not previously have, and the threshold falls sharply.
Two things move the break-even more than volume alone: margin, because a high-margin digital business captures far more from each recovered transaction than a low-margin retailer, and geographic spread, because the largest approval gains almost always come from acquiring locally in markets where the merchant was previously acquiring cross-border. A domestic-only merchant with a competent single acquirer has very little left to win.
Most merchants do not need it
This deserves saying without hedging: for the overwhelming majority of merchants, an orchestration layer is an expensive answer to a problem they do not have. If a business processes in one country, through one acquirer, with an approval rate already in the high nineties, there is no meaningful uplift available and the project will cost more than it returns.
The cheaper interventions come first, and they are usually the ones left undone. Enable network tokenization and account updater with the existing provider. Fix the retry schedule in the billing system. Send complete data on every authorization, since thin submissions get declined more often. Apply the correct network indicators to recurring transactions. Audit which declines are hard and which are soft before assuming any are recoverable. Merchants routinely find several tenths of a percentage point in that list at close to zero cost.
There is also a diagnostic step between doing nothing and buying a platform. Pagos reads transaction data from the processors a merchant already uses, normalizes it, enriches it with BIN data and reports where authorizations are being lost — explicitly without requiring a change of provider. Knowing which issuers, markets and card types underperform is a prerequisite for orchestration anyway, and a far cheaper way to discover that the answer is a configuration change rather than a new vendor.
How to test the claim before you sign
Every orchestration vendor will quote an approval-rate uplift. Treat it as a hypothesis and make them prove it on your traffic.
- Establish a baseline you trust. Approval rate by issuer BIN, market, card type, ticket size and transaction type. A single blended number is not a baseline; it hides the segments where the gains live.
- Separate hard from soft declines. If most failures are hard declines, no amount of routing will help and you have a customer or fraud-rule problem instead.
- Run a genuine split test. Route a randomized share of comparable traffic through the new path for long enough to cover a full billing cycle. Comparing this month to last month is not a test; seasonality and mix will swamp the effect.
- Price the whole program. License plus engineering plus reconciliation plus the impact on your existing acquirer's volume-committed rate.
- Contract for exit. The reason to buy a vault is portability, so a vault contract without a written, tested right to export tokens defeats the purpose of buying it.
If the split test shows a real uplift, the arithmetic makes the decision for you. If it does not, you have spent a quarter learning where your authorizations actually go — worth more than the platform would have been.
Frequently asked questions
What is payment orchestration?
Payment orchestration is a software layer that sits between a merchant's checkout and its payment providers, storing payment credentials independently of any one provider, deciding which provider receives each transaction, retrying or re-routing failures, and consolidating reporting across providers. Orchestration platforms typically do not settle funds: money still flows from the cardholder to the merchant's own acquirer and merchant account. The merchant therefore keeps its acquiring relationships, its underwriting and its chargeback liability.
Does payment orchestration reduce processing fees?
Not directly. Interchange is set by the card networks and is not negotiable by merchants, processors or acquirers, and network assessments are equally fixed. Orchestration can reduce cost indirectly by routing transactions to whichever acquirer prices a given corridor most favorably, by enabling local acquiring that attracts domestic rather than cross-border interchange, and by giving a merchant the credible ability to move volume, which strengthens its position when renegotiating acquirer markup.
What is transaction cascading?
Cascading is resubmitting a declined authorization to a different payment provider in the hope that a different acquirer, routing path and risk model produce an approval. It should only ever be applied to soft declines such as issuer unavailable or temporary processing errors, never to hard declines such as stolen card or closed account. Both major card networks limit retry attempts against declined transactions and can apply fees or penalties for excessive reattempts, so cascading logic must be driven by decline response codes.
What is vault independence and why does it matter?
Processor-issued payment tokens are proprietary, so a merchant that stores cards with one provider cannot present those tokens to another. Vault independence means storing credentials in a PCI DSS Level 1 environment that is not owned by any single processor, so the same stored credential can be used with multiple providers. It matters because it removes the migration barrier that otherwise makes switching processors impractical, which is what converts processor pricing from a fixed cost into a negotiable one.
At what transaction volume is payment orchestration worth it?
There is no universal threshold, but the calculation is annual processed volume multiplied by the expected approval-rate uplift multiplied by contribution margin, compared with the fully loaded annual cost of license, engineering, reconciliation and a second acquiring relationship. Two factors move the break-even more than volume does: gross margin, since a high-margin business captures more from each recovered transaction, and geographic spread, since the largest approval gains usually come from acquiring locally in markets previously served cross-border.
Is an acquirer's smart routing the same as orchestration?
No. Acquirers such as Adyen, Checkout.com, Worldpay and Nuvei offer routing, retry and authorization-optimization features, but those operate within that provider's own connections and acquiring estate. An independent orchestration layer routes between competing providers, which is the capability that delivers redundancy against a single processor's outage and leverage in a pricing negotiation. A provider has no commercial incentive to make its own volume easy to move elsewhere.
What should a merchant do before buying orchestration?
Exhaust the cheaper interventions first: enable network tokenization and account updater with the existing provider, correct retry schedules in the billing system, submit complete data on every authorization, apply the correct network indicators to recurring transactions, and separate hard declines from soft ones. Many merchants recover several tenths of a percentage point of approval rate this way at close to zero cost. An analytics layer that reads existing processor data, such as Pagos, can identify where authorizations are actually being lost without changing providers.
Does orchestration remove chargeback liability?
No. Because orchestration platforms typically do not settle funds or hold the merchant agreement, the merchant remains the party to its acquiring contracts and continues to carry chargeback liability, dispute deadlines and any network monitoring-program exposure. Splitting volume across multiple acquirers in fact multiplies the dispute workflows a merchant must operate, which is one of the costs most often left out of the business case.