Testing

There's no mock platform or SDK to test against here — the operator side of this integration is plain signed HTTP, so testing it is mostly testing your own signing/verification code and your wallet backend in isolation, plus one real end-to-end pass before you handle real money.

Test your signing and verification independently of the platform

Both signRequest and verifyPlatformSignature are pure functions of their inputs — no network call required to test them. A useful smoke test: sign a request with signRequest, then feed its own output straight into your verifyPlatformSignature and confirm it accepts it; then mutate one byte of the body, or the timestamp, or the nonce, and confirm it's rejected. This catches the most common integration bug — a canonical-string construction that's subtly different from the platform's (wrong field order, missing newline, path vs. full URI) — before it ever reaches a real request.

Test your wallet callback backend directly

Your POST /v1/wallet/transaction and GET /v1/wallet/balance implementation doesn't need the platform running to be tested — it's your own HTTP server. Write requests that match TransactionRequest directly against it and assert on the response:

• A BET for more than the player's balance returns DECLINED, not an error.
• A repeated transactionId (same BET sent twice) returns the exact same cached response and doesn't double-debit — this is the single most important property to verify before going live. See Idempotency.
• A ROLLBACK referencing a known originalTransactionId credits back the right amount.
• A malformed or unsigned request is rejected with 401 before your business logic ever runs.

Use DEMO mode to test the launch + shell integration

DEMO mode lets you exercise the full launch → embed → shell-bridge flow without your wallet callback backend being involved at all — the platform mints a session backed by a temporary fake balance instead of calling you. This is the fastest way to verify signing, catalog listing, iframe embedding, and your postMessage listener are all wired up correctly, independent of whether your wallet backend is ready yet. See REAL vs DEMO mode.

One real end-to-end pass before going live

Once both pieces work in isolation, run one full REAL-mode session against the platform's pre-production environment (if your integration contact provides one — see Environments & base URLs) before your first real player session: sign a launch call, embed the result, place a bet, confirm your wallet backend received and correctly settled it, and confirm the balance shown in the shell bridge's BET_END event matches what your ledger now shows. The Go-live checklist covers everything else to verify before that first real session.