Getting started

New here? Read Introduction & concepts first for the architecture this page assumes. This page is the concrete 5-minute path from "I have credentials" to "my game runs a round."

Prerequisites

• A provider tenant ID and HMAC secret, issued by the platform's admin team. Keep the secret server-side only — it signs every wallet call and must never reach the browser.
• Your game running inside an iframe on an operator's page (the "shell"). You don't control when or how the operator embeds you — you only control what happens inside your iframe.

The end-to-end flow

1. A session token arrives on your launch URL. By the time your game's page loads, the platform has already appended a ?session=<token> query parameter to your registered launch URL. See Getting the session token for how your browser client reads it and hands it to your backend.
2. Your backend verifies the session. When your game starts, call ProviderClient#verifySession with the token. This validates it and returns the player reference, game and operator IDs, currency, and the resolved Central Config (RTP label + bet limits) for this game/operator pair — see Server-side integration.
3. Your game runs the round. Player places a bet → your server submits a BET transaction (and a WIN transaction if it pays out) via ProviderClient#submitTransaction. Amounts are always minor units (cents), never floats.
4. Your browser client reports lifecycle events. Inside the iframe, use GameBridge to tell the operator's shell when the game loaded, when a bet starts/ends, and when the player exits — and to receive balance pushes back down from the shell.

Continue to Server-side integration.