Go-live checklist

A short checklist to run through before your first real-money player session. Every item links back to where it's explained in full.

Credentials & secrets

[ ] Your operator tenant ID and HMAC secret are stored server-side only — never in a browser bundle, mobile app, or client-visible config. See Signing & authentication.
[ ] The secret is read from a secrets manager or environment variable, not committed to source control.

[ ] The server that signs your outbound calls (and verifies inbound wallet callbacks) has its clock synced via NTP. A skewed clock is the most common cause of an otherwise-unexplained 401 — see Environments & base URLs: Clock sync.
[ ] You're pointed at the platform's baseUrl for the environment you mean to go live against, not a pre-production one — see Environments & base URLs.

[ ] Your wallet callback base URL is registered through your tenant's portal and already resolves to a running implementation before you save it — see Registering your wallet callback URL.
[ ] If your typical wallet response time is close to or over 5000ms, you've raised the callback timeout with the platform admin team rather than discovering TIMED_OUTs in production.

[ ] POST /v1/wallet/transaction and GET /v1/wallet/balance both verify the platform's signature (full URI, not just path) before trusting the request — see Signing & authentication.
[ ] Repeated calls with the same transactionId return the exact same cached response rather than re-applying the balance change — see Idempotency. This is the single most load-bearing property in the whole integration.
[ ] DECLINED is only ever returned for BET — WIN, ROLLBACK, and ADJUSTMENT either succeed with OK or fail the HTTP call outright.
[ ] GET /v1/wallet/balance is fast and reliable — it's called live by game studios through the platform, not just as a background check.
[ ] You've run at least one ROLLBACK through your implementation, not just BET/WIN — it's the path least exercised by a happy-path demo.

[ ] currency and (if used) language are validated against the target game's GameSummary before you call launch, so a mismatch fails fast on your side instead of surfacing as an opaque 400.
[ ] You've handled the 403 risk-control response — see POST /v1/operator/games/launch — with a player-facing message, not just a generic error.
[ ] Your 429 handling honors the Retry-After header rather than retrying immediately — see Errors & retry.

[ ] Your postMessage listener validates event.origin, event.source, and the envelope marker before trusting a message — see Shell bridge.
[ ] SESSION_REVOKED is handled distinctly from EXIT_GAME — a player kicked mid-game (by you, or by risk control) sees a clear message instead of a silent return to your lobby.

[ ] You've completed one full REAL-mode session end-to-end against the platform's pre-production environment (if available) — sign a launch, embed, bet, confirm your wallet settled it, confirm the balance in BET_END matches your ledger. See Testing.