Architecture · Orchestration · 8 min read

When you need payment orchestration

Payment orchestration gets framed as something you graduate into once you are processing serious volume. That framing is wrong, and it is why teams reach for it a year after they needed it. Orchestration is not a scale problem. It is a risk problem, and the triggers arrive early.

What orchestration actually is

Strip away the vendor language and it is four things:

• One interface your application talks to, with providers behind it.
• Routing rules that decide which provider handles a given transaction - by method, currency, geography, cost, or whether the primary is currently up.
• Normalised events, so downstream systems do not care where a payment came from.
• One reconciliation view across providers, rather than a spreadsheet per provider.

Notice that none of that requires volume. It requires more than one provider, or the realistic prospect of one.

The triggers

In our experience the need shows up through one of five doors, and only the last is about size.

Redundancy. This is the underrated one. Providers have outages. If you have a single integration, their outage is your revenue stopping - you cannot take money at all, and the only mitigation is a status page and an apology. A second provider behind a routing rule turns a revenue-stopping incident into a degraded hour.

A structural change forced on you. A provider withdraws your merchant ID, changes their acceptable-use position, or decides your category is now high-risk. This can happen with little notice and it is not always negotiable. If your only integration is with the provider who just left, you are rebuilding under time pressure - the worst possible conditions.

Geography or method. You expand into a market where your provider's coverage is weak, or customers want a local method they do not support well. This one is predictable, which makes it the easiest to prepare for and the one teams most often leave until it is urgent.

Category risk. If you operate anywhere the schemes treat as elevated risk, single-provider dependency is a standing exposure. Underwriting decisions get revisited, and pricing moves with them.

Cost. The one everyone expects. At meaningful volume the difference between providers is real money, and routing by cost or by success rate pays for itself. But if this is the first trigger you hit, you have been lucky rather than prepared.

Four of the five triggers are about something going wrong. Only one is about growth. That is the case for building the layer before you think you need it.

Build or buy

Orchestration platforms exist and they are legitimate. They give you routing, normalised events and a reconciliation view without building it, and if you want that capability next quarter rather than next year, buying is the right answer.

The trade-offs are the obvious ones, and worth stating plainly:

• Cost is per transaction, usually basis points on top of what you already pay your providers. It scales with you, which is fine when it is small and less fine later.
• You have added a dependency in the middle of your money flow. That is a real consideration - you now have an additional party whose outage is your outage, and whose commercial decisions affect you.
• Your routing logic lives somewhere you do not control. For simple rules that is fine. For rules specific to your business, it can become the constraint.

Building it means a real project - the interface, adapters per provider, event normalisation, idempotency, reconciliation - but you own the routing, there is no per-transaction fee, and there is no extra party in the flow.

The honest rule of thumb: buy if you need it now and your routing needs are conventional. Build if payments are core to your product, if your routing depends on business logic a platform will not model, or if you are already at volume where basis points matter.

The cheap version, which most teams should do first

There is a middle path that costs days rather than quarters, and it is what we recommend to almost everyone: build the interface now, with exactly one adapter behind it.

You get no routing, no second provider, no orchestration. What you get is the option. When a trigger arrives - and one will - adding the second provider is a contained piece of work rather than a rewrite of checkout under deadline.

That is the whole argument. Orchestration is expensive to retrofit and cheap to prepare for, and the preparation is worth doing even if you never orchestrate anything.