LivePlay Bingo Integration Docs

Embedding the game

iframe contract, hosts to allow, and mobile considerations

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://bingo.lpmbackstagedevelop.com/?launchCode=<short-lived-code>

launchCode is a one-time, short-lived value tied to a specific session. The launch code itself expires after 10 minutes by default. Refreshing the page after the code is consumed will not re-authenticate the player — request a fresh launch URL each time you embed the game.

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 sets a strict CSP, allow the following hosts so the iframe can load all of its assets and connect to our backend:

DirectiveHosts to allow (sandbox)
frame-srcbingo.lpmbackstagedevelop.com, replay.lpmbackstagedevelop.com
connect-srcapi.lpmbackstagedevelop.com, wss://socket.lpmbackstagedevelop.com
img-srcbingo.lpmbackstagedevelop.com, plus our CDN host (provided at onboarding)
media-srcThe host stream domain (provided at onboarding)

Production hosts are issued during go-live. 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 (Gametech's operator-portal export, etc.).

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.
  • The session row on our side expires passively after its TTL (24 hours by default). 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

The game ships with default LivePlay Bingo branding. Per-operator theming is not exposed today; talk to us during onboarding if you need it.

On this page