Payment orchestration explained: routing, failover, vaults

Payment orchestration is a software layer between a merchant's checkout and two or more payment processors: it decides which processor handles each payment, retries a failed payment on another one, and stores card details in a vault that is not tied to any single processor. It is offered by dedicated platforms such as Primer and Spreedly and, as of 3 November 2026, by Stripe as a private-preview product called Orchestration.

The idea is simple. Instead of wiring the checkout straight to one gateway, the merchant integrates once with the orchestration layer, and the layer talks to every processor behind it. If you are unsure how gateways, PSPs and acquirers differ in the first place, start with payment gateway vs PSP vs acquirer.

Who does what in an orchestrated payment

One point is easy to miss. The orchestration layer usually does not become the merchant's processor. Stripe's documentation for its Orchestration product says that a third-party processor keeps acting as the processor for payments routed to it, and that its fees and liability for transaction losses stay under the merchant's own contract with that processor (Stripe, checked 3 November 2026).

How payment orchestration works, step by step

1. The shopper enters card details. The checkout sends them to the orchestration provider's tokenisation service rather than to a single gateway. Primer, for example, says its checkout sends payment data straight to its PCI Level 1 tokenisation service, which returns one standard token format whatever the payment method.
2. The card is stored in a neutral vault. The token points to card data held in the orchestrator's vault. Spreedly describes this as storing cards separately from any one gateway, so the merchant can pass a stored card to different endpoints.
3. Routing rules pick a processor. The layer reads the payment's attributes (card country, currency, amount and so on) and checks them against the merchant's rules.
4. The layer sends the authorisation. It forwards the payment, with the card data or a network token, to the chosen processor's API.
5. The processor returns a result. Approved payments move on to capture and settlement with that processor. The layer records which processor handled the payment.
6. Failures can be retried elsewhere. If the first processor declines or errors, a retry rule can send the same payment to a second processor.
7. Reporting is pulled together. The layer shows approval rates and volumes per processor, so the merchant can adjust its rules.

Routing rules

Routing is the core feature. Each provider describes it slightly differently.

Sources: Stripe route-payments documentation; Primer website; Spreedly documentation, all checked 3 November 2026.

Stripe's documentation gives a worked example: a rule that sends payments to another processor when the card country is the United Kingdom, and to Stripe otherwise. Its dashboard can then filter performance by currency, card brand, card country, card type or transaction type. Stripe notes that this data can take up to two days to appear and depends on what the other processors report.

Failover and retries

Failover means sending a payment to a backup processor when the first one fails. Primer says its fallbacks can trigger on standard gateway errors, soft issuer declines such as "Do Not Honor", and application-level failures.

Stripe's retry rules let a merchant name a main processor and one retry processor. Its documentation sets out some limits worth knowing:

• If 3D Secure was attempted on the first processor and the shopper did not authenticate, or authenticated but the payment still failed, Stripe does not retry on the second processor.
• If the payment uses a feature the retry processor does not support, it is not retried there.
• If Stripe is the main processor and its own fraud screening blocks a payment, Orchestration treats that as a decline and can retry on the other processor.

That 3D Secure point matters for European merchants. Authentication is tied to the acquirer, and Stripe's documentation says that for payments needing 3D Secure the merchant must supply the acquirer BIN of the processor the payment is routed to. Our 3D Secure guide explains why authentication and authorisation have to line up.

The vault and token portability

The vault is what makes switching processors practical. Without it, card details saved for repeat customers sit with one PSP in a token only that PSP can read.

Primer puts the case directly in its documentation: because its vault is not tied to a processor, the merchant does not receive processor-specific tokens. Spreedly calls its approach "universal tokenization".

Network tokens add a second layer. Spreedly says it acts as a token requestor for Visa and Mastercard and pairs each network token with the underlying card number in a single Spreedly token. When a payment goes to a gateway that does not support network tokens, it falls back to the card number. Adyen, by contrast, says its own network tokenisation applies only to payments it acquires, not to connections to external acquirers.

Moving stored cards between processors

A merchant that already stores cards with a PSP can usually ask for them to be exported. Stripe's documentation says it will transfer card data only to a processor that is PCI DSS Level 1 compliant, and asks for that processor's Attestation of Compliance or listing on Visa's Global Registry of Service Providers, plus a PGP public key of at least 4,096 bits. Stripe says it does not export payment history or subscriptions, and that cards saved through its Link wallet cannot move between processors.

Stripe also offers a Vault and Forward API, available on request, which sends card details collected by Stripe to a third-party processor's endpoint and strips identified card data from the response before returning it.

Who offers payment orchestration

Sources: provider documentation and websites, checked 3 November 2026. Stripe's feature limits come from its Orchestration overview page.

Large processors such as Adyen, Checkout.com and Worldpay often sit behind an orchestration layer as one of the routed processors. Our Adyen vs Stripe and Stripe vs Checkout.com comparisons cover how those processors differ.

Benefits and trade-offs for merchants

Two practical points come out of the documentation. First, reconciliation changes: Stripe says it creates different record types for payments routed to other processors and does not create balance transactions for them, because the funds never pass through the Stripe account. Second, feature parity is uneven. A payment that relies on a processor-specific feature may not be routable, which is why Stripe offers an option to process it on Stripe instead of returning an error.

Orchestration tends to suit merchants with high card volumes, several markets or a need for processor redundancy. A business with one market and one processor gains less from it.

Adoption figures

No central bank, card scheme or standards body has published market-wide adoption figures for payment orchestration that we could find as of 3 November 2026. Provider figures, such as Primer's count of connected PSPs, describe the provider rather than the market.

More guides and profiles sit in the gateways hub.

Frequently asked questions

What is payment orchestration?

Payment orchestration is a software layer between a merchant's checkout and two or more payment processors. It decides which processor handles each payment, retries a failed payment on another one, and stores card details in a vault that is not tied to any single processor.

Does a payment orchestration platform replace my payment processor?

Usually not. Stripe's documentation for its Orchestration product says a third-party processor keeps acting as the processor for payments routed to it, and that its fees and liability for transaction losses stay under the merchant's own contract with that processor. Each processor still needs its own merchant agreement and onboarding.

Which companies offer payment orchestration?

Dedicated platforms such as Primer and Spreedly offer it, and as of 3 November 2026 Stripe offers a private-preview product called Orchestration. Primer says it connects to 70+ PSPs through one API (website, checked 3 November 2026). Large processors such as Adyen, Checkout.com and Worldpay often sit behind an orchestration layer as one of the routed processors.

What is the difference between a PSP token and a network token?

A PSP token is created by the merchant's payment processor, and only that processor can use it. A network token is issued by the card scheme's token service and passes through acquirers and networks; Visa describes its tokens as not specific to any one processor. Our network tokenisation guide explains how they work.

Can a failed payment be retried on another processor?

Yes, a retry rule can send a declined or errored payment to a second processor. Stripe does not retry on the second processor if 3D Secure was attempted on the first and the shopper did not authenticate, or authenticated but the payment still failed. A payment that uses a feature the retry processor does not support is not retried there either.

Who is payment orchestration for?

It tends to suit merchants with high card volumes, several markets or a need for processor redundancy. A business with one market and one processor gains less from it.

Key terms

• Failover: sending a payment to a backup processor after the first one fails.
• Orchestration layer: software that routes payments across several processors through one integration.
• Network token: a card-scheme-issued substitute for the card number, usable across acquirers.
• PSP token: a token that only the processor that issued it can turn back into card data.
• Routing rule: a condition and action that decides which processor handles a payment.
• Token portability: the ability to use stored payment credentials with a different processor.
• Vault: a PCI DSS compliant store of card data held separately from the merchant's own systems.