Acceptance starts with an auditable ledger
A game may render and launch yet fail release if financial events cannot reach one defensible state after retries, timeouts, session loss, and routing changes. RGS acceptance testing is not visual sign-off: it is the operator decision that the RGS, wallet, limits, ledger, and support processes behave predictably beyond the happy path.
Its output is a versioned evidence pack for QA, platform, finance, compliance, and provider teams to establish what happened to a player balance, why, and whether it is reproducible. This runbook starts after provider and route selection and ends with production acceptance evidence.
Wallet callbacks form one financial state
An RGS spans systems without a shared database or transaction boundary. A provider may create a round and send a debit that the wallet persists before a timeout hides the response. Without a safe retry contract, both sides can act reasonably while the player is debited twice.
Treat the wallet contract as a state machine, not an endpoint list: session validation, balance retrieval, debit, credit, reversal or rollback, and closure. Each financial mutation needs an immutable business identity, terminal state, and operator ledger record. Identity normally combines provider transaction ID, operation type, player account, currency, and RGS instance; timestamps are insufficient because a retry can have a different timestamp for the same debit.
The direct-versus-aggregator decision belongs earlier. Teams still deciding should assess operator trade-offs between game aggregators and direct integrations. Once selected, acceptance covers the exact enabled contract, configuration, and production path.
The wallet is authoritative for available balance and ledger; the provider is authoritative for game execution and round outcome under the protocol. Neither should invent the other's state after a timeout. A failed response means only that the caller received no usable response, not that a debit failed.
Certification and UAT prove different things
Certification and operator UAT are related, non-interchangeable gates. A lab may assess game, RGS, or platform controls for a jurisdiction; UAT proves that the certified or approved component works with this operator's wallet, identities, limits, cashier rules, observability, and release process.
Before scope freezes, compliance should confirm current requirements for every intended GEO with the regulator, approved test laboratory, and legal advisers. Requirements for approved game versions, reporting, player protection, technical standards, and production changes vary by jurisdiction; this is release control, not a generic disclaimer.
| Evidence question | Operator UAT | Independent certification or lab work |
|---|---|---|
| Does this wallet route handle agreed callbacks? | Tests the operator contract and ledger. | May assess the component or required controls within formal scope. |
| Does the deployed game version meet local approval conditions? | Confirms intended version and configuration. | Determines compliance where testing or approval is required. |
| Can a production incident be reconstructed? | Requires traces, ledger records, ownership, and rollback. | Does not replace operator incident evidence. |
| Who accepts release? | Named operator release owner under internal governance. | Lab and regulatory processes retain their authority and timelines. |
A lab pass does not prove callback deduplication after a timeout, and a UAT pass does not replace required certification, approval, or change notification. Keep packs separate, cross-reference versions, and do not let commercial deadlines blur the distinction.
Versioned cases turn tests into evidence
A credible catalogue records version, preconditions, exact request identity, expected wallet mutation, evidence location, severity, and owner—not merely scenario and result. This prevents a staging pass without proof of the payload, configuration, or build. Keep IDs stable across releases; change version and rationale when behaviour, fields, or criteria change.
| Case and version | Preconditions and callback | Idempotency rule and evidence | Severity and owner |
|---|---|---|---|
| UAT-WAL-014 v1.3 | Funded account; send debit for one round, then repeat after a simulated timeout. |
Same identity returns original accepted outcome; one ledger debit. Save request/response hashes, trace ID, ledger row, round reference. | Critical. Wallet QA owner. |
| UAT-WAL-021 v1.1 | Send credit tied to an accepted debit, then replay it. |
First credit settles round; replay creates no second credit. Preserve callback log and reconciliation extract. | Critical. RGS integration owner. |
| UAT-SES-008 v1.2 | Interrupt browser connectivity after accepted debit but before client result. | Player resumes or receives contract-defined outcome without new debit. Capture session ID, round state, support message, final balance. | High. Product QA owner. |
| UAT-CFG-006 v1.0 | Use configured currency, minimum/maximum stake, and account-limit boundaries. | Wallet and RGS use the same minor-unit rule and reject invalid values without balance movement. Store configuration fingerprint and rejection payload. | High. Configuration owner. |
| UAT-DR-003 v1.0 | Route controlled non-production callbacks through failover. | Deduplication store and ledger authority survive; no replay becomes a new financial event. Save routing logs and reconciliation. | Critical. Platform reliability owner. |
Severity describes release impact, not test annoyance. Duplicate debits, balance-changing currency errors, and unexplained open rounds normally block production; a cosmetic lobby label may be releaseable if its owner records a correction date.
Duplicate callbacks are accounting decisions
Retries follow network loss, provider policy, gateway timeout, worker restart, or delayed response. The wallet must classify a request as a new instruction, exact replay, or conflict; HTTP success without that decision hides the defect.
For an exact replay, return the stored original result without another balance mutation. If an identity is reused with changed amount, currency, player, or operation type, return a traceable contract-defined conflict. Silent acceptance turns malformed provider state into operator liability.
Test both uncertainties: persist a debit then fail its response, so replay returns the original result; then stop before persistence, so replay creates one debit rather than being rejected as already settled. Deduplication must commit with the ledger mutation, not in a later asynchronous job.
Do not accept a client display, provider dashboard, or aggregate balance as proof. Preserve the raw callback, normalized trace ID, response, ledger entry, and reconciliation result. If these cannot be joined during an incident window, support and finance must reconstruct money movement from partial logs.
Interrupted sessions expose state ownership
A lost browser session tests whether the RGS and operator know whether state belongs to the round or player account. Do not improvise a refund because a player did not see an outcome, or create a fresh debit on reconnect.
Test interruption after session validation, accepted debit, RGS outcome generation, and unavailable credit or rollback response. Define expected state first. An accepted debit with an unresolved round may remain pending until protocol settlement or reversal; the result depends on the provider contract. Acceptance requires a deterministic, traceable outcome shown consistently to player, support, and ledger—not identical outcomes for every interruption.
Also test token expiry, player blocking, self-exclusion, account closure, and wallet locks. A cached game session must not bypass a control activated after launch. Compliance and responsible-gambling teams should approve handling for each state change in every regulated GEO.
Reconciliation proves money, not HTTP
HTTP records a technical response; reconciliation proves money state. Use immutable identities rather than broad opening-versus-closing balance comparisons, which can hide offsetting errors. For a player, currency, release candidate, and test window:
expected closing balance = opening balance + accepted credits - accepted debits + accepted reversals
For a test wallet opening at GBP 100.00, an accepted GBP 2.00 debit leaves GBP 98.00. Its forced-timeout retry creates no ledger movement. An accepted GBP 5.40 credit produces GBP 103.40. A GBP 1.00 debit later reversed leaves expected closing balance GBP 103.40. The duplicate appears in transport logs, never as a second financial debit.
Reconcile operator wallet transaction ID, provider transaction ID, game round ID, correlation ID, amount and currency, plus status. Matching amount with a different settlement state is not clean reconciliation. Define pending-event duration, queue owner, and closing evidence; unresolved financial state must not disappear because a daily batch completed.
Currency and limits fail at boundaries
The contract must define minor units, rounding, zero-decimal currencies, and unsupported-currency behaviour. A displayed 1.50 must mean the same ledger amount on both sides. Test smallest and largest permitted stakes, one minor unit below and above each boundary, and unsupported currency.
Game minimum/maximum, account balance, deposit-derived, and jurisdiction-specific limits can reject wagers. The RGS needs an unambiguous response and the client a message that does not imply missing money. Include the source of truth in the release pack: game version, RGS configuration, wallet rules, currency mapping, and jurisdiction profile.
Run a configuration-drift negative test by changing a non-production stake or currency setting on one side. Monitoring must identify the mismatch before financial traffic proceeds, proving broken configuration fails loudly enough for the release owner to stop it.
Cutover needs a reversible evidence pack
Cutover can invalidate sound UAT because staging differs in DNS routes, credentials, fraud controls, monitoring retention, flags, currencies, and traffic. The release owner needs proof that the enabled contract was tested and a rollback that protects accounting in flight.
Maintain one controlled-access release pack with named approvals containing:
- Approved RGS and game build IDs, catalogue version, results, known deviations, and production scope by GEO and currency.
- Redacted callback payloads, trace IDs, ledger and reconciliation extracts, screenshots where visual state matters, and retained-log links.
- A configuration fingerprint for routes, wallet credentials, currencies, stake limits, availability, flags, and monitoring alerts.
- A jurisdiction-approved production smoke test covering test accounts, funds, player exclusion, and evidence retention.
- A rollback owner and procedure to stop launches or routing without deleting ledger state, then reconcile open rounds before relaunch.
Rollback reverses traffic exposure, not financial history. If a route is disabled with open rounds, preserve settlement or contract-defined recovery access. Failover must share ledger authority and deduplication state or legitimate retries can become new money events. Test this before an incident.
Release controls are replacing screenshot UAT
Screenshot-led UAT fails when providers patch clients, callback fields, routes, or jurisdiction configurations on different schedules. A screenshot proves rendering in one session, not duplicate-credit settlement or partial-round recovery. Replace it with replayable financial cases tied to a release candidate and retained evidence.
Use contract fixtures, deterministic fault injection, and gates that compare approved configuration with the candidate. Automation need not cover every edge case immediately: start with balance-changing callbacks, retries, interruptions, currency mapping, limits, and failover; add cases after incidents, provider changes, and reconciliation exceptions. UAT becomes a learning record, not a ceremony.
The enablement decision must survive audit
Production enablement means a named owner can trace every tested financial event from callback to ledger, explain retries and interruptions, show deployed configuration matches accepted scope, and halt or reverse traffic without corrupting open accounting. Certification, local legal review, and operator UAT remain separate gates; linking their evidence makes release defensible.