How the process of integrating the game into the casino works

Game integration is not "connected iframe." This is a chain of approvals, tests, legal and technical steps between the studio (provider), platform/aggregator and operator. Below is a practical scheme "from the contract to the first real rates."

1) Map of participants and areas of responsibility

Studio (provider/RGS): game and mathematics, RNG, API, logs, certificates, market builds, support.

Aggregator/platform: a single API for operators, routing, billing/reporting, promo, compliance hub.

Operator (casino): wallet/payments, KYC/RG, showcase, marketing, customer support.

Laboratory/regulator: verification of RNG/mathematics/logs, registers of approved builds.

2) Stage 0. Pre-integration (legal and data)

What we do:

1. Contract (s): rev-share/per-spin/hybrid, IP rights, list of markets.

2. Compliance package: certificates, RTP profiles, RG policy, ISO/IS.

3. Catalog and metadata: RTP, volatility, locales, age icons, tags, icons/videos.

4. Release plan: priority markets, dates, promotional package (freespins/tournament).

3) Stage 1. Technical preparation and API

Basics: REST/HTTPS (sometimes gRPC), UTC-time, ISO-currencies, JWT/HMAC, IP allowlist, mTLS.

Key models:

Сессия: `session_id, player_id, game_id, build_hash, country, currency, rg_flags`.
Wallet: debit/credit (on the fly) or transfer (session balance). For slots, debit/credit is more common.
Idempotence: 'spin _ id/round _ id' as keys for repetitions; replay response is the same result.
События: `spin_finished, bonus_trigger, jackpot_contribution/win, rg_event, error`.

Spin flow mini-chart:

Client → Platform: StartRound → Platform → RGS: Spin(stake) → RGS → Platform: Outcome(win) → Platform → Wallet: Debit/ Credit → Platform → Client: Result → Platform → EventBus: spin_finished.

4) Stage 2. Market versions and certification

Market builds: language, warnings, limits, allowed RTP versions.

Validation: the platform checks the'build _ hash ↔ certificate ↔ country'.

References: rules, RTP, age icons, RG links - in each locale.

Demo mode and restrictions: where allowed - individual builds/flags.

5) Stage 3. QA and test circuits

Sandbox (deterministic RNG):

functionality, wallet, RG scripts, errors/retrays, idempotency;
autotests of payout borders, bonus states, cascades.

Staging (copy of production info):

Locali/LQA, showcase, banners, age tags, promotional module.
Load tests: p95/p99 for 'spin', network fault tolerance.
Purse failures and RGS: Retreats, Idempotence, UI Folbacks.

UAT at the operator:

showcase checklists, categories/searches, RTP/volatility filters, quick bets, game history.

6) Stage 4. Integration of promos and jackpots

Frispins: issuance in packages, accounting 'spin _ type = free', billing rate (often reduced or 0).

Tournaments/missions: metrics (multiplier/sum/series), anti-bot defense, live-tables.

Jackpots: contributions and payments in separate transactions; reporting and odds of winning.

7) Stage 5. Launch (go-live)

Check-list of day X:

IP domain/registry and mTLS certificates.
'build _ hash' whitelisted by country, RTP profile selected.
Banners/tiles on display, demo/regional availability.
Monitoring enabled: latency/error, RTP drift, bonus frequencies, uptime.
Incident channels (Pager/Slack/Email), 24 × 7 contacts.
Pilot promotion (freespins/mini-tournament).

8) Stage 6. Reporting and Billing

Event layer: 'stake, win, currency, spin_type, game_id, build_hash, operator_id, ts_utc'.

Summary reports: turnover, GGR, NetWin, optional spins, jackpot contributions, bonus cost, royalties/commissions.

Payout models: rev-share (from NetWin/GGR), per-spin/turnover-fee, hybrid.

True-up: Quarterly exception reconciliations (free/test), FX, and late-posting.

9) Post-release monitoring and incidents

RTP-guardrails: online windows (e.g. 10-50 million spins) and alerts when leaving the confidence interval.

Bonus frequencies/streams: anomaly detection (regression/config errors).

SLA: p95 for spin ≤200 -300 ms by region, ≥99,9% availability.

Hotfixes: without changing mathematics - without recertification; math affected - plan overhauled.

Audit log and replay: investigating controversial spins in minutes.

10) Frequent problems and how to prevent them

1. Transaction doubles. - Idempotent keys for 'debit/credit' and status storage.

2. Invalid market build. - Auto-check 'build _ hash' by country and RTP in runtime.

3. Localization errors. - ICU plurals, numerical forms, age icons, glossary.

4. Swelling latency. - Metadata cache, close RGS regions, gRPC/Event Bus for threads.

5. Report mismatch. - Unified event schema, deduplication, UTC, and quarterly true-up.

6. RG inconsistencies. - Immediate '403 RG_BLOCKED', RG event log, display warnings.

7. Mixing versions. - Register of builds/hashes, prohibition of "self-assembly," canary calculations.

11) Roles and Communications

Integration Tehlid (both sides): Critical Path Owner and SLA.

Compliance officer: certificates, market builds, RG documentation.

QA lead: Sandbox/Staging/UAT scripts, blocker reports.

BD/Marketing: showcase, banners, promotional set-up, calendar.

SRE/DevOps: monitoring, alerts, emergency regulations.

12) Checklists

Studio → Operator/Aggregator

OpenAPI/specs and examples of payloads.
IDempotency 'spin/debit/credit/jackpot'.
RNG replicas for 'seed/nonce', WORM log storage.
Certificates, RTP ruler, market builds, references/locales.
Load tests and network chaos scenarios.

Operator → Studio

Wallet API with idempotency and retras.
Geo-mapping, age-labels, RG-policies.
The showcase/categories/search are connected to the metadata.
Promotional module: freespins/tournaments/missions.
SLA dashboards and reporting/true-up.

13) 30-60-90: Integration Roadmap

0-30 days (preparation)

Contracts and markets, catalog and metadata, certification package.

API coordination (kosher, spin, events), Sandbox rise from fix-seed RNG.

Registry 'build _ hash' and primary matrix market builds.

31-60 days (integration and tests)

Wallet and spin connection, Event Bus and observability.

Load/chaos tests, LQA of locales, window setting and promo.

UAT at the operator, final fixes.

61-90 days (start and tracking)

Go-live in pilot markets, freespin or tournament promo.

Billing/reporting, quarterly true-up.

Post-release RTP/frequency alerts, hotfix and recertification plan.

14) Short FAQ

Can RTP be changed after release? Only for pre-certified profiles and with the correct market build.

Do I need an iframe/web view? More often yes; nativ - by special partners. Important: client protection (anti-tamper, asset signatures).

Who pays for jackpots/promos? Under the contract: contributions are usually up to NetWin, prize tournaments - separate estimates.

How to quickly investigate a controversial spin? Replay by 'spin _ id/seed' + audit-log + reconciliation 'build _ hash'.

The integration process is managed pipeline work: contracts → API/wallet → market builds/certification → QA/UAT → promo/launch → billing/monitoring. When the sides have idempotence, transparent events, a strict build matrix and RG discipline, the game comes out quickly, safely and predictably - and post-release incidents are resolved in minutes, not days.