Do payment operators need a separate orchestration layer?

Not when routing, fallback and provider connections are part of the payment platform itself. Routing rules and a global payment network give operators the same control over providers, under their own brand.

Where orchestration came from

Orchestration platforms appeared for large merchants that used several PSPs and needed one API to route between them. The merchant kept its PSP contracts and added a layer on top. For a payment operator that runs its own platform, the question is different: the operator already owns the provider connections.

When a separate layer makes sense

• The operator's platform cannot connect new providers quickly.
• Routing rules are hard-coded and cannot be changed per merchant.
• Fallback between providers does not exist.

When it does not

If routing, fallback and provider connections are features of the platform itself, a separate orchestration layer adds a hop, a fee and a second place where transactions live. The operator ends up reconciling its own platform against the orchestrator. The better test is control: can the operator decide, per merchant and per market, which provider gets each transaction, and change that decision without a release? If yes, the orchestration is already there. The brand matters too: a merchant should see the operator's routing, not a third party's.

The cost of an extra layer is also paid in data: two systems each hold a version of the transaction, and reconciliation has to prove they agree.