Payment orchestration vs payment gateway (2026): what is the difference?

A payment gateway and a payment orchestration platform both sit between your checkout and the banks, which is why the terms get mixed up. They do different jobs. The gateway is the connection to one provider’s processing. Orchestration is the decision layer above several providers: it picks a provider for each payment, retries elsewhere when one declines, and gives you one integration and one report across all of them.

This page is the reference explanation on omno.com. It defines both, shows where each is stronger, and gives a simple test for which one you need.

What is a payment gateway?

A payment gateway is the service that takes payment details from your checkout, passes them to the processor or acquiring bank for authorization, and returns the approve or decline response. Wikipedia’s definition describes it as facilitating a payment by transferring information between the payment portal and the processor or acquiring bank, and notes that the gateway is not directly involved in the money flow.

Gateways often do more than pass messages. Many reduce the merchant’s PCI DSS scope by collecting card data in hosted fields, run fraud checks such as velocity and address verification, and connect several acquirers and payment methods inside one provider’s system. When people say “our gateway”, they often mean their payment service provider (PSP) as a whole.

What is payment orchestration?

Payment orchestration is a layer that sits between a business and its payment providers. Adyen describes it as routing transactions across multiple providers, applying rules such as geography or payment method, and redirecting payments when a primary route fails. One integration to the orchestrator gives access to every connected gateway, PSP and local payment method.

In practice an orchestrator adds four things a single gateway cannot:

1. Routing across competing providers. Rules choose the PSP for each payment by country, method, currency, BIN, amount or customer attributes.
2. Cascading and failover. When one provider returns a soft decline or times out, the payment is retried on the next eligible provider without the customer re-entering anything.
3. Provider-independent tokens. Saved cards are stored in the orchestrator’s vault and can be charged through more than one PSP.
4. One view across providers. Approval rates, decline reasons and settlement data are reported in one place.

How does one payment flow through each?

Through a gateway:

1. The customer enters card details in the gateway’s hosted fields or payment page.
2. The gateway sends the authorization request to its acquirer, which passes it through the card network to the issuer.
3. The issuer approves or declines, and the response comes back through the same path.
4. If the issuer declines, the payment has failed. The customer can try another card, but the merchant has no second route.

Through an orchestrator:

1. The customer enters card details in the orchestrator’s hosted checkout or fields, and the card is tokenized.
2. Routing rules check which providers are eligible for this card, country, currency, amount and customer, and pick the first.
3. The orchestrator sends the payment through that provider’s gateway.
4. If the provider is unavailable or rejects the request, the orchestrator sends the same payment to the next eligible provider in the rule. Some orchestrators cap attempts or stop on hard declines; in Omno the payment moves through the rule until one provider accepts.
5. The final status reaches the merchant once, by webhook, with a log of every attempt.

The customer sees one payment in both cases. The difference is what happens between the first decline and the final answer.

Where is a payment gateway stronger?

Simplicity. One integration, one contract, one dashboard, one support team. There are no routing rules to design or maintain.

Data in one place. When one provider sees all of your payments, its fraud models and authorization optimizations have the full picture. Adyen points out that splitting transactions across providers can weaken conversion optimization, fraud detection and customer recognition.

Fewer moving parts. Every extra layer is another possible point of failure and another vendor to manage. Adyen’s guidance is candid that orchestration can redistribute risk rather than reduce it, and that it shifts complexity rather than removing it.

Cost. You pay your provider’s processing fees and nothing on top. An orchestrator usually adds a platform or per-transaction fee.

Speed to new provider features. New methods and features arrive when your provider ships them, without waiting for an orchestrator to support them.

Where is payment orchestration stronger?

Coverage. No single PSP is strong in every country. A merchant selling in Kazakhstan, the UAE and Brazil may need different acquirers and local methods in each. Orchestration connects them behind one API.

Decline recovery. A soft decline at one acquirer is not always a decline everywhere: issuers treat acquirers, merchant category codes and risk profiles differently. Cascading sends a recoverable decline to a second provider. Our guide to cascading and decline recovery explains which declines to retry and which never to retry.

Resilience. When a provider has an outage, failover keeps payments flowing through another route.

Negotiating position. When traffic can move between providers, no single provider holds all of it.

Regulated and high-risk sectors. Merchants in these sectors often route by customer segment and verification level and keep a backup acquirer ready. That is orchestration work, not gateway work.

How do pricing and commercial models differ?

A gateway or PSP usually charges per transaction, either as a blended rate or as interchange plus scheme fees plus a markup, sometimes with monthly or setup fees. With orchestration you keep paying each PSP for processing and add the orchestrator’s fee, which is typically a platform fee, a per-transaction fee or both.

The business case for orchestration therefore rests on the extra approvals, lower processing costs from routing, and avoided outage losses being worth more than the added fee. Check whether the orchestrator bills every attempt, including cascaded retries, or only successful payments. Omno’s pricing is not published; ask for a quote in the same structure as your current provider’s so you can compare.

How do you move from a gateway to orchestration, or run both?

You rarely need to replace your gateway. The usual path is:

1. Connect your existing PSP through the orchestrator. Nothing changes for that traffic except the integration point.
2. Add a second provider for one market or one problem, such as a country with weak approval rates.
3. Turn on cascading with at least two providers in each rule, so a payment one provider rejects can move to the next.
4. Move saved cards deliberately. Tokens issued by your current provider’s vault stay there unless both sides support a PCI-compliant migration or network tokens.
5. Keep webhooks as the source of truth for payment status, from whichever provider processed the payment.

Measure approval rate on unique payment intents before and after. Our guide on how to calculate approval rate shows the formula and the common mistakes.

Who should choose which?

A single payment gateway is enough if:

• You sell in a few markets that one provider covers well.
• Your approval rate is healthy and stable, and declines are mostly genuine.
• Outages have not caused material revenue loss.
• Your team has no capacity to own routing rules.

Payment orchestration is worth it if:

• You already use, or need, more than one PSP.
• You sell in markets where local methods and local acquirers matter.
• You sell in a high-risk category where issuer behaviour varies widely.
• You need payments, payouts and saved cards to work across providers.

How we compared

Omno is a payment orchestration platform, so we have an interest in this question. We have tried to state the gateway case fairly and drew on Adyen’s own published view of orchestration’s trade-offs, which argues the limits of orchestration openly. The table compares the two concepts, not specific products; individual gateways and orchestrators vary. Sources are linked from each row and listed below. This page will be reviewed quarterly.