Payment orchestration is a software layer that connects one business to several payment processors and payment methods through a single integration. It decides where each payment goes, can retry a failed payment on a backup processor, and keeps card details in a vault that is not tied to one processor. Orchestration platforms such as Primer and Spreedly sell this layer. Some processors, including Stripe, now offer routing to third-party processors as well.
What a payment orchestration layer does
A payment orchestration layer sits between a business’s checkout and its processors. It usually bundles five parts.
- Connections. Pre-built links to gateways, processors and payment methods. Spreedly lists 150+ gateway connections and 60+ supported payment methods on its pricing page.
- A vault. A secure store that swaps card numbers for tokens, so the business can send the same card to different processors. Spreedly says its vault keeps credentials portable across gateways and supports card updater services that refresh expired cards.
- Routing rules. Logic that picks a processor for each payment. Primer calls its rule builder Workflows and says teams can build payment logic without code and run A/B tests across processors or 3-D Secure strategies.
- Fallbacks. A retry on a backup processor when the first one declines or fails. Primer says its fallbacks reuse the 3-D Secure data from the first attempt, so the customer does not authenticate twice.
- Reporting. One view of performance, costs and settlement across processors.
3-D Secure (3DS) is the card networks’ protocol for authenticating the cardholder during an online payment.
Payment orchestration vs a single gateway
| Question | Single gateway or processor | Payment orchestration layer |
|---|---|---|
| Processors per integration | One | Several, behind one API |
| Where stored cards live | Usually in the processor’s own token store | In a vault the business controls, usable across processors |
| What happens on an outage or decline | The payment fails or waits for a manual retry | Rules can retry it on a backup processor |
| Switching processors | A new integration and a card-data migration | A routing change, if the new processor is connected |
| Contracts | One processor agreement | An orchestration contract plus one agreement per processor |
| Who processes each payment | The gateway’s processor | Still each underlying processor; the layer does not replace them |
The last row matters. An orchestration layer is not a processor or an acquirer. Stripe’s documentation for its own Orchestration product says a third-party processor “continues to act as the processor” for payments routed to it. Fees and liability for losses stay under that processor’s terms.
Payment routing in practice
Payment routing is the rule set that sends each payment to a processor. Common inputs are the customer’s country, the card type, the currency, the amount, the cost of each route and recent approval rates per processor.
Three patterns show up in provider documentation:
- Rule-based routing. A fixed rule, such as sending one region’s cards to a local processor.
- Retry routing. Stripe says its Orchestration can be configured to retry failed transactions with alternative processors. Primer describes the same idea as fallbacks.
- Test-and-learn routing. Primer says Workflows can split traffic between processors and send more of it to the one that performs better.
Stripe Orchestration is in private preview, per its documentation. Stripe says it covers card payments through Payments, Billing and the Dashboard. It does not support non-card payments, Connect, Terminal, disputes or settlement activity. Disputes and settlement for routed payments stay in the third-party processor’s dashboard.
Where orchestration fits next to embedded payments
The two layers solve different problems. Embedded payments let a platform offer payments to its own users as sub-merchants. Orchestration lets one merchant spread its own payments across processors. A platform can use both. Check support first: Stripe’s documentation lists Connect as unsupported by its Orchestration product.
What orchestration costs
Pricing is uneven across the market:
- Spreedly publishes an Independent Vault plan starting at $750 per month. Its Performance Optimization tier, which includes routing, is priced on request.
- Primer’s pricing is not published.
- Stripe Orchestration pricing is not published; the product is in private preview.
Processor fees come on top. Each processor still charges for the payments it handles.
Security and card-data scope
The Payment Card Industry Data Security Standard (PCI DSS) is meant for every entity involved in card processing, including merchants, processors and service providers. An orchestration provider that runs a vault stores card data for its customers. Spreedly describes its vault as “PCI-1 compliant”. Ask any provider for its attestation of compliance.
The PCI Security Standards Council published PCI DSS v4.0.1 in June 2024. Its 51 future-dated requirements became mandatory on March 31, 2025. A vault can reduce how much card data a merchant’s own systems touch. It does not end the merchant’s PCI DSS obligations. Scope is set with the merchant’s acquirer and assessor, and this article is not compliance advice.
For a side-by-side review of the providers’ published features, see payment orchestration platforms.
Questions to ask a provider
- Which processors and payment methods are connected today, and which are on request?
- Can we export our stored card tokens and card data if we leave? In what format and at what cost?
- Which PCI DSS validation do you hold as a service provider, and can we see the attestation?
- What inputs can routing rules use, and who can change them without a code release?
- Do fallbacks reuse 3-D Secure data, and which processors accept it?
- How are refunds, disputes and settlement handled for each connected processor?
- Is pricing published? If not, which fees are fixed and which scale with volume?
For platform-side payment models, see embedded payments. For how payment products relate to the wider stack, see embedded finance vs banking as a service. More in our payments guides.
