A payment gateway is a single phone line between your checkout and one acquiring bank: encrypt the card, ask "can you approve this?", carry the result back. One integration, one settlement file, one support contact. Most businesses start here, and they should — with one market and one bank, that's the whole problem.
Payment orchestration sits one layer above that. Instead of one line, it's a switchboard wired to several gateways, banks and local payment methods behind a single integration. For every transaction it applies rules like "send this BIN to bank A, cascade a soft decline to bank B, keep local 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 gateway and orchestration aren't rivals — orchestration is built on top of gateways. The real question is whether a single gateway should carry your whole payment flow, or whether you need a routing layer above several of them.
Side by side
| Gateway | Orchestration | |
|---|---|---|
| Acquirer connections | one per integration | many behind one API |
| Routing | fixed | rule-based: BIN, currency, MCC, success rate |
| Soft declines | returned as-is, manual retry | cascaded to an alternate acquirer automatically |
| Redundancy | acquirer down = payments stop | failover to a healthy acquirer |
| Tokenisation | vault tied to one provider | provider-agnostic vault, same token across acquirers |
| Adding a market | new integration project | a configuration change |
Read that table as one sentence: a gateway executes a routing decision someone already made; orchestration makes that decision on every single payment.
When a gateway is still the right call
- One market, one bank. If all volume clears the same acquirer in the same currency, there's nothing to route — you'd be paying for options you never use.
- Approval rate is already healthy and stable. Cascading and failover solve a problem you don't have yet.
- You want the fewest moving parts. One integration is easier to reason about and to debug at 3am.
The concrete signals that you've outgrown it
- You run, or are about to run, more than one bank relationship — for approval rate, geography, or risk spread. The moment there are two banks, something has to decide between them for every payment; that something is orchestration.
- A real share of your declines are soft — issuer timeouts, transient risk flags — and a single gateway just hands them back as a lost sale instead of retrying elsewhere.
- Reconciliation across banks is eating more analyst time than the numbers are worth, because every bank reports differently and nothing is normalised.
Migrating is usually the real path, not "choosing on day one"
Few teams pick between the two at the start. The low-risk order is:
- Put orchestration in front of the gateway you already have. Your current bank becomes the first route — nothing about how payments clear changes yet, you've only moved the decision point.
- Add a second bank and one narrow routing rule (one card type or one country) and watch the approval rate before widening it.
- Turn on cascading for soft declines — this is usually where recovered revenue first shows up, measurable against your pre-migration baseline.
One thing decides how clean this move is: where the tokenisation vault lives. If stored card tokens sit inside a single gateway's vault, "portable" tokens are portable only on paper — moving them means re-tokenising the raw PAN for every card, which is slow and sensitive. Settle a provider-agnostic vault (or network tokens you actually control) before the second bank goes live, not after.
Where this leaves an integrator
Payneteasy is built bank-agnostic on purpose: the same connection you already have links to every bank you add afterwards, with routing and cascading handled above the acquirer layer rather than baked into one gateway's logic.
If you're evaluating this for your own stack, the question to ask isn't "gateway or orchestration" in the abstract — it's whether you're about to add a second bank relationship. If yes, decide where the routing brain and the vault live before you sign the second contract, not after.
Full writeup with the FAQ and migration checklist: https://payneteasy.com/blog/payment-orchestration-vs-gateway?utm_source=devto&utm_medium=social&utm_campaign=payment-orchestration-vs-gateway&utm_content=inline&service_type=orchestration
Top comments (0)