What is an iGaming platform — and how to choose an iGaming platform provider
An iGaming platform is the core software system that an online gambling operator runs the business on: it manages player accounts and wallets, aggregates game content, processes payments, powers bonuses and CRM, and produces the reporting that regulators and finance teams require. An iGaming platform provider is the B2B company that builds, certifies, hosts and maintains that system so operators can launch and scale without developing the technology themselves. If the games are what players see, the platform is everything underneath — identity, money, risk, and data.
This guide explains what a complete platform actually contains, how delivery models differ, and how to evaluate an iGaming platform provider before signing a multi-year contract.
Why the platform decision matters more than any other vendor choice
Most vendor decisions in iGaming are reversible. Game studios can be added or dropped through an aggregator in days. Payment providers can be swapped when approval rates sag. Affiliate tools, CRM add-ons and analytics layers all churn without existential risk.
The platform is different. It holds the player database, the wallet ledger, the bonus state and the regulatory reporting pipeline. Replacing it means migrating every account, every balance and every open bonus — a project measured in months and audited by regulators, even with purpose-built migration tooling. Choosing well the first time is dramatically cheaper than choosing twice.
The commercial stakes compound the technical ones. Platform fees are typically structured as a revenue share plus fixed components, so the contract shapes operator unit economics for years. And because the platform gates which markets you can enter — through its certifications and regulatory integrations — it effectively sets your expansion roadmap.
What a complete iGaming platform includes
Vendors slice the stack differently, but a genuinely complete platform covers five functional areas. When a provider is missing one, you will be buying it elsewhere and integrating it yourself — which is sometimes a fine choice, but should be a conscious one.
Player account management (PAM)
The PAM is the system of record: registration and login, KYC status, the player wallet, balances, limits, self-exclusion state, and the segmentation data every other module consumes. Everything else on the platform reads from and writes to the PAM. It is the module regulators scrutinise hardest, because responsible gambling controls and player fund protection live here. See our dedicated guide on player account management for the architecture in depth.
Game aggregation
A single integration that exposes thousands of titles from dozens of studios, with per-market certification metadata, jackpot feeds and round-level transaction settlement. The practical questions are release cadence (how fast new titles reach your lobby), jurisdiction coverage (what subset is certified where you operate), and failure isolation when an individual studio has an outage.
Payments and cashier
Payment orchestration across cards, bank rails, local methods and e-wallets, with routing, retries and cascading built in. In regulated markets the cashier is a retention product in its own right: approval rates and withdrawal speed move loyalty more than most bonus spend. On a platform with modular payment adapters, taking a new provider live is a routing configuration measured in days, because the orchestration layer, not the operator, absorbs the integration work.
Bonusing and CRM
The bonus engine defines offer types, wagering logic, eligibility rules and abuse controls; the CRM layer schedules campaigns across email, SMS and on-site messaging. Regulated markets constrain both — bonus caps in Germany, ban on some incentive types in the Netherlands, wagering transparency in the UK — so the engine must apply rules per jurisdiction, not globally.
Reporting and back office
Operational dashboards, finance reconciliation, safer gambling monitoring, and the regulatory reporting each market demands — from UKGC regulatory returns to per-jurisdiction data vault requirements. The back office is where your team lives eight hours a day; demo it with the people who will actually use it.
Platform delivery models at a glance
| Model | What the provider supplies | Who holds the licence | Time to launch | Best for |
|---|---|---|---|---|
| Turnkey | Full platform, hosting, integrations, launch support | Operator | 6–12 weeks | Licensed operators wanting speed with control |
| White label | Platform plus use of the provider's licence | Provider (sub-licensed) | 4–8 weeks | Curacao-tier only; not accepted in Tier-1 markets |
| Modular / API | Individual modules (PAM, aggregation, bonusing) | Operator | Varies by module | Operators with in-house tech replacing parts of a stack |
| In-house build | Nothing — operator develops everything | Operator | 18–36 months | Large groups with strategic reasons to own IP |
The turnkey model dominates regulated-market launches because Tier-1 regulators require the operator to hold its own licence, which rules out classic white label. The full comparison is covered in white label vs turnkey.
A concrete reference point for what "modern platform" means in practice: the Vuch platform combines a casino module (30,000+ aggregated games) and a prediction-markets module on a single unified wallet — one balance, one atomic ledger across both products — with a real-time risk engine built into the infrastructure rather than bolted on, USDT payment rails live today and fiat providers on the integration roadmap. Branded deployments are scoped at four to eight weeks depending on integrations and jurisdiction, and the casino module can be enabled or disabled per partner configuration.
How to evaluate an iGaming platform provider
Feature lists converge; every serious provider claims aggregation, bonusing and payments. Differentiation shows up in four places that demos rarely cover.
Regulatory footprint, evidenced
Do not accept "we support regulated markets" — ask for the certification inventory per jurisdiction, the B2B licence numbers, and links to the public registers where they can be verified. A provider certified in your current market but not your next one turns expansion into their roadmap decision, not yours. Check specifically for integrations with national self-exclusion registers (GAMSTOP, OASIS, Spelpaus, CRUKS) where relevant.
Technical architecture and integration surface
A CTO-grade review should cover: microservices vs monolith, API style (REST/GraphQL) and documentation quality, sandbox availability before contract, deployment model (shared cloud, dedicated, on-premise where regulators require it), and realistic integration timelines with named references. Public API documentation is a strong positive signal; refusal to show it before an NDA is a negative one.
Commercial structure and exit terms
Model the total cost at three revenue scenarios, not the entry price. Watch for minimum monthly fees that dominate economics at low volume, per-module charges that reprice a "cheap" platform, and — critically — data export and termination assistance clauses. A provider confident in its product will contractually commit to migration support if you ever leave.
Operational track record
Uptime history with a defined SLA, incident communication practice, support model in your operating hours, and reference calls with operators of your size in your markets. Whatever availability number a provider quotes, ask how it is measured, over what window, and what the credits are when it is missed — a marketing percentage without a measurement definition is not an SLA.
The 10-question provider evaluation checklist
Use this table in your RFP. A strong provider answers every row in writing without hedging.
| # | Question | What a good answer looks like |
|---|---|---|
| 1 | Which B2B licences and certifications do you hold, per market? | Licence numbers plus links to public regulator registers |
| 2 | Which of our target markets are you certified in today? | Named list with dates; a roadmap for gaps with committed timelines |
| 3 | What is the realistic time from contract to first bet? | A week-by-week plan with operator-side dependencies made explicit |
| 4 | What are all fee components at 3 revenue scenarios? | A transparent model: setup, revenue share, minimums, per-module fees |
| 5 | Can we see API documentation and a sandbox before signing? | Yes, with public or trial-access docs |
| 6 | How do modules run standalone if we keep parts of our stack? | Named APIs and at least one reference client running that pattern |
| 7 | What is your measured uptime and what SLA do you commit to? | ≥99.9% with credits, plus an incident post-mortem sample |
| 8 | How do you support regulatory reporting in each market? | Per-jurisdiction reporting formats supported out of the box |
| 9 | Which clients of our size and market can we call? | At least two relevant references, not just logos |
| 10 | What happens contractually and technically if we leave? | Data export formats, migration assistance, defined exit timeline |
Common evaluation mistakes
Buying the catalogue, not the core. Ten thousand games through an aggregator is table stakes; a weak PAM or bonus engine will cost you more than any content gap. Weight your scoring toward the platform core, not the content number.
Ignoring the back office. Decision-makers evaluate the player-facing demo; their teams then spend years in the admin panel. Put your operations lead in the back office for a day before shortlisting.
Treating compliance as the provider's problem. The platform supplies tools; the licence holder carries the accountability. Evaluate how the platform makes your compliance work auditable — logs, four-eyes controls, report trails — not just whether a feature box is ticked.
Skipping the exit clause. Every operator believes they will never migrate. In practice, a meaningful share of operators eventually replatform — and the single biggest predictor of a painful migration is a contract with no data-export commitment.
Who should own the evaluation
Platform selection fails most often as an organisational problem: one function runs the process and optimises for its own criteria. A durable evaluation assigns each dimension an owner. The CTO owns architecture, API quality, sandbox testing and the integration plan. The CFO owns the fee model at three revenue scenarios, the minimums, and the termination economics. The Head of Compliance owns the certification inventory, the RG tooling review and the audit-trail walkthrough. The COO or Head of Operations owns the back-office trial and the support SLA. Run the scoring in parallel, then reconcile in one session — providers that score high with three functions and terribly with one are telling you exactly where the relationship will hurt.
Where to go from here
If you are earlier in the journey, start with the budget: our guide to how much it costs to start an online casino breaks down licence, platform, certification and marketing costs line by line. If you are comparing delivery models, read white label vs turnkey before any sales call — it will change the questions you ask.
Ready to score vendors side by side? Request the full 40-point Vuch platform evaluation checklist — the extended version of the table above, in spreadsheet form, with weighting guidance — along with a demo tailored to your target markets.