Are 'cashier' and 'payment gateway' the same thing?

No. The cashier is the player-facing UI — the deposit form, method picker, validation, and confirmation. The payment gateway is the back-end processor that authorises card or APM transactions. Operators need both, and the same vendor sometimes provides both bundled together.

Can the cashier and the payment gateway come from the same vendor?

Yes — that's the model PaymentIQ, Praxis, and Nuvei use. It's faster to integrate but creates lock-in, because changing PSPs means changing cashiers (or vice-versa). Modern operators increasingly separate the two.

What's an example of each?

Examples of cashiers: Fluid (modern, brand-controlled), PaymentIQ Cashier (hosted iframe), an in-house cashier built by larger operators. Examples of payment gateways: Worldline, Adyen, Nuvei, Praxis, Worldpay. The cashier renders the UI; the gateway authorises the transaction.

Which one should an operator focus on first?

Both are required, but the cashier drives more variance in deposit conversion. A best-in-class cashier on a mid-tier gateway often beats a mid-tier cashier on a best-in-class gateway. If only one can be improved at a time, focus on the cashier.

What does an orchestrator do that a gateway doesn't?

An orchestrator sits between the cashier and one or more gateways. It decides which gateway to route a transaction through, retries failed transactions, applies failover, and unifies reporting. Modern operators run an orchestrator above their gateways, with a cashier UX layer above the orchestrator.

iGaming Cashier vs Payment Gateway: The Real Difference

What's the difference between an iGaming cashier and a payment gateway? Definitions, where each lives in the stack, and why operators need both.

The fastest way to misalign two payment-team conversations is to assume “cashier” and “payment gateway” mean the same thing. They don’t, and the difference matters when you’re evaluating vendors, building integration plans, or troubleshooting why deposit conversion is below where you expected.

This is the explainer for whoever’s joining the conversation new — whether a product manager, a new payments analyst, or a vendor evaluating their first iGaming RFP.

Definitions, in one paragraph each

What a cashier is

The cashier is the player-facing user interface for depositing money and withdrawing winnings. It’s what the player sees when they click “Deposit” inside the operator’s app or website: the amount field, the payment-method picker, the form fields for card details or pay-by-bank, the 3DS prompt, the success or failure message, the saved-method list. Everything in the player’s deposit journey is the cashier.

A cashier renders. It doesn’t move money itself.

What a payment gateway is

The payment gateway is the back-end service that authorises and processes the transaction. It’s the PSP — Payment Service Provider — that connects to card schemes (Visa, Mastercard) or alternative payment methods (Trustly, Pix, Apple Pay) and gets the actual auth response back. Its API is what the cashier calls when it has all the data it needs.

A gateway processes. It doesn’t render.

What an orchestrator is

The orchestrator sits between the cashier and the gateways. It decides, transaction by transaction, which gateway to route through. It handles retries, failover, smart routing rules, and unified reporting. Most mid-to-large operators have an orchestrator; smaller ones often run direct cashier-to-gateway with no orchestration layer.

Picture of the stack

In modern iGaming setups, the layers look like this:

Player
  ↓ interacts with
Cashier         ← UI: deposit form, method picker, validation
  ↓ calls
Orchestrator    ← Routing: which PSP, retries, failover
  ↓ routes to
Payment Gateway ← Processor: card auth, APM settlement
  ↓ moves money via
Card schemes / banks / wallet networks

In legacy setups, the orchestrator layer is missing — the cashier talks directly to one gateway, with no intelligent routing. In hosted-PSP-cashier setups, the cashier and the gateway come from the same vendor and are tightly coupled. In modern setups, the layers are clearly separated and operator-controlled.

Why operators confuse them

A few reasons:

Vendor naming. PSPs sell “cashier solutions” that actually bundle gateway + cashier. Cashier vendors sometimes sell “payment platforms” that include orchestration and routing. The product names don’t always reflect which layer is being sold.
Single-product origin. Many operators started with a hosted PSP cashier 5-10 years ago. Cashier and gateway came as one product. The mental model of “they’re the same thing” stuck.
Search overlap. Generic searches like “iGaming payment provider” can mean any of the three layers. Buyer-side documentation often doesn’t distinguish until late in the evaluation.

Why the distinction matters

Three operator-impact reasons:

Reason 1 — Conversion

The cashier drives most of the variance in deposit conversion. A modern, brand-controlled cashier with smart UX can lift conversion 5-12pp over a hosted iframe cashier on the same underlying gateway. The gateway matters too (approval rate, retry logic), but the cashier is where most of the player-experience compound effects live.

Reason 2 — Vendor lock-in

If your cashier and gateway are bundled, changing one means changing both. That’s a 6-9 month migration, not a Q1 procurement decision. Separating the two layers means you can swap a PSP without re-integrating the cashier, and rebrand or redesign the cashier without changing PSPs. The flexibility compounds over years.

Reason 3 — Innovation cadence

Cashier UX evolves faster than gateway processing. Apple Pay, Google Pay, biometric authentication, in-flow KYC, AI personalisation — these are all cashier-layer innovations. A bundled product moves at the slower of the two roadmaps. Separating them lets each layer evolve at its own pace.

What lives where

If you’re building or troubleshooting, here’s the rough breakdown:

Concern	Cashier	Orchestrator	Gateway
Form fields and validation	✓	–	–
Method ranking and selection	✓	–	–
Saved cards (UI)	✓	–	–
Saved cards (storage)	–	–	✓
Tokenisation	–	sometimes	✓
3DS UI / challenge sheet	✓	–	–
3DS protocol exchange	–	sometimes	✓
Smart routing / failover	–	✓	–
Retry logic	shares	✓	–
Card auth	–	–	✓
APM settlement	–	–	✓
Branding / theming	✓	–	–
In-flow KYC UI	✓	–	–
KYC vendor calls	–	shares	✓
Per-player personalisation	✓	–	–
Approval-rate analytics	shares	✓	✓
Conversion-rate analytics	✓	–	–
Decline-reason mapping	shares	✓	✓

Common operator misconfigurations

Once you have the mental model right, you start to see misconfigurations more clearly. The recurring ones:

Cashier doing routing logic. Some legacy cashiers hardcode “if this method, route via PSP X”. This is orchestrator work, not cashier work. Result: changing routing requires a cashier release, which is slow.
Gateway doing UI work. Some PSPs return HTML strings or formatted error messages intended to render directly. The cashier ends up displaying the gateway’s copy verbatim. Result: inconsistent player-facing language across methods.
Orchestrator missing entirely. Cashier talks to one gateway; no failover, no retries. Result: a 30-minute PSP outage costs an entire 30 minutes of deposits.
Two cashiers (web + mobile native). Cashier code duplicated across web and mobile teams; UX drifts between them. Result: tracking discrepancies, inconsistent conversion.
Redirect-out KYC. KYC happens on a separate page after the cashier closes. Result: 12-25% drop on first deposits.

Where Fluid sits

Fluid is a cashier UX layer. We render the player-facing experience. We don’t process payments and we don’t underwrite operators. We integrate above any orchestrator (or directly with one or more gateways for operators who don’t run orchestration), and we work alongside whichever fraud, KYC, and analytics tools the operator has chosen.

If you’re putting a stack diagram together for an internal review and aren’t sure how the layers should interact, we’d love to help — even if Fluid isn’t the right product for your situation. The right shape of the stack is the same conversation regardless of who provides each layer.

For deeper reading: How to Choose an iGaming Payment Gateway, iGaming Payment Solutions Comparison, and Building an iGaming Payment Tech Stack.