Payment orchestration: build in-house or buy a provider?
What payment orchestration actually is, when to buy it, and where a build partner fits.
What is payment orchestration?
Payment orchestration is the layer that sits above your individual payment providers and decides how each transaction is routed, retried, and settled across multiple rails and acquirers. Instead of wiring your platform directly to each PSP, bank, or rail one connection at a time, an orchestration layer gives you a single integration point that handles routing logic, failover, retries, and reconciliation across all of them.
The reason this matters is structural. The alternative — point to point integration, where every provider is wired directly into your core — works beautifully for the first one or two connections and becomes a maintenance trap by the third or fourth. Every new provider multiplies the number of direct couplings, every change ripples unpredictably, and the system becomes brittle exactly as your business becomes dependent on it. Orchestration replaces that tangle with a clean layer.
The question is not whether you need orchestration as you scale. It is whether you buy an orchestration provider or build the layer yourself. This is the payment orchestration build vs buy decision, and it turns on a single distinction: is routing a commodity, or your edge?
When to buy from payment orchestration providers
Buying — using a provider such as Spreedly or Gr4vy, or the orchestration features inside platforms like Stripe or Adyen — is the right call when:
- Your routing needs are standard: pick the cheapest or highest-converting acquirer, retry on soft declines, fail over cleanly.
- You want to ship in weeks and treat orchestration as solved infrastructure.
- Your provider mix fits comfortably inside what the orchestration product supports.
For a large share of merchants and operators, this is genuinely the smart move. Orchestration is a well-understood problem, and renting a solved problem is good engineering discipline.
Where buying orchestration runs out
Bought orchestration runs into the same ceiling every product layer does, and it runs into it precisely when orchestration is a differentiator rather than a commodity:
- Routing logic you cannot express. If your edge is a non-standard routing strategy — corridor-specific liquidity optimisation, custom settlement timing, a local rail the provider does not support — you are constrained to what the product allows.
- Ownership and lock-in. Your routing intelligence lives inside someone else’s system. Migrating off it later is a multi-quarter project.
- Per-transaction economics. Orchestration pricing, like PSP pricing, compresses margins at high volume — model the fee × your projected volume against the cost of owning the layer before you assume buying stays cheaper.
If routing across rails is part of how you compete — common for cross-border operators juggling SWIFT/gpi, SEPA Instant, local instant schemes, and emerging stablecoin settlement — renting that intelligence eventually caps your differentiation.
When to build your own orchestration
Building your own orchestration layer is the right call when routing is a differentiator, your rail mix is heterogeneous and growing, and you need to own the logic for economic, audit, or strategic reasons.
The engineering is non-trivial and worth respecting. A production orchestration layer needs saga orchestration to manage multi-step, long-running payment flows that must either complete or compensate cleanly; idempotent webhook handling so a retried or duplicated provider callback never double-processes a payment; observability deep enough to debug a routing decision after the fact; and reconciliation that holds across every rail. Get these wrong and a custom orchestration layer is more dangerous than the point-to-point tangle it replaced.
A useful test before committing to build: if your team cannot confidently explain how it would handle each of those four — saga orchestration, idempotency, observability, reconciliation — that gap is the signal to embed a partner, not to learn them live in production.
This is the engineering FreySoft built for WorldRemit (now Zepz) — orchestrating transfers across 130+ countries and 70+ currencies, optimised to run 24/7 at over 100,000 payment transactions a day, with the corridor and routing logic owned by WorldRemit. Building orchestration that survives that volume and reliability bar is a domain skill, not a generic backend task.
The decision
| Your situation | Lean |
|---|---|
| Standard routing, standard rails, want speed | Buy a provider |
| Outgrown one PSP, routing still commodity | Buy — orchestration provider |
| Routing is a differentiator; heterogeneous, growing rail mix | Build (or embed a partner to build) |
| Need to own the logic for economics / audit / independence | Build / embed |
| Should build, but lack senior payments engineering capacity | Embed a specialist partner |
As with corridor logic, the build-versus-buy answer is a strategy question and the in-house-versus-embed answer is a capacity one. If routing is commodity, buy it and move on. If routing is your edge, own it — and if you cannot staff the senior payment engineering to build orchestration that survives production, embed a partner who has built it before rather than learning saga orchestration and idempotency the expensive way.
Building orchestration as part of a wider corridor strategy? See “How fintechs actually add new payment corridors,” or talk to our payments team.
