What is an iGaming platform? (platform vs provider vs operator)
An iGaming platform is the software infrastructure that runs a real money online casino or sportsbook: it holds player accounts, moves money, launches games from third party studios, gives the operator an admin panel, and produces the logs and reports regulators ask for. It is not the games themselves, and it is not the licence. Those are separate things, and confusing them is the single most common mistake in vendor conversations.
Platform definition
Think of the platform as the system of record. Every session token, wallet transaction, bonus grant, deposit limit, self exclusion flag and bet record lives there or is reconciled there. The games are external services that call into it. The payment providers are external services it calls out to. Strip away the game lobby UI and what remains is a transactional financial application with strict audit requirements attached.
Key distinctions
- Platform: the core software (player account management, wallet, aggregation layer, back office, compliance engine). Delivered as a turnkey solution or white label package, or built in house.
- Provider: an ambiguous word in this industry. It can mean a game studio supplying content (Evolution for live dealer, Pragmatic Play or Light & Wonder for slots), or a platform provider supplying the infrastructure. Always ask which one someone means before signing anything.
- Operator: the licensed business that faces the player, owns the brand, holds the funds and answers to the regulator. In the US that means a state by state licence, and in most states market access through a land based casino partner.
One more distinction worth pinning down: white label means you run on someone else’s platform and often under their licence, with limited control over the stack. Turnkey means you hold your own licence and licence the software. The technical work is similar; the regulatory exposure is not.
Market players
A single US casino brand typically stitches together a platform vendor, an aggregator or a set of direct studio integrations, two to five payment providers, a geolocation vendor, an identity verification vendor, a CRM, and a data warehouse. Nobody does all of it alone. The platform’s real job is to be the integration hub that keeps those pieces consistent.
Core components of a modern iGaming platform
Modern iGaming software is usually described as six modules. They are not standalone tools you can buy separately and hope to glue together later, because they all read and write the same player and money state.
- Player account management (PAM): identity, authentication, sessions, profiles, limits.
- Wallet: the balance ledger, including bonus funds and locked amounts.
- Game aggregation layer: the API surface that lets external game servers place bets and settle wins.
- Payments orchestration: deposits, withdrawals, routing, reconciliation, fraud checks.
- Back office: operator facing tools for support, finance, marketing and configuration.
- Compliance engine: geolocation enforcement, responsible gaming controls, audit trails, regulatory reporting.
Bonusing and CRM sit across all six. A free spins award touches the wallet, the game layer, the back office and the compliance logs at once, which is why bolt on bonus engines cause so much pain.
Player account management (PAM) system
The PAM is the platform’s core. In several regulated markets the PAM is the component that gets certified and audited, precisely because it owns the answer to “who is this person, what are they allowed to do, and what is their balance right now?”
User registration and KYC
Registration in a US regulated market is not an email and password form. The flow usually collects legal name, date of birth, address and a government identifier, then runs an automated identity check against third party data sources. Behind it sit age verification (hard blocked under 21 in most US casino states), sanctions and PEP screening, duplicate account detection, and a state self exclusion list check. Failed automated checks drop into a manual review queue with document upload, so the platform needs secure document storage with retention rules and access logging.
Session management
Once authenticated, the PAM issues a session token that every downstream service trusts. Practical requirements: single active session per account in some jurisdictions, idle timeout, forced re-authentication on sensitive actions such as changing withdrawal details, and token revocation the moment a geolocation check fails mid session. Game launch is typically a short lived, single use token passed to the studio’s remote game server, which then calls back to the platform wallet for every bet.
Player protection tools
Responsible gaming controls belong in the PAM, not in the UI layer, because they must be enforced server side on every transaction. That means deposit, loss and session limits with the regulator’s cooling off rules on increases; time based reality checks; cool off periods; and self exclusion that survives a new registration attempt from the same identity. Build these as hard constraints in the wallet and session path from day one; retrofitting them is painful and regulators do test them.
Game aggregation and content management
Game aggregation means integrating many game studios through one API contract instead of building a bespoke integration for each. An aggregator sits between the platform and dozens of studios, normalising game launch, bet and settle calls, round history and free round awards. Integrate once, gain a catalogue.
API integration methods
The games themselves run on the studio’s remote game server (RGS), which holds the RNG and the game maths. Your platform never determines outcomes. The typical sequence: the client requests a launch URL, the platform mints a session token, the RGS validates that token, then sends authenticated bet and win calls to your wallet endpoints. Non negotiable engineering details are idempotency keys on every transaction, deterministic error codes, replay of unresolved rounds after a timeout, and a round settlement reconciliation job. Latency budgets matter more than people expect, since a slow wallet response shows up to the player as a frozen spin.
Wallet models
Two models dominate, and the choice affects both player experience and your reconciliation workload.
| Aspect | Seamless (single) wallet | Transfer wallet |
|---|---|---|
| Balance location | One platform balance used by all games | Funds moved into a per studio sub wallet before play |
| Player experience | No transfers, instant game switching | Manual or automated transfers, visible friction |
| Real time dependency | High: every bet hits your wallet API | Lower: outages affect transfers, not play |
| Engineering demands | High availability, idempotency, low latency | Reconciliation of multiple ledgers, stuck balance handling |
| Typical use | Standard for regulated casino platforms | Legacy setups and some regional integrations |
Game studio partnerships
In US states, content is not universally available: each game must be certified and approved per jurisdiction, so the same brand can have different lobbies in Michigan and New Jersey. The content management module therefore needs per state game availability flags, per market RTP configuration where studios ship multiple RTP versions, and category, tag and merchandising controls. Certification comes from independent test labs such as Gaming Laboratories International, which test RNG behaviour and game maths against the regulator’s standards.
Payment processing and wallet system
The wallet is a double entry ledger with gambling specific complications: bonus balances with separate withdrawal rules, locked funds during open rounds, and pending withdrawals that can be reversed.
Multi currency wallets
Even a US only operator needs the plumbing that multi currency support implies: minor unit handling with no floating point money, per market currency configuration, and a clean split between cash balance, bonus balance and wagering progress. Every state licence is effectively a separate reporting entity, so ledger entries need market attribution from the start.
Payment gateway integration
Deposits in the US usually run over several methods in parallel: debit and credit cards (with meaningful decline rates on gambling MCC codes), ACH and pay by bank, PayPal, branded prepaid products such as Play+, and cash at the partner casino cage. Withdrawals are a different pipeline: KYC completion, risk scoring, return to the original method where rules require it, and a manual approval queue for larger amounts. Practical steps for a payout flow:
- Validate KYC status and any bonus wagering locks.
- Run fraud and AML checks against the transaction history.
- Route to the method’s provider and record provider reference IDs.
- Handle asynchronous webhooks for success, failure and reversal.
- Reconcile provider settlement files daily against the internal ledger.
Fraud prevention
The main risks are chargeback and stolen card abuse, multi accounting for bonus farming, collusion in player versus player games, and money laundering through deposit and quick withdrawal patterns. Controls that pull their weight: device fingerprinting, velocity rules on deposits and withdrawals, shared attribute matching across accounts, bonus abuse scoring, and transaction monitoring that feeds a compliance case management queue. Licensed US operators carry anti money laundering programme and suspicious activity reporting obligations, so monitoring output has to be reviewable and retained, not just automated.
Back office and reporting tools
The iGaming back office is the operator facing admin application. It decides whether a support agent resolves a ticket in two minutes or escalates to engineering.
Player management
Search by any identifier, a full account timeline (logins, geolocation results, deposits, bets, bonuses, limit changes), KYC document review, manual adjustments with mandatory reason codes, and account status changes. Role based access control and immutable audit logs of every operator action are requirements, not nice extras.
Financial reporting
Finance teams need turnover, gross gaming revenue, bonus cost, net gaming revenue, actual hold versus theoretical, payment method performance and chargeback rates, all sliceable by market and date range. Regulator facing figures must be reproducible from raw transactions months later, which pushes you toward an append only event store rather than mutable balance rows.
Analytics dashboard
Game level performance (unique players, bet count, average bet, actual RTP against theoretical), cohort retention, bonus ROI, and segmentation feeding the CRM for campaigns. Most serious operators stream platform events to a warehouse and do the heavy analysis there; the built in dashboard covers day to day operational questions. If you are planning that data layer, the same principles from any event driven architecture work apply here.
Compliance and regulatory tools
Compliance is architecture, not a policy document. In US iGaming, an unlicensed bet accepted from outside the state is a licence problem, so the platform enforces the rules in the request path.
Geo-compliance
Every real money session requires location verification inside the licensed state, typically through a specialist geolocation vendor combining GPS, Wi-Fi, IP and device signals. The platform must check at login, re-check periodically during play, and terminate wagering when a check fails or goes stale. Layer on IP and payment level geo blocking for prohibited jurisdictions.
Audit systems
Regulators expect a reconstructable history: bet and round level records with timestamps, the game version served, RNG certification references from the studio, operator action logs, and configuration change history. Storage retention periods are set by each jurisdiction, so make retention configurable rather than hard coded.
Regulatory reporting
Each state defines its own submission formats and cadence for revenue, tax, self exclusion and incident reporting. Automating generation and validating file formats before submission saves the finance team from monthly spreadsheet work, and it reduces the chance of a filing error becoming a compliance finding.
Platform selection: build vs buy considerations
The honest answer for most new entrants is buy, or buy first and build selectively later. Certification alone can consume months per jurisdiction, and a licensed vendor arrives with that work done.
Technical requirements
Score candidate vendors on scalability under peak concurrency, aggregation catalogue and how easily you can add direct studio deals, wallet model and API quality, extensibility (do you get real APIs and webhooks, or a locked UI?), data access for your own warehouse, and existing certifications in the states you want. Ask for the integration documentation before the sales deck.
Cost analysis
Commercial models are usually a setup fee plus a revenue share on gaming revenue, sometimes with minimum monthly fees, with game content royalties either included or passed through. Building in house replaces that with engineering headcount, certification and audit spend, payment and geolocation contracts you negotiate yourself, and ongoing 24/7 operations. Compare over three to five years, not year one.
Decision framework
| Factor | Points to buy | Points to build |
|---|---|---|
| Time to market | Weeks to months on a certified stack | Long runway including certification |
| Differentiation | Brand, content mix and CRM are enough | Product mechanics are the core of the strategy |
| Scale | Early stage or single state | Multi state volume where revenue share dominates costs |
| Team | No in house payments or compliance engineering | Existing platform and regulated fintech experience |
| Control | Standard roadmap is acceptable | You need to own release cycles and data end to end |
A common middle path: licence a platform for PAM, wallet and compliance, then build your own front end, bonus logic and data layer against its APIs. That only works if the vendor exposes proper APIs, which brings the evaluation back to the same question. If you are scoping that kind of hybrid build, the integration surface is where most of the custom development effort actually lands.
FAQ
What is an iGaming platform?
The software infrastructure behind a real money gambling site: player accounts and KYC, the wallet, the game aggregation layer, payment orchestration, the operator back office, and compliance tooling. It does not include the games or the gambling licence.
What components make up an iGaming platform?
Player account management, wallet and ledger, game aggregation, payments, back office and reporting, and a compliance engine, with bonusing and CRM cutting across all of them.
What is the difference between a platform and a provider?
A platform is the infrastructure. A provider is either the game studio supplying content or the vendor supplying the platform, depending on who is talking. Clarify the term in every commercial conversation.
What does game aggregation mean?
Integrating one aggregator API to reach many game studios, instead of building a separate integration per studio. The aggregator normalises game launch, bet and settle calls, and round history while outcomes stay on each studio’s remote game server.
Note for product teams: gambling products carry a built in house edge and negative expected value for players over time. Ship responsible gambling tools such as deposit and loss limits, reality checks and self exclusion as first class features, and keep all marketing claims free of any promise of winnings.