Payment orchestration: routing, cascading and one API for several PSPs

What is payment orchestration?

A payment orchestration platform connects one checkout to many payment providers. Instead of integrating Stripe, Adyen, a domestic acquirer and a crypto processor separately, the merchant integrates once, and the orchestrator translates each request into the provider's API and normalises statuses, webhooks and reports.

The value lies in what one integration makes possible: routing each payment to the provider most likely to approve it at the lowest cost, switching connections when one fails, and moving volume without rebuilding the checkout. Contracts, pricing and settlement stay between the merchant and each PSP.

• Connectors: one adapter per provider
• Router: rules that pick a connection
• Vault: card credentials and network tokens independent of any PSP
• Webhooks: one event format for all providers
• Back office: refunds, reporting and reconciliation

Payment orchestrator vs PSP vs payment gateway vs acquirer: who does what?

An acquirer is a licensed institution that accepts card payments for the merchant and settles funds. A PSP bundles acquiring with payment methods, onboarding and risk under its own licence. A payment gateway passes authorisation requests to one processor, and an orchestrator sits above several gateways and PSPs.

Only parties that hold funds need a payment institution, e-money or banking licence under PSD2. An orchestrator that never possesses funds is a technical service provider, which also means it cannot replace a PSP contract.

How does payment routing work?

Payment routing evaluates rules on each transaction before authorisation. Rules read checkout data such as the first 6 to 8 card digits (the BIN), issuer country, card type, currency, amount and method; advanced routers add live approval and error rates per connection.

Most merchants start with static rules and add cost and performance rules once they have data. An A/B split, for example 90% to the current PSP and 10% to a new one, measures a provider on real traffic before moving more volume.

What is cascading, and when should a declined payment be retried?

Cascading resubmits a failed or declined payment to another connection without asking the shopper to re-enter details. It is meant for timeouts, provider errors and some soft declines; hard declines must never be retried. Our payment cascading glossary entry covers which declines to cascade and the rules for doing it safely.

How do token vaults and network tokens fit into orchestration?

If one PSP stores your card data, saved cards and subscriptions are locked to it, and moving them takes a migration file and weeks of coordination. An orchestrator's vault stores credentials independently, so any connected PSP can charge a returning customer, and hosted fields keep card numbers off the merchant's servers.

Network tokens from Visa and Mastercard replace the card number with a token the scheme keeps current when a card is reissued, raising approval rates and cutting fraud. Provisioned once in the vault, they can be used across several acquirers.

What does orchestration change for a merchant with three PSPs?

Consider a European web shop processing €2 million a month at a €50 average basket: €1.5 million on cards, €0.4 million on local methods such as iDEAL and BLIK, and €0.1 million in crypto, across a global card PSP, a domestic interchange++ acquirer and a crypto processor.

With orchestration, EEA consumer debit goes to the interchange++ acquirer, other cards to the global PSP, and soft declines cascade between the two. These figures are a hypothetical, illustrative example, not OrsunPay results or a forecast: real outcomes depend on your card mix, provider contracts and traffic.

Do you need a payment orchestration platform, and should you build or buy?

Orchestration typically pays off with two or more PSPs, several countries or currencies, local methods your main PSP lacks, or a high-risk vertical where an account can be terminated at short notice. A single-country shop with one PSP usually gains little. For the full trade-offs of building in-house versus using a platform, see our build vs buy payment orchestration comparison.

Which payment orchestration companies are there?

The market splits into enterprise platforms for merchants, white-label software for PSPs and banks, and open source. Connector counts are the vendors' own figures and not directly comparable.

To add orchestration through OrsunPay, you connect your existing PSP accounts and integrate one API with signed webhooks; OrsunPay is a technical service provider that never holds funds. Rule-based smart routing and cascading are live.

How to add a second PSP

1. Define the reason for the second PSP Name the gap: approval in one country, cost on debit cards, a local method or an outage fallback. It decides which provider to sign and the first routing rule.
2. Sign the merchant contract Open an account with the new PSP under your own legal entity. The orchestrator connects the account but cannot sign or underwrite it for you.
3. Connect it through one integration Add the PSP's API credentials and webhook secret as a new connection, so checkout, refunds and reports keep using the same API.
4. Make stored cards portable For saved cards or subscriptions, move credentials to a PSP-independent vault or request a card-data migration, and provision network tokens.
5. Start with a small, measurable rule Route a slice, such as 10% of one country, to the new PSP and compare approval rate, cost and 3-D Secure friction for at least two weeks.
6. Add failover and widen routing Enable cascading for technical errors and retryable soft declines, widen the rules, and reconcile both PSPs' settlements monthly.