How to Choose an iGaming Platform Provider for Casino and Sportsbook

Type "best platform" into a search box and you get lists written by people who have never sat through a migration weekend. This guide is the other thing: a way to judge any iGaming platform provider yourself, on the questions that decide whether casino and sportsbook can honestly run on one core. By the end you can score a shortlist on five criteria, run a demo call that produces answers instead of slides, spot the clauses that create lock-in, and price each candidate over three years.

One disclosure first. We are an iGaming platform provider ourselves, which is why this page ranks nobody and names no rivals: a vendor scoring its competitors is advertising in the costume of research. The criteria are written to be turned on us too, and our own platform architecture is scored against them near the end.

How to shortlist an iGaming platform provider without a ranked list

A ranking is the wrong instrument, because the right answer depends on your situation: a core that fits one casino in one market is often wrong for a group planning four brands and a sportsbook.

Run the shortlist in three passes. Cut five or six candidates to three against a written requirement list, test the survivors on a sandbox instead of watching a presentation, then let the cost model and the exit clause separate the final two. No iGaming platform provider volunteers that order, and most operators invert it by opening with pricing.

Five criteria carry the decision when casino and sportsbook share one core. Each appears below with what differs between vendors, how to test it, and how a weak answer sounds.

1. Shared wallet and shared player record
2. Module independence
3. Multi-brand and multi-market behaviour
4. Exit cost and the shape of lock-in
5. Total cost across three years

Criterion 1. One balance and one identity, or two of each

Some cores keep one balance ledger that the casino and betting modules both write to. Others keep two, reconcile them with a transfer service, and show a single number in the front end. In a scripted demo they look identical, because a demo has no load. They separate on a busy Saturday, when a sync queue lags, a bet settles against a stale balance and support cannot say which figure is correct.

• Testing the wallet takes twenty minutes On the sandbox, place a bet and open a slot in one session, then ask for the ledger rows behind that player. One record set with one running balance is a single wallet; two sets with a transfer entry between them is a bridge. Ask the iGaming platform provider which service owns the balance at settlement, and what happens to an in-flight bet when it is unreachable. "It behaves like one wallet to the player" is how a bridge gets described by people who know it is one.
• The player record is the same question applied to identity. Where casino and betting hold separate profiles, verification happens twice, a limit on one side does not bind the other, a self-exclusion can be honoured in one product and ignored in the second, and reporting shows two customers where there is one. In a regulated market that is an audit finding.
• Prove the record with a self-exclusion Register a test player, verify once, set a limit and a self-exclusion on the casino side, then try to place a bet. Instant blocking across both products means the record is single; a batch job means it is not. Ask for the audit trail of all three actions on one screen, and look at where the single player record actually lives first. "The profiles synchronise every few minutes" hands you the gap along with the invoice.
• Almost every vendor calls itself modular, and the word carries three meanings. The weakest is marketing: the product has many features. The middle one means modules can be switched off. The strong one means a module can be replaced by a third party or bought without the rest, and only that version is worth a premium.
• Ask for the unbundled price list What does the core cost without the CRM? Can their content run against your account layer, and your payment provider behind their cashier? Has either gone live, and can the iGaming platform provider describe that integration rather than assert it? Require the same answer in the contract, because a module independent in the architecture and bundled in the price is not independent at all.

When everything is modular and no price exists for a single component, the architecture is a monolith with feature flags. Not disqualifying, but stop paying a premium for it.

Criterion 3. Multi-brand and multi-market: configuration or repetition

Most operators end up with more than one brand and more than one market, including those who swear they will not. On some cores a brand is a configuration object with its own domain, theme, game mix, bonus rules and jurisdiction settings, run from one back office. On others it is a fresh instance with its own database and release cycle, which turns portfolio growth into a headcount problem. Markets behave the same way: one deployment holding per-jurisdiction limits and game availability, or a separate build per country.

• Ask for engineering days and certificate dates How many working days for brand two, and how many for brand five? Is the fee charged per brand, per deployment or per group? Which jurisdictions are certified at platform level today, and can you see the certificates? Certification held centrally is inherited; certification held per deployment is bought again, so check which certifications carry across markets first.
• "We will spin up another instance" and "we can support any market" are the two evasions here. The first describes a copy you will patch for as long as you own it. The second is a sales reflex: every iGaming platform provider supports every market eventually, and eventually is the number you are buying.
• Lock-in is rarely written as a restriction. It is built from small dependencies that are individually reasonable and collectively immovable: a player database in a proprietary schema, a front end the vendor owns, bonus history that exports as a summary rather than as events, and a supplier-held licence.
• Ask the exit questions at the start, while you still have leverage. Who owns the player database, in a numbered clause rather than a sentence on a slide? What format does it export in, and does it include transaction history, bonus events and verification documents, or only account rows? Is there an exit-assistance obligation with a defined period and an agreed rate?
• Ask for a sample export before signing A vendor who sends an anonymised sample within a week has done this before; one who treats the request as odd has not. The model matters too, since renting a brand under someone else's licence means the licence and often the player relationship are not yours to move.
• Almost every iGaming platform provider says the data is yours Ownership without a format, a deadline and an assistance obligation is a sentiment, so make the clause carry the promise.
• Signature-day price is the least informative number in the deal. Start with the revenue base. A share of gross gaming revenue and a share of net gaming revenue are different businesses once bonus cost is real, so get the definition in writing: are bonuses deducted before the share is calculated, and are chargebacks, payment fees and jackpot contributions? Then stack setup, content fees on top of the platform share, payment costs, per-brand and per-market charges, minimum monthly guarantees, priced change requests and the annual escalation clause almost nobody reads.
• Price one scenario, not one price list Write one volume scenario covering deposits, bets, bonus spend, markets and brands, and ask every candidate to price it for years one, two and three. The spread widens by year three, and the cheapest signature is often the most expensive contract. Put three years of fees into one model rather than compare quotes built on different assumptions.

"It is just a percentage of GGR" is where cost comparisons go to die, and so is a low headline rate paired with a high monthly minimum, which is a fixed fee describing itself as a share.

Build, buy or rent: the model changes which criteria matter

Decide what you are buying before scoring anyone. Building in-house takes roughly 12 to 18 months and suits groups with an engineering organisation. A modular platform runs about 4 to 8 weeks to a live brand and keeps the platform and the data with you. A packaged route, where you buy the stack as a finished package, lands at 2 to 4 weeks under your own licence. Renting through a white label is fastest at 1 to 3 weeks, in exchange for the licence and most of the control.

That choice reorders the criteria. If you buy or take a package, all five apply and an iGaming platform provider should answer every one. If you rent, criteria four and five dominate, because architecture is moot when you do not own the deployment. Settle market and licence first, then compare the casino modules on the same core.

Criteria scorecard: weight, evidence and the cost of getting it wrong

The table compares criteria, not companies. Score each iGaming platform provider on a three-point scale and fill in the evidence column, because a score without evidence is an impression.

The demo call: questions that produce answers instead of slides

Send the list in advance and say you want the sandbox open during the call. A serious iGaming platform provider will have it open. Take architecture first, and write the replies down word for word.

• Architecture questions One balance ledger or two? Which service owns the balance at settlement? One player record across casino and betting, or one per vertical? How fast do limits and self-exclusion propagate between them?
• Modularity questions Can one module be bought without the rest, and at what price? Can your content run against our account layer, and our payment provider behind your cashier? Which of those has gone live?
• Scale and market questions How many working days for brand two? Which jurisdictions are certified today, with dates? If we add the betting side of the core a year after the casino launch, what changes for the player database and the reports?
• Commercial questions What does the uptime commitment promise, and what is the remedy when it is missed? What exactly is the revenue base? Price our scenario for three years. Who owns the player database, in which clause, and may we see a sample export?

Contract and exit terms worth arguing over

A few clauses are worth more than the whole feature comparison that preceded them. None are unusual requests, and any iGaming platform provider that has done this before expects all of them.

• Data ownership clause Numbered and explicit that the player database, transaction history and marketing consents are yours and survive termination.
• Export specification Format, scope and a deadline. An export arriving in ninety days in an unreadable schema meets the letter of a clause and none of its purpose.
• Exit assistance A defined period after notice during which migration is supported at a rate agreed now, not negotiated later under pressure.
• Revenue base definition What is deducted before the share is calculated, item by item: bonus cost, chargebacks, payment fees, jackpot contributions.
• Price escalation The annual uplift, its cap, and whether it applies to the share, the minimums or both.
• Unbundling right The right to drop a module and the price of the remainder, so modularity becomes a commercial fact.
• Uptime and remedy A percentage with a measurement method and a consequence, because a service level without one is a target.

Have counsel read the termination and data clauses even when commercial terms are agreed.

Red flags on an evaluation call

None of these proves a vendor is bad. Each is a reason to slow down, and an iGaming platform provider worth shortlisting answers without defensiveness.

• The sandbox is unavailable, delayed twice, or replaced with a recorded walkthrough.
• Every requirement gets a yes, including two that contradict each other.
• Reference customers are described but cannot be contacted, and no anonymised reference is offered.
• The proposal shows one price and no breakdown, or a breakdown that changes between versions.
• Certification is asserted by name, with no certificate, no date and no issuing laboratory.
• The draft contract arrives with the data clause missing and a promise to add it later.
• Pressure arrives before the evidence does, usually as a discount that expires this month.

How we answer these criteria, as one of the vendors you would be evaluating

Read this as claims to be tested rather than as evidence. We are the iGaming platform provider that wrote the framework, which is a conflict of interest worth naming. Every figure below is marked because it rests on contracts, certificates and a service level you can see before signing.

Our core keeps one balance ledger and one player record shared by casino and betting, so verification, limits and self-exclusion bind across both instead of synchronising between them. The stack is API-first, and individual modules can run against a core that is not ours. Content and payments reach 25,000+ titles from 100+ studios and 220+ payment methods through one integration, across 20+ jurisdictions we build for configured on a single deployment. Operations commit to a 99.99% uptime SLA and 24/7 support, with a live brand in roughly 4 weeks on the modular route. The player database is yours on every model except white label.

Here is the part most vendor pages leave out. We are a new company, so we cannot yet show named reference customers, published case studies or client performance figures, because we do not have them. Any supplier quoting an uplift percentage should be asked which customer produced it and whether they will confirm it. What we offer instead is sandbox access and these tests run against our environment, with the ledger rows, the export sample and the priced three-year scenario in your hands.

Frequently asked questions

Test this framework on us

You have the criteria, the demo-call list, the clauses and the scorecard. Use them on every iGaming platform provider you are talking to, then use them on us. Tell us your verticals, markets and expected volumes, and we will open a sandbox, price your three-year scenario and send the export sample with the exit clause.

Book a technical demoRequest sandbox access