Embedding the game

The iframe is the only boundary between your casino and our game. You don't talk to our WebSocket, our database, or our game state machine — you load a launch URL in an iframe and let the player play.

Launch URL anatomy

https://<game-host>.<our-domain>/?launchCode=<short-lived-code>

For example, in the sandbox: https://bingo.lpmbackstagedevelop.com/?launchCode=.... Each game has its own host (bingo., bingo-beach., bingo-atlantis. and so on), so always use the launchurl exactly as we return it.

launchCode is a short-lived value tied to a specific session. It expires after 10 minutes. When the iframe starts, the game swaps it for a player token that lasts 1 hour. Request a fresh launch URL each time you embed the game, and again if the player comes back after the token has expired.

iframe attributes

<iframe
  src="https://bingo.lpmbackstagedevelop.com/?launchCode=..."
  allow="autoplay; fullscreen; clipboard-write"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups"
  style="width: 100%; height: 100%; border: 0;"
/>

The sandbox attribute restricts what an iframe can do; each allow-* token relaxes one restriction. We need:

allow-scripts — the game is a JavaScript app, it needs to run scripts.
allow-same-origin — lets the game read its own browser storage for player preferences (sound on/off, language, etc.).

Recommended:

allow-forms — needed for the in-game chat input.
allow-popups — needed for links to external help, terms, and responsible gambling resources.

Content Security Policy (CSP)

If your casino page sets a strict CSP, the directive that matters is frame-src: it controls which hosts your page may load in an iframe. Allow our game hosts and our replay host. The simplest rule is a wildcard on our domain:

Environment	`frame-src`
Sandbox	`https://*.lpmbackstagedevelop.com`
Production	`https://*.<our production domain>` (given at go-live)

Your page's other directives (connect-src, img-src, media-src) don't apply inside our iframe, so you don't need to add our API, socket, image or stream hosts to them. We don't load third-party ads, trackers, or analytics from inside the game.

Sizing and orientation

Aspect ratio — the game adapts from 9:16 (portrait phone) to 16:9 (landscape desktop). No fixed minimum; we render down to 320px wide.
Fullscreen — players may request fullscreen from inside the game. Pass allow="fullscreen" to honour this.
Mobile in-app browsers — most native casino apps embed our iframe inside a system webview. Tested containers: Android WebView, iOS WKWebView (the modern web view used by most native iOS apps), and SFSafariViewController (an Apple-provided in-app Safari container). Common cross-platform wrappers also work: Cordova / Capacitor, Flutter WebView, and React Native WebView. If you use a more restrictive container, talk to us during onboarding.

Mobile audio autoplay: in iOS in-app browsers, iOS Safari, and Android Chrome, audio autoplay is blocked until the player taps the screen. We handle this internally — the first tap unlocks audio for the rest of the session — but it's worth knowing if a player reports "the host is muted" before they've interacted.

Lifecycle signals

The iframe does not currently emit lifecycle events to the parent window. There is no postMessage contract today — the player plays inside the iframe and exits via UI inside the iframe; the casino has no programmatic signal of "round started", "round ended", or "player exited". This may change in future; if your UI relies on round-state hooks, talk to us during onboarding.

For round outcomes, rely on:

Direct integration: the credit call your wallet receives. This is the authoritative signal of "round closed, money moved".
Aggregator path: your aggregator's transaction record (typically exported from their operator portal).

For "player exited the game", you'll need a wrapper around the iframe in your own UI — for example a close button on the iframe's container, since the iframe itself can't notify you.

What happens if the player closes the tab mid-round

A real production case worth handling explicitly: a player buys cards, the round is in progress, and they close the browser tab (or lose connectivity) before the round settles.

What happens on our side:

The round continues to play out on the server. Other players in the room are not affected.
When the round settles, we still send the final credit call to the wallet (yours if direct, your aggregator's otherwise). This is the authoritative outcome.
A slot spin in progress also finishes on the server: it either pays its credit or is reversed. If our side was interrupted, a background job finishes it, usually within a couple of minutes.
The session row on our side expires passively after its TTL (24 hours). We do not currently send any session-end notification to your wallet.

What this means for you:

The wallet call is the source of truth. If your wallet log shows the credit landed, the player got paid — even if your frontend never showed it.
If the player launches the game again later, they'll see their updated balance.
Replays are available from /gamelauncher/replay if the player asks where their money went. See Replay.

Branding

We run several branded versions of the game, each with its own game code and host. You can't restyle a game yourself; talk to us during onboarding about which versions fit your brand.