Is payment orchestration a replacement for a payment gateway?

No. They sit at different levels of the stack. A gateway authorises and settles transactions; orchestration decides which gateway each transaction goes to and what happens when one declines. Orchestration without at least one gateway underneath it processes nothing. The real decision is not which to buy — it is where the routing logic should live.

At what point does an iGaming operator need payment orchestration?

The practical trigger is three live PSPs, or two PSPs across more than two markets. Below that, the routing rules are simple enough that your PSP's native failover or a few hundred lines in your own backend will do the job for less money. Above it, the combinations grow faster than anyone can maintain by hand.

Can a cashier layer do orchestration?

Some can, and increasingly the routing question is settled inside the cashier rather than in a separate product. What matters is not which box the logic sits in but whether you can change a routing rule without a vendor ticket. If a rule change takes a sprint of someone else's roadmap, you don't functionally own your routing regardless of what the architecture diagram says.

How much does payment orchestration cost?

Either a per-transaction fee in the low single-digit cents, a monthly platform licence in the low thousands, or both. The number that decides viability is not the fee — it is the fee measured against recovered revenue. If orchestration recovers one percentage point of auth on 3M EUR monthly volume, it has roughly 30,000 EUR a month to justify itself against.

What's the risk of orchestration becoming a new single point of failure?

It is real and under-discussed. Putting every transaction through one routing layer means an incident there stops all deposits, including the ones your redundant PSPs could have served. Ask any orchestration vendor for their incident history, their published status page, and what happens to in-flight transactions during a failover — before signing, not after.

Payment Orchestration vs Gateway for iGaming

A decision framework for iGaming payment solutions: when orchestration earns its licence fee, when a second gateway is enough, and when it's neither.

“Should we use payment orchestration or a payment gateway?” is the wrong question, and answering it as asked is how operators end up paying a licence fee for capability they already had.

They are not alternatives. A gateway authorises transactions. Orchestration decides which gateway gets each transaction. You cannot run orchestration without a gateway underneath it, and every operator processing money already has the gateway.

The question worth answering is narrower: where should routing logic live, and is that somewhere worth paying for? This is a framework for deciding that, with thresholds rather than adjectives.

The four places routing can live

Every operator running more than one provider has routing logic somewhere. The only variable is who maintains it.

1. Inside your primary PSP. Most large gateways offer native failover to their own secondary rails. Free, already there, and limited to that vendor’s estate — it cannot route to a competitor.

2. In your own backend. A routing table and retry rules you wrote. Cheapest at small scale, fully controlled, and it becomes a maintenance liability at roughly the point where the rules stop fitting on one screen.

3. In a dedicated orchestration platform. IXOPAY, Spreedly, BR-DGE, Primer, or an iGaming-native option like Praxis. Purpose-built, vendor-neutral, and priced accordingly.

4. In the cashier layer. The routing decision made where the player-facing retry conversation happens, so a decline and the response to it are handled in one place rather than two.

None of these is correct in the abstract. Which one fits is determined by four measurable things about your operation.

The four gates

Run your operation through these in order. The first gate you fail tells you where to stop.

Gate 1 — How many PSPs are actually live?

Not contracted. Live, taking production traffic this month.

One: You do not have a routing problem. You have a redundancy problem. Adding a second PSP will do more for you than any orchestration product, because right now a provider incident takes 100% of your deposits with it. Solve that first.
Two: Borderline. Your PSP’s native failover or a modest amount of your own code will handle this. Buying orchestration here is usually premature.
Three or more: Routing combinations have outgrown hand-maintenance. Proceed to Gate 2.

Gate 2 — How many markets, and how different are they?

Three PSPs serving one country is a simpler problem than two PSPs serving six countries with different local methods in each.

Count the distinct market/method pairs you support — Sweden/Trustly, Germany/cards, Brazil/Pix, and so on. Under about eight pairs, the rules stay comprehensible. Past fifteen, nobody on your team holds the whole picture, and the routing table starts drifting from the intended behaviour without anyone noticing.

Gate 3 — Does the recovered revenue clear the fee?

This is the gate most operators skip, and it is the only one that is straightforwardly arithmetic.

Orchestration earns its keep by recovering declines that would otherwise have died. So:

monthly deposit volume × expected auth-rate uplift = monthly value recovered

A realistic uplift from adding genuine cross-provider retry to a setup that has none is one to three percentage points. Be conservative and model one.

Monthly deposit volume	Value of +1pt auth	Verdict against a typical fee
500K EUR	5,000 EUR	Marginal — fee eats most of it
2M EUR	20,000 EUR	Clears comfortably
10M EUR	100,000 EUR	Not a close call

Below roughly 1M EUR monthly volume, a dedicated orchestration licence is hard to justify on recovered revenue alone. That does not make it wrong — it makes it a bet on where you will be in eighteen months, which is a legitimate reason to buy but a different one, and it should be argued as such rather than dressed up as ROI.

Gate 4 — Where is your conversion problem actually located?

This gate disqualifies more orchestration purchases than the other three combined.

Pull your deposit funnel and split the drop-off:

Players who opened the cashier and never submitted
Players who submitted and got declined
Players who got declined and did not retry

Orchestration only addresses the middle group. If most of your loss is in the first — players who saw the deposit form and abandoned before entering anything — no amount of routing intelligence will help, because those transactions never reached a gateway. That is a UI, method-mix or trust problem, and it is usually the larger number.

In the funnels we see, pre-submission abandonment is frequently two to four times the size of the decline bucket. Buying a routing product to fix a rendering problem is an expensive category error, and it is common precisely because routing products are easier to shop for than UX changes.

Four operator profiles, worked through

Single-market casino, 400K EUR/month, one PSP. Fails Gate 1 and Gate 3. Add a second PSP for redundancy, use its native failover, and spend the orchestration budget on the deposit form. Revisit in a year.

Multi-market sportsbook, 3M EUR/month, four PSPs, six countries. Passes all four gates. This is the profile orchestration was built for — the market/method matrix is past hand-maintenance and the volume clears any plausible fee several times over. Buy it, and be specific about incident behaviour in the contract.

Sweepstakes operator, 1.5M EUR/month, two PSPs, US only. Passes Gate 3, fails Gates 1 and 2. The routing problem is small; the real constraints are card acceptance under sweepstakes MCCs and dispute rates. Money is better spent on acceptance and dispute tooling than on a routing layer with two destinations to choose between.

Established casino group, 8M EUR/month, five PSPs, hosted vendor cashier. Passes every gate, and already has orchestration — bundled inside a hosted cashier it cannot modify. The decision here is not whether to buy orchestration but whether to separate it from the cashier, and that turns entirely on the next section.

The switching-cost test

Whatever you choose becomes the thing you have to leave eventually. Three questions decide how expensive that will be, and they are worth asking before signing rather than at renewal:

Can you export the tokenised card vault in a portable format? If not, switching means every stored card in your player base has to be re-entered. That is a retention event affecting your highest-value depositors, and it is the most effective lock-in mechanism in payments precisely because it never appears in a contract as a restriction.
Can you change a routing rule yourself, today? If a rule change requires a vendor ticket, you do not own your routing in any operational sense. The architecture diagram is irrelevant; the sprint calendar is what matters.
Who holds the PSP contracts? If the orchestration vendor holds them, your commercial rates are theirs to negotiate, and leaving means renegotiating every provider relationship from scratch. If you hold them, the routing layer is genuinely swappable.

An operator who answers “no, no, the vendor” to these is not buying orchestration. They are buying a dependency that happens to route transactions, and it should be priced as one.

When orchestration is the wrong purchase

Stated plainly, because vendors rarely will:

You have one or two PSPs. The problem is redundancy, not routing.
Your losses are pre-submission. Routing cannot recover a transaction that was never attempted.
Volume is under about 1M EUR/month. The arithmetic does not work yet.
You have nobody to own the rules. An orchestration platform with unmaintained routing logic converts worse than a single well-configured PSP, because now the failure modes are distributed and harder to see.
You are buying it to fix reconciliation. Reconciliation is a data problem. Some orchestrators help with it, but buying a routing product for its reporting is paying a premium for the wrong feature.

Where to start this week

Do the Gate 4 split before anything else, because it determines whether the rest of this exercise is relevant at all. One query, three numbers: cashier opens, submissions, approvals. Then the ratio between them.

If submissions ÷ opens is below about 60%, your money belongs in the deposit experience, and no routing layer will change that number. If it is healthy but approvals ÷ submissions is weak, you have a genuine routing problem — then run Gates 1 to 3 and see whether it is one a licence fee should solve or one a second PSP already solves for free.

For the layer underneath this decision — what a gateway costs, which auth rates to expect, and how the major providers compare — see the iGaming payment gateway operator’s guide. If you are running an RFP off the back of this, the payment orchestration RFP template has the questions that produce comparable answers.