Integration is the job
An iGaming platform is mostly connections. A mid-sized operator typically integrates dozens of game studios (often through a small number of aggregators), one or two sportsbook feeds, a range of payment methods across several providers, several identity and screening vendors, a geolocation service in the markets that need one, a CRM stack, an affiliate platform, analytics and tag management, and the regulator's reporting endpoint in each market. Each integration has a contract, a certification, a technical specification, a monitoring requirement and a failure mode, and integrations take up a large share of the operator's technology effort. This lesson covers the three integration families that matter most: games, sportsbook and payments.
Game integrations
Direct versus aggregated. A direct integration connects the platform to one studio's remote game server; an aggregator integration connects to a hub that fronts many studios. Aggregators reduce integration work from dozens of projects to one, handle the studios' varying APIs and certifications, and take a share of the revenue for it; direct integrations give better commercial terms and priority access to a studio's releases and are used for the studios that matter most. Most operators run both: the top studios direct, the long tail through aggregators.
The seamless wallet API. The standard integration pattern: the game server calls the operator's wallet to authenticate the session, to debit each bet, to credit each win, and to roll back a transaction if a round fails. The specification covers idempotency (a retried call must not double-debit), ordering, timeouts, currency and rounding, bonus-money handling (which balance a bet draws from and which it credits), and the game-round identifier that links every transaction to a certified game outcome for audit. Getting this wrong is a common source of wallet discrepancies.
Game launch and lobby. The platform requests a game launch URL from the studio with the session token, market, currency, language and mode (real or demo), and the game runs in the customer's browser or app from the studio's servers. The lobby's catalogue of games, with the metadata (RTP version, volatility, jurisdiction certification, feature flags) that decides what appears where, is synchronised from the studios and aggregators, and per-market rules are applied at launch. In Britain that means no feature buy in practice, after the Commission challenged it under its technical standards in January 2020 and the six operators it contacted removed it, no auto-play and a minimum slot spin of 2.5 seconds, and, since 2025, online slot stake limits of £5 per game cycle, or £2 for customers aged 18 to 24. In Germany the 2021 State Treaty on Gambling caps virtual slot stakes at €1 per game, requires an average game length of at least five seconds and requires the average payout ratio to be displayed; the €1 cap is a default, and from July 2026 to the end of 2027 licensees may offer up to €3 or €5 to qualifying players, which the platform's limit logic has to handle player by player.
Certification and change control. In regulated markets a game must be tested or approved for each jurisdiction before it is offered, and the platform may only offer approved versions in each market. In Britain new games must be tested by a Commission-approved test house, with the test report sent to the Commission before release, and updates that affect game fairness must be retested; in Germany each virtual slot game needs the regulator's own approval, and so does any material change to it. Studios release new versions constantly; the platform must track which version is certified where, and in Britain the change-control records for game updates must be available for inspection and are audited annually by an approved test house. Jackpot networks, tournaments and free-spin awards need their own integration points because they cross the wallet boundary in unusual ways, and not every market allows them: Germany's treaty prohibits jackpots in virtual slot games.
Sportsbook integrations
The feed. Events, markets and prices arrive from data suppliers (and from the operator's own trading where it prices in-house) as a continuous stream, with frequent in-play updates during live events. The platform ingests, maps to its own market model, applies margins and limits, and publishes to the front end and the bet-acceptance engine. Feed latency and mapping errors are the two failure modes; a mismapped market settles wrongly and a slow feed accepts stale prices.
Bet acceptance. The engine checks the customer (limits, restrictions, market eligibility), the market (open, price current), and the liability (per-selection and per-event limits) before accepting, and either accepts, rejects or refers to a trader for large or unusual bets. Under a managed trading service these decisions run in the provider's system with the operator's parameters; under in-house trading they run in the operator's.
Settlement. Results feeds, official data where required, and manual settlement for exceptions drive the settlement engine, which grades every bet and every leg of every multiple, credits the wallet and handles resettlement on corrections. Settlement speed after the final whistle is a measured service level.
Official data. Several American states let a league require the use of official league data for settling in-play bets: in Virginia, for example, once a sports governing body asks, operators must use only official league data to settle bets placed after the event has started, within 60 days of the regulator's notice, unless the data is not offered on commercially reasonable terms. Illinois goes further and licenses the providers of official league data. That makes the data supplier's licence and the data rights a licensing question as well as an integration one.
Payment integrations
Orchestration. The payments layer connects to multiple providers per method (card acquirers, bank-transfer and open-banking providers, e-wallets, vouchers, local methods) and routes each transaction by market, method, amount, customer risk and provider performance, cascading to the next provider on decline. Routing rules can move the acceptance rate materially, and acceptance is revenue.
Deposits. The flow applies deposit limits and responsible-gambling rules before the transaction, strong customer authentication where required, fraud and velocity checks, and the market's rules on methods (in Britain, no credit cards for gambling since 14 April 2020; restrictions on crypto in some markets). The result is written to the wallet and the payment record reconciled to the provider's settlement file later.
Withdrawals. The flow applies closed-loop rules (return to the deposit method or a verified method in the same name), pending-period and review rules, anti-money-laundering checks (source of funds triggers), and the market's rules on reverse withdrawals (banned for all online gambling in Britain from 31 October 2021), then executes through the provider and reconciles. Withdrawal time is one of the customer-facing metrics most closely watched.
Reconciliation. Every payment transaction must reconcile between the platform's ledger, the provider's records and the bank; unreconciled items are investigated daily, and in a regulated market the reconciliation records are part of the evidence an operator's auditors, and the regulator, can ask to see.
Identity, screening and geolocation
Identity vendors verify documents and match against databases; screening vendors check sanctions and politically-exposed-person lists; self-exclusion registers are national systems with their own APIs (and their own uptime), and in Britain participation in the national multi-operator self-exclusion scheme is a licence requirement; geolocation providers confirm position in the American states, where Pennsylvania, for example, requires the system to detect the player's location at login and monitor it throughout the session. Each is integrated at the points the market's rules require (registration, first deposit, withdrawal, login, every session) and each is a dependency: an outage at a self-exclusion register or geolocation service can stop registrations or play in that market, because a required check cannot be completed.
Integration operations
Integrations are operated, not just built. Monitoring covers latency, error rates and volumes per integration, with alerts; reconciliation runs daily for wallet-to-game, wallet-to-payment and settlement; certification tracking keeps game versions and platform releases aligned with each market's approvals; and change management governs the release of new integrations and versions under the regulator's notification rules. The operator's integration team, the studios' and providers' support teams and the aggregators' account managers form a permanent working relationship, and the quality of a supplier is judged as much on its support and documentation as on its product.
What to take from this lesson
An operator's platform is dozens of integrations, each with a contract, certification, specification and failure mode. Games integrate through seamless wallet APIs to studios' remote game servers, directly for the top studios and through aggregators for the long tail, with certified versions tracked per market. Sportsbooks integrate feeds, bet acceptance, settlement and official data, with latency and mapping the risks. Payments orchestrate multiple providers per method, apply limits, closed-loop and anti-money-laundering rules, and reconcile daily. Identity, screening, self-exclusion and geolocation are national dependencies. Integrations are operated with monitoring, reconciliation, certification tracking and change control.