# Payment orchestration explained What a payment orchestration platform does, how routing and failover work, and when a business should use more than one processor. By Pablo Albrecht, CEO, Orchestrapay Page: https://www.orchestrapay.com/resources/guides/payment-orchestration-explained ## Key takeaways - Payment orchestration is a layer between your checkout and your processors: you integrate once, and it decides which processor handles each payment. - Routing rules send each payment by country, amount, currency, BIN or percentage split, and failover retries soft declines and outages on another processor. - Never retry hard declines anywhere, because card schemes watch retry behavior and repeated retries can lead to fines. - A card vault you own keeps saved cards usable on every processor, so switching processors does not touch your customers' stored cards. Payment orchestration is a layer that sits between your checkout and your payment processors. You integrate it once, and it decides which processor handles each payment, retries failures somewhere else and keeps your customers' saved cards usable on every processor you connect. This guide covers what an orchestration platform does, how routing and failover work in practice, and how to tell whether your business needs one. ## The problem orchestration solves Most businesses start with one processor. It is the fastest way to take payments, and for a while it is enough. The limits show up as you grow: - **A single point of failure.** If your processor has an outage, or freezes your account during a risk review, checkout stops. - **Declines you cannot fix.** Every processor approves some cards better than others. With one processor, a declined payment is simply lost. - **Locked-in cards.** Saved cards usually live in your processor's vault. Moving to another processor means asking customers to enter their cards again, or negotiating an export. - **No leverage.** When all your volume sits with one processor, you have little room to negotiate pricing. Integrating a second processor directly fixes some of this, but each integration has its own API, its own webhooks and its own way of handling 3D Secure, refunds and saved cards. The work grows with every provider. ## What a payment orchestration platform does ### One integration, many processors You build against one API and one payment form. The orchestration platform maintains the connections to each processor, so adding or removing a processor does not change your code. ### Routing Routing rules decide where each payment goes. Typical conditions include: - The customer's country - The amount and currency - The card's BIN, which identifies its brand, type and issuing bank - The customer's IP range - A percentage split, for example 70% to one processor and 30% to another Rules are evaluated per payment, so you can send domestic cards to a local acquirer, large tickets to the processor with the best rate for them, and a slice of traffic to a new provider you are testing. ### Failover and cascading When a processor declines a payment or fails to respond, the platform can retry it on another processor before the customer sees an error. Good orchestration separates failures by type: - **Hard declines**, such as a stolen card, should not be retried anywhere. - **Soft declines**, such as a temporary issuer problem, are worth a second attempt elsewhere. - **Outages**, where the processor itself is down, should move traffic to a backup straight away. Retrying everything is a mistake. Card schemes watch retry behaviour, and repeatedly retrying hard declines can lead to fines. Route failures by type, not by default. ### A card vault you own An orchestration platform stores cards in its own PCI DSS compliant vault and keeps a token for each processor a card has been charged on. Saved cards follow your routing rules, and switching processors does not touch your customers' stored payment methods. ### Authentication and wallets 3D Secure, Apple Pay and Google Pay work differently on every processor. An orchestration layer gives you one flow for each, whichever processor ends up taking the payment. ## How a routed payment flows 1. The customer pays in your checkout, using the platform's hosted card form. 2. The card is vaulted and checked against your routing rules. 3. The payment goes to the processor the rules select. 4. If that processor declines softly or is unavailable, the payment cascades to the next processor in the rule. 5. The result comes back to your checkout, and your webhook receives one consistent event whichever processor handled it. ## Orchestration and PCI DSS scope Every business that accepts cards has to validate PCI DSS compliance. How much work that takes depends on where card numbers travel. If cards pass through your servers, most of the standard applies to your systems. An orchestration platform that captures cards in its own hosted form, on its own domain, keeps card numbers away from your infrastructure entirely. Your servers only ever see a token. For many merchants that shrinks the assessment to the shortest self-assessment questionnaire, with the final call made by your acquirer or assessor. See [PCI DSS compliance](/solutions/pci-dss-compliance) for how that works. ## What to look for in a platform Not every orchestration platform is built the same. Questions worth asking: - **Which processors are actually connected?** A long logo wall is not the same as live, maintained integrations. Ask which processors handle real traffic today. - **Who owns the card data?** You should be able to keep your saved cards if you leave the platform, not only if you leave a processor. - **How are failures classified?** Look for routing that treats hard declines, soft declines and outages differently. - **What can rules match on?** Country, amount, currency and BIN are the basics. Percentage splits make testing a new processor safe. - **Do 3D Secure and wallets work everywhere?** One authentication flow and one wallet integration should cover every processor you route to. - **How do you see what happened?** Per-processor response times and error codes tell you when a provider is degrading before customers do. ## When you need payment orchestration You probably need orchestration if any of these apply: - You sell in several countries and want local acquiring in each. - A processor has frozen your account, or you are in a vertical where that risk is real. - Your approval rate varies a lot by card country or issuer. - You want to add a processor without another integration project. - You want saved cards that are not locked to one provider. If you process low volume in one country with one processor and none of these apply, a direct integration is often simpler for now. The time to add orchestration is before the day you need a second processor in a hurry. ## Where to go next - [Smart Routing](/products/smart-routing) covers routing conditions and failover in detail. - [Card Vault](/products/card-vault) explains how saved cards stay portable. - [Reduce declines](/solutions/reduce-declines) shows how routing, network tokens and retries win back failed payments.