Infrastructure6 min read

Payment orchestration vs payment gateway: what is the actual difference?

A gateway moves a transaction. Orchestration decides where it goes. Where the line sits, and when you need both.

The two terms get used interchangeably, mostly by people selling one of them. They solve different problems, and the difference matters the first time a processor lets you down.

A gateway moves a transaction

A payment gateway takes card details from your checkout, encrypts them, and passes an authorisation request to a processor and on to the acquirer. It handles tokenisation, 3-D Secure, capture and refund. It is the pipe between your site and one processing relationship.

That is genuinely valuable and most merchants need one. But a gateway's job ends at delivering the transaction to the processor it is connected to. If that processor declines, the transaction is declined. If that acquirer closes your account, the gateway has nowhere to send anything.

Orchestration decides where it goes

Orchestration sits above the gateways. It holds connections to several processors and MIDs, and for each transaction it decides which one to use — on rules you set, on live performance, or both.

  • Routing: send this transaction to the acquirer most likely to approve it, by card type, issuing country, ticket size or billing model.
  • Cascading: when an attempt fails for a retriable reason, present it to a different processor rather than returning a decline to the customer.
  • Load distribution: split traffic across MIDs so no single account carries enough volume to attract attention.
  • Failover: when a processor degrades or an account is suspended, move the traffic without a deploy.
  • One reconciliation: settlements from several processors in a single ledger, rather than a spreadsheet per provider.

Where the third thing fits

Neither a gateway nor an orchestration platform is an acquirer. Both move transactions to acquiring relationships that you hold. That is fine until the problem is that nobody will give you the relationship — which, for merchants in restricted categories, is very often the actual problem.

This is worth checking carefully when you are evaluating platforms. An orchestration provider can route beautifully across MIDs you do not have. If your constraint is acquiring rather than architecture, you need a partner who can provide processing as well as route it.

When a gateway alone is genuinely enough

Orchestration is not free. It is another layer to configure, reason about and monitor. A single gateway is the right answer when your volume sits comfortably inside one MID's limits, you sell in one market on one currency, your category is not one acquirers get nervous about, and an outage would be an inconvenience rather than an existential event.

If that describes you, buy the simpler thing.

When it stops being enough

  1. You are approaching a monthly cap on your only MID.
  2. You sell in markets your acquirer prices badly or will not support.
  3. Your approval rate differs materially by issuer or geography and you cannot act on it.
  4. You run subscriptions, where a failed rebill is churn rather than a retryable order.
  5. You have been declined, reviewed or offboarded before, and know how the day goes.
  6. Reconciliation across providers is being done by a person and a spreadsheet.

Any two of those and a gateway is the constraint rather than the solution.