Testing and going live

The onboarding flow

 1  Commercial and compliance   contract, KYB, licences per jurisdiction, revenue terms
 2  Registration                you get an operator id per environment (sandbox, production)
 3  Key exchange (sandbox)      you upload your Ed25519 public key; you download the RGS wallet keys (current and standby)
 4  Sandbox configuration       wallet ingress URL, currencies, lobby origins, test users
 5  Build                       launch and catalogue against the sandbox; the wallet against the RGS
 6  Conformance                 the wallet and operator-API suites pass in the sandbox and produce a signed report
 7  Production request          you request go-live with the report and the certificates checklist
 8  Production keys and IPs     a NEW key pair (never reuse the sandbox keys); our six egress IPs allow-listed on your side
 9  Production smoke test       qa-tagged sessions, real tiny bets, one rollback drill
10  Ring 0, then general availability

Sandbox and production share nothing secret. A sandbox key can never sign a production call, and sandbox IP addresses are never to be allow-listed in production firewalls.

What you can test today, on your own machine

You do not need our environments to build and verify most of an integration. With a checkout of the RGS (Core) and these SDKs:

What	How	Proves
Your signing code	the vectors in `vectors/signing.json`	your signatures are byte-identical to ours
Your operator-API client	`interop/run.sh`, adapted to your client	launch, catalogue and lookups work against the real service, including the refusals
Your wallet against the conformance kit	`wcs` as above	the wallet contract, row by row, with a signed report
Your wallet against the real RGS	start `play-core` with `walletUrl` pointing at your wallet, as `examples/reference-wallet/e2e.sh` does	the RGS's signed balance, debit and credit calls are verified and your books agree with ours
The whole path: launch, play, wallet	`examples/reference-wallet/launch-e2e.sh`	your launch call, the game API reading that session in another process, and your wallet being debited and credited by signed calls, on one database
Retry and fencing behaviour	make your wallet answer `5xx`, time out, or refuse a debit, and watch the RGS retry the identical bytes and roll back	idempotency, fencing and refused-debit handling

The wallet conformance kit

Before go-live your wallet must pass RuneCode's wallet conformance suite against your sandbox wallet. The kit calls your wallet exactly as the RGS does (signed bodies, x-operator, frozen bytes re-sent verbatim on retry) and writes a signed report with a result per row and the capability flags it derives for your wallet. The report is the evidence for the go-live items on wallet conformance, refusal handling and the standby key.

# from the RGS repository (Node 24 or newer; no runtime dependencies)
pnpm --filter @runecode/wallet-conformance wcs \
  --wallet-url https://sandbox-wallet.example.com --operator-slug acme \
  --signing-key ./rgs-sandbox.key --standby-key ./rgs-sandbox-standby.key \
  --dev-session-url https://sandbox-wallet.example.com/v1/dev/session --out ./wcs-report

Rows: authentication and x-operator, the standby key, validation, balance, debit (including single-shot, instant loss and replays), credit, rollback (including fencing and multi-debit), ordering and idempotency, concurrency, forward compatibility, byte-identical replays, and refused-debit handling.
Verdicts: fail (a MUST row failed) is worse than incomplete (a MUST row skipped), then pass-with-warnings (a SHOULD row failed), then pass.
Safety gate: the kit refuses to run (exit 3) unless your wallet offers the dev-only session helper POST /v1/dev/session ({currency, balance} returns {token}; off by default and never in production), or you pass your own test-account tokens. The helper's presence is the proof that the target is a sandbox.
Capability flags such as remembersRefusals, supportsSingleShot and supportsCloseAtPlay tell the RGS how it may drive your wallet. A flag whose rows did not run is "not tested", never assumed.

The reference wallet passes it: examples/reference-wallet/wcs.sh runs the real kit against the reference wallet (verdict pass, every row, every capability true). Use that wallet as your starting point and the kit as your acceptance test.

The wallet simulator (wallet-sim) is our reference for the other direction: it behaves like an Engine-contract wallet and is what the RGS is tested against.

Go-live checklist

A blocker must be done before production. Items marked if used apply only when you use the feature.

#	Item	Blocker
1	Contract, KYB and revenue terms signed	yes
2	Licences and jurisdictions confirmed; a jurisdiction profile assigned; counterparty compliance record complete	yes
3	Certificates in place for every (game, release, jurisdiction) you enable	yes
4	Wallet conformance passed against your staging wallet, within 30 days, same build as production	yes
5	Operator-API conformance passed	yes
6	Capability suites passed for each capability you enable (promotions, jackpots, webhooks, crypto)	per capability
7	Production key pair uploaded; both RGS wallet keys (current and standby) trusted; fingerprints confirmed out of band	yes
8	Refusal handling passed: a rollback of a refused debit answers `200` and refunds nothing; refused debit ids are idempotent	yes
9	All six production egress IPs allow-listed and reachable	yes
10	Wallet ingress URL specific to RuneCode, TLS valid, `/health` green	yes
11	Test helpers unreachable in production	yes
12	Lobby origins registered; launch tested in the real lobby on desktop and mobile	yes
13	Currencies, bet levels and limits reviewed and approved	yes
14	Webhook endpoint verifies signatures and de-duplicates by id	if used
15	24/7 contact for wallet incidents, escalation path, status subscription	yes
16	One day of transactions pulled and matched against your ledger; daily reconciliation agreed	yes
17	Production smoke test passed	yes
18	Player round history shown in your lobby where the jurisdiction requires it	where required
19	Multi-jurisdiction operators: `country` sent on every launch, or a complete brand-to-profile map	if more than one profile

Operating in production

Log X-Request-Id on every operator-API response, and quote it in any support request.
Never log launch URLs, tokens or private keys.
Watch /health on your wallet as we do: three failures pauses bets for your players.
Plan key rotation: keep two operator keys active during a switch, and trust both RGS wallet keys at all times.
Reconcile daily.