Building an iGaming Payment Tech Stack in 2026
An engineering architecture guide to the modern iGaming payment stack — cashier, orchestrator, gateways, fraud, KYC — with build-vs-buy reasoning.
This is the architecture-team view of the iGaming payment stack — what each layer does, how the layers interact, where the engineering debt typically accumulates, and where a small operator should differ from a large one.
It’s written for engineering leads, payment platform architects, and CTOs who are evaluating new stack components or rebuilding an aging one. It’s deliberately not a vendor pitch — Fluid sits in one specific layer of this picture, and we’ll be explicit about that.
The reference architecture
A modern iGaming payment stack has roughly seven layers:
┌─────────────────────────────────────┐
1. │ Cashier UI (web component / SDK) │ ← What players see
└────────────┬────────────────────────┘
│
┌────────────▼────────────────────────┐
2. │ Cashier API / session service │ ← Stateful per-player session
└────────────┬────────────────────────┘
│
┌────────────▼────────────────────────┐
3. │ Orchestration / routing engine │ ← Which PSP, retries, failover
└────────────┬────────────────────────┘
│
┌────────┴────────┬──────────┬─────────┐
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌──────┐ ┌──────┐
4. │ PSP A │ 4. PSP B│ │ │ KYC │ │Fraud │ ← External services
└───────┘ └───────┘ └──────┘ └──────┘
│ │ │ │
┌───▼─────────────────▼──────────▼─────────▼───┐
5. │ Event bus / webhook router │ ← Async glue
└────────────┬─────────────────────────────────┘
│
┌────────────▼─────────────────────────────────┐
6. │ Player wallet / accounting │ ← Source of truth on balances
└────────────┬─────────────────────────────────┘
│
┌────────────▼─────────────────────────────────┐
7. │ Reporting / data warehouse │ ← Analytics, finance, BI
└───────────────────────────────────────────────┘We’ll walk each layer.
Layer 1 — Cashier UI
The player-facing component. In modern stacks this is a web component, SDK, or React/Astro component embedded in the operator app. It handles form rendering, method selection, validation, 3DS UI, error messaging, and saved-method display.
Key engineering considerations:
- Framework agnosticism (web component is the safe choice — works in React, Vue, Angular, plain JS)
- Design-token inheritance from the operator’s design system
- Accessibility (WCAG 2.2 AA at minimum)
- Mobile UX (iOS Safari is the highest-traffic browser in EU iGaming)
- Bundle size — the cashier should not block the page render
Build vs buy: usually buy. The depth of payment-method-specific UX (iOS Apple Pay sheet integration, Pix QR-code rendering, Trustly redirect handling) is significant.
Layer 2 — Cashier API / session service
The stateful service that holds an active deposit session. Tracks: which player, which method, what amount, which validation state, what 3DS response is awaited.
Key engineering considerations:
- Session timeout policy (15-30 minutes typical)
- Idempotency on retries
- Multi-tab handling (player opens cashier twice; what happens?)
- Webhook reception for asynchronous gateway responses
Build vs buy: typically bundled with the cashier UI. Building it standalone makes sense at large operator scale where the session service becomes a horizontal platform across multiple cashier surfaces.
Layer 3 — Orchestration / routing engine
The routing layer. Decides per transaction: which PSP, which method, which retry strategy. Configurable rules typically include geography, method, BIN range, time-of-day, decline-reason history per player.
Key engineering considerations:
- Real-time rule evaluation (sub-100ms typical SLA)
- Rule versioning and shadow-mode testing
- Auditability (every routing decision logged with rule ID)
- Failover semantics (if PSP A times out, when does PSP B get called?)
Build vs buy: at small scale, buy (IXOPAY, Spreedly, BR-DGE, Primer). At large scale (€10M+ monthly), some operators build their own because the routing rules become operator-specific IP. Most don’t, and shouldn’t.
Layer 4 — External services (PSPs, KYC, fraud)
PSPs do the actual processing. KYC vendors verify identity. Fraud tools score risk.
PSP picks for licensed iGaming in 2026: Worldline (owns PaymentIQ), Adyen, Nuvei, Praxis, Worldpay, Trustly, regional specialists.
KYC picks: Onfido, Sumsub, Veriff, Jumio, IDnow, ComplyAdvantage.
Fraud picks: Sift, Featurespace, Forter, Riskified, Sardine, in-house rules.
Key engineering considerations:
- Webhook reliability — every external service uses a different webhook contract
- Retry semantics if the operator-side webhook handler fails
- Data minimisation — never share more PII with vendors than required
- Sub-processor visibility (GDPR requirement)
Build vs buy: always buy. Building these in-house is a non-starter for cost and regulatory reasons.
Layer 5 — Event bus / webhook router
The glue layer. Receives webhooks from every external service, normalises them, routes to internal consumers (cashier session service, accounting, fraud, analytics).
Key engineering considerations:
- At-least-once delivery semantics with idempotency on consumer side
- Dead-letter queue for unprocessable events
- Webhook signature verification per vendor
- Replay-ability for backfills
- Lag monitoring (a 5-minute lag in webhook processing is a deposit-success-state lag for the player)
Build vs buy: typically build, on top of managed infrastructure (AWS EventBridge, GCP Pub/Sub, Kafka). The business logic in the router is operator-specific.
Layer 6 — Player wallet / accounting
The system of record for player balances. Increments on successful deposits, decrements on bets/withdrawals, holds for pending transactions.
Key engineering considerations:
- ACID guarantees (don’t run wallet on eventual consistency)
- Audit log per balance change with reason code
- Reconciliation against external statements (PSP settlement files, bank statements)
- Multi-currency handling (FX timing decisions)
- Refund handling (a refund is an inverse deposit, not a withdrawal)
Build vs buy: usually build. Wallet is the operator’s core IP; buying introduces vendor lock-in on the most critical piece. A few platforms (SBTech, EveryMatrix) provide it as part of a broader platform offering, but operators with in-house product teams typically own this.
Layer 7 — Reporting / data warehouse
BigQuery / Snowflake / Redshift typical. Receives streamed events from layers 1-6, becomes the source for finance, BI, payment-ops dashboards, and any data-science work.
Key engineering considerations:
- Event taxonomy stability (renaming an event field 18 months in is painful)
- PII handling — many regulators require PII not to leave specific regions even within a single operator’s data warehouse
- Lookback consistency — don’t change historical aggregations without a clear migration
Build vs buy: build the warehouse on a managed platform; buy the BI tool (Looker, Tableau, Hex, Mode).
Where the engineering debt accumulates
Across operators we’ve talked to, the failure modes cluster:
- Webhook handling. Layer 5 is consistently under-engineered at year 1. Operators run webhook receivers as simple REST endpoints, hit reliability issues at scale, and end up rebuilding the layer in year 2 or 3 with proper queuing and idempotency.
- Reconciliation. PSP settlement files don’t always match cashier-recorded events. Operators who don’t build daily reconciliation early discover gaps at financial audit time.
- Refund flow. Refunds get treated as withdrawals because the wallet system is too rigid to model “inverse deposit”. Causes confused player UX and accounting noise.
- Multi-tab cashier sessions. A player opens cashier in two tabs, deposits in one, success state doesn’t propagate to the other. Sounds rare, isn’t.
- Currency drift. FX rate captured at deposit-intent time vs deposit-success time vs settlement time. Three different rates in three different places. Causes pennies-per-transaction discrepancies that aggregate to thousands.
Choices that compound positively
The decisions that pay off over 3-5 years:
- Pick a cashier UX layer that’s separable from any single PSP. Even if you start with one PSP, the cashier shouldn’t be tied to it.
- Build the event-bus layer early. Even at low volume, having idempotent, versioned, replayable webhook routing makes every other integration easier.
- Track the seven KPIs from day 1. Approval rate, deposit conversion, decline-recovery, withdrawal time, fraud loss ratio, chargeback rate, total payment cost. Don’t try to retrofit instrumentation in year 2.
- Stay in one cloud provider until you can articulate why not. Multi-cloud sounds resilient; in practice it often increases failure modes faster than it removes them.
- Treat the cashier as product, not infrastructure. Conversion is a product KPI; tooling and engineering exist to serve it.
Where Fluid fits, honestly
Fluid is layers 1 and 2 of this diagram — cashier UI plus session service. We don’t replace orchestration, KYC vendors, fraud tools, the wallet, or the warehouse. We integrate above whatever you’ve built or bought for layer 3+, and we render the player experience on top.
If you’re an operator architecting this stack from scratch, the broader pattern of “buy the cashier UX, buy the gateways, buy the external services, build the event bus and the wallet, build the warehouse” is what most successful modern stacks look like. Whether the cashier you buy is Fluid or someone else is a separate decision — we’re happy to be in or out of that decision on the actual architectural merits.
Further reading: iGaming Cashier vs Payment Gateway, iGaming Payment Solutions Comparison, and How Fluid Connects to Paysafe, Praxis, Nuvei, PaymentIQ.