Meet us at conferences around the world
iGB L!VE London
SBC Summit Lisbon
SiGMA Europe
A gateway sends each payment to one bank. Orchestration decides which bank, in what order, and what happens when the first attempt fails. The real choice is whether you outsource the routing decision or own it.
One bank, one market? You need a gateway. Add a second bank and you need orchestration — a layer that picks a bank for each payment.
Get this choice right and you spend less on integrations, win back sales you used to lose, and open new markets in days. Get it wrong and you either pay for routing you never use, or you outgrow one bank and feel it in your approval rate every day.
So the core question isn’t «gateway vs orchestration» in the abstract. It’s: do you want to outsource routing, or do you want to own it?
Let’s strip away the jargon.
A payment gateway takes a card at checkout, encrypts the card details, asks one bank «can you approve this payment?», and then carries the result back to your store. It’s a single phone line between your business and one acquirer — the bank or processor that clears the payment.
Most businesses start here, and they should. One bank is enough to take your first payments in a single market with a single acquiring relationship.
Payment orchestration sits one floor up — as a smart routing layer above your gateways.
Instead of one phone line, it’s a switchboard:
For every payment, orchestration applies rules like:
«Send this card BIN and currency to bank A.»
«If bank A returns a soft decline, retry through bank B.»
«Keep local payment methods on the local rail.»The gateway answers:
«Can this go through here?»
Orchestration answers:
«Where should this go, and what do we do if it fails?»
So calling gateways and orchestration «rivals» is a mistake. Orchestration uses gateways. The honest question is not «gateway or orchestration», it’s whether a single gateway should carry your whole business or whether you need a routing brain above several of them.
Both take a card and return an approval code. They diverge as soon as you have more than one bank, more than one country, or a decline you want to win back. Think of the differences like this:
| Payment gateway | Payment orchestration | |
|---|---|---|
| Acquirer connections | One acquirer / processor per integration | Many acquirers, gateways and APMs behind one API |
| Routing logic | Fixed; each transaction goes where that gateway is wired | Rule-based and dynamic; routes by BIN, currency, amount, MCC, success rate, region, etc. |
| Declines | Returned as-is to the merchant — a loss unless you manually retry | Soft declines can be cascaded to an alternate acquirer |
| Redundancy | If the acquirer is down, payments stop | Traffic fails over to a healthy acquirer automatically |
| Tokenisation | Vault usually tied to one provider | Provider-agnostic vault, so the same token works across multiple acquirers |
| Reconciliation | One settlement file, one format, per bank | Normalised reporting across all connected acquirers |
| Adding a market | A new integration project per acquirer | A configuration change on the existing API |
| Best fit | Single market, single acquirer, predictable volume | Multi-acquirer, multi-market, or growth that has outpaced one bank |
You can read that whole table as one sentence:
A gateway executes a routing decision someone already made; orchestration makes that decision on every single payment.
The further your business moves toward «many banks, many countries, many methods», the more that difference compounds into hard gains or hard losses.
A single gateway is the right answer more often than orchestration vendors admit. Fit comes before price.
Pick a gateway if:
In this scenario, a solid gateway plus a strong acquiring relationship gives you a clean, maintainable stack.
Orchestration earns its place the moment one bank relationship stops being enough. The signals are concrete, not vague; you’ll recognise yourself in at least one:
| Signal | Why it points to orchestration |
|---|---|
| You run, or plan to run, more than one bank | The reasons are usually:
|
| You are losing recoverable money to declines | A real share of declines are soft — issuer timeouts, transient risk flags, temporary glitches. Cascading those soft declines to a second acquirer wins back sales a single gateway simply hands back as a loss. |
| You are growing into new markets | Local acquiring and local methods lift approvals and reduce cost, but each new provider is an integration. Orchestration turns «add a bank» into a routing rule instead of a multi-month project. |
| Reconciliation has become a tax | Every bank reports differently. When finance spends more time tidying settlement files than analysing them, a layer that normalises data across providers pays for itself. |
If any of these are true, you’ve outgrown «gateway only».
Here is the part that takes the pressure off the decision. Few companies pick between the two at the start. They begin with a gateway and add orchestration when the cracks show. Done in the right order, the move is low-risk.
One detail decides how clean the move is: the tokenisation vault — where your stored card numbers live. If that data sits inside a single gateway’s vault, «portable» tokens are portable only on paper. Moving them means migrating the raw card number, called the PAN — the full 16-digit account number — and re-tokenising everything, which is slow, sensitive work. A provider-agnostic vault, or network tokens you control, is what keeps banks swappable instead of sticky. Settle that before the second bank, not after.
Payneteasy is built bank-agnostic, and that is the point of this whole piece.
You don’t have to pick a side today:
Because it’s available white-label, PSPs and platforms can offer that routing intelligence under their own brand:
If you want help mapping «gateway vs orchestration» to your own numbers — bank count, markets, methods — Payneteasy’s team can walk it with you before you commit.
No. Orchestration sits above gateways and routes between them. You still need at least one bank connection; orchestration decides which bank handles each payment and what happens on a decline.
It can, in two ways: by routing each payment to the bank most likely to approve it, and by cascading soft declines — retrying them on another bank — instead of handing them back. The lift depends on how many of your declines are recoverable and how many banks you connect.
When you operate in one market through one bank with a stable approval rate. Routing has nothing to optimise, and the simplicity of one integration outweighs features you would not use.
Low-risk if you keep your current bank as the first route and add capability one step at a time. The one thing to plan early is the tokenisation vault, where your stored card numbers live. A provider-agnostic vault keeps banks swappable and avoids a card-data migration later.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
