Payment Orchestration, Explained for Banks and PSPs Actually Deciding Whether to Build It
Orchestration is the layer that decides, for every transaction, which payment provider handles it, and what happens automatically if that provider fails. Without it, that decision is usually static: whoever integrated the first provider made the call once, in code.
The three problems it solves
Provider failure. Every rail, mobile money aggregator, or card processor has downtime or degraded performance. With only one provider per payment method, their bad day is your bad day. Orchestration fails over to a second provider automatically, mid-flow. Cost. Providers price differently by method, size, and corridor. Routing rules send each transaction to whichever provider is cheapest for that case, instead of everything going through whoever was integrated first. Reconciliation. Multiple providers means multiple settlement formats and timings. Reconciling all of them by hand doesn't scale. Unified reconciliation gives one settlement view regardless of which provider actually processed the transaction.
What "smart routing" looks like
Method-based rules. Mobile money to Provider A, cards to Provider B. Performance-based rules. Route away from a provider whose success rate is degrading, before it fully fails. Cost-based rules. Route by value or corridor to the cheapest option. Manual overrides. Let operations force routing during an incident, without an engineering deploy.
Build or buy
If you're on a single provider per method, orchestration is premature; there's no redundancy to manage yet. It becomes worth it once you're running two or more providers for the same method, or after an outage has already caused a customer-facing incident. The part that usually stalls in-house builds isn't the routing logic, it's keeping reconciliation correct as providers get added or swapped.
Take it further
See how the principle applies to a real product and provider setup.
