RGS integration requirements for a casino game should be agreed as a versioned acceptance contract before the game client is built against a remote game server. The useful delivery artifact connects every launch, session, wager, outcome, settlement, interruption and retry to one authoritative state model and to evidence for the exact release.
For a studio, operator, RGS provider or procurement team, the central decision is where authority sits at each boundary. A polished game can still be unsafe to integrate when the parties have not agreed who creates the round, which command accepts value, how repeated requests behave, what the wallet records and how a player recovers after an uncertain response.
Freeze the integration boundary before game production
The RGS integration boundary should be frozen before client production because interface ambiguity becomes product behavior once game logic, animation and wallet handling depend on it. Name the operator platform, RGS, game client, wallet or PAM service, identity provider, configuration owner and evidence owner, then state what each party may request and what it alone may decide.
Use a formal interface description for transport details, but keep the gaming state model beside it. OpenAPI Specification 3.2.0 can describe paths, operations, parameters, request bodies, responses and security requirements. It does not define a correct casino round. The contract must add the meaning of accepted, committed, settled, voided, recoverable and terminal states.
Create one inventory of launch, authenticate, open session, start round, submit action, get status, complete, cancel or void where permitted, history and close-session operations. For each operation record the caller, trusted owner, prerequisites, request identifier, state transition, wallet effect, response, timeout meaning and evidence emitted. Unknown operations and unsupported state transitions should fail closed.
Separate player sessions, game sessions and round identity
Player sessions, game sessions and game rounds should use separate identifiers because they have different lifetimes and authorities. A login can expire while an accepted round remains unresolved, and a player can reopen a game without creating a second financial event.
GLI-19 Version 3.0 defines a gaming session and treats a game cycle as the activity from wager to wager. Its baseline says a new game in the same session should not begin before the current cycle is complete and the available funds and game history are updated. That standard is a procurement reference, not a universal approval route, but it gives buyers a concrete question: can every visible action be resolved to one game-cycle identity and final state?
Issue round identifiers on a trusted boundary before accepting a wager or other value-bearing action. Bind the round to the player account, game and math configuration, currency, market profile, client version and RGS version. Do not let a browser-generated identifier become evidence that the server accepted the round.
The wallet reconciliation guide explains the adjacent ledger decision. The integration contract should reference that authority rather than invent a second balance inside the game client.
Make every command safe to retry
Every value-bearing RGS command should be safe to retry because a timeout cannot reveal whether a trusted service accepted the first request. The client must not guess from the absence of a response, and a disabled button cannot protect the server from network replay or a second device.
Give each logical command a stable idempotency or request key within a defined scope. The RGS validates the actor, round, current state and payload, records the decision atomically with its authoritative effect, and returns the existing result for an identical accepted retry. A reused key with different content should be rejected and investigated rather than treated as a new wager.
Model the command lifecycle explicitly: received, rejected before acceptance, accepted and pending, outcome committed, wallet effect pending, settled, voided where permitted, and terminal failure. Not every product needs these exact labels, but every implementation needs meanings that cannot be confused. RFC 9457 provides a standard problem-details format for HTTP APIs; it can carry machine-readable error types and extensions, while the integration contract defines the gaming consequence of each error.
Design interruption behavior as part of the protocol
Interruption behavior should be designed into the RGS protocol because recovery cannot be added safely as a generic reconnect screen. The system must distinguish a command that never reached authority from one that was accepted but whose response did not return.
The UK Gambling Commission’s RTS 10 on interrupted gambling requires fair interruption policies within its stated scope. Its guidance distinguishes accepted gambles whose results should stand, single-stage events interrupted before an outcome, and stateful games that should be restored to the last known state where possible. It also calls for enough retained information to restore events or apply controlled void behavior where appropriate.
Turn those outcomes into protocol states and player messages. After a reconnect, query the trusted round status before enabling another action. Return the current authoritative state, the permitted next step and a stable reason code. The resilient casino game sessions guide covers the deeper recovery model; this integration contract makes that model an acceptance obligation between organizations.
Test disconnects before acceptance, after acceptance, after outcome commitment, during wallet processing and after settlement but before the response. In every case, the visible status, balance, history and next permitted command must describe one compatible result.
Version the interface and product configuration together
The RGS interface and the casino game configuration should be versioned together because a technically valid message can still carry the wrong math, currency, locale or market profile. Record compatibility as an explicit matrix, not as an assumption that all clients can use the newest endpoint.
Name the API or protocol version, schema version, game artifact, rules version, math or paytable configuration, RGS release, wallet contract, supported currencies, locales, channels and market profiles. Validate server-owned configuration at session creation and again at the command boundary when a stale client could submit an old value.
The iGaming API lifecycle guide describes consumer inventory, deprecation and retirement. A game integration adds a harder constraint: a version cannot be considered compatible when the call succeeds but changes the interpretation of a wager, outcome, balance or player rule.
Do not silently fall back across material configurations. Return an explicit incompatibility before commitment, preserve the reason in evidence and route the client to an approved update or unavailable state.
Test the contract in an environment that reflects production
RGS integration testing should use an environment that reflects the intended live platform and should prove failures as carefully as successful rounds. A scripted happy path cannot establish how identity expiry, repeated commands, delayed wallets, stale configuration or partial service failure behaves.
The Commission’s procedure for testing says software testing should use an environment that reflects the intended live environment. It also says additional integration testing can be required when a game uses a different RNG or platform from its original testing, with scope decided by the licensee and test house. Relevant RGS or RNG changes may require representative game retesting within that Great Britain framework.
Build a test matrix across supported clients, currencies, locales, configurations and integration versions. Include expired sessions, wrong actors, duplicated keys, conflicting retries, out-of-order messages, unavailable wallet services, delayed responses, malformed payloads, unsupported versions and recovery after each acceptance boundary. Reintroduce one intentional contract defect and require the gate to reject it before treating the suite as release evidence.
Turn the contract into a buyer acceptance pack
The buyer acceptance pack should bind the interface, tests and approvals to the exact casino game and RGS release. A generic API document or demo recording cannot prove which artifact, configuration and environment passed.
Include the actor and authority map, operation catalogue, state model, identifier and idempotency rules, security requirements, configuration matrix, machine-readable interface description, error catalogue, environment record, positive and negative test results, fault-injection evidence, artifact digests, change classification and named acceptance. Add the applicable test-house or authority records without presenting one jurisdiction’s process as universal certification.
Procurement can then compare suppliers on a reproducible delivery obligation: one round can be launched, accepted, recovered, settled and explained across the complete integration boundary. For a team commissioning casino game development, the RGS acceptance contract should be agreed before production and verified again against the exact launch candidate.
Frequently asked questions
What should an RGS integration contract define?
An RGS integration contract should define actors, trust boundaries, session and round identifiers, commands, states, wallet effects, errors, retries, configuration, versioning, observability and the evidence required for acceptance.
Which system should own the casino game round?
The trusted server architecture should name one authority for round identity, accepted actions, outcome commitment, settlement and final status. The browser client may present state, but it should not become the authority for wagering or balances.
How should an RGS prevent duplicate wagers?
The trusted command boundary should use stable request and round identifiers, validate the current state, make retries idempotent and return the existing result when an accepted command is repeated. Disabling a button in the client is not sufficient protection.
What happens when a casino game connection fails?
The integration should expose whether the action was rejected, not accepted, accepted and pending, committed, settled, recoverable or terminal. Recovery behavior must match the applicable rules and preserve enough state to explain the player balance and history.
When does an RGS integration need additional testing?
The applicable authority, operator and approved test house decide the required scope. In Great Britain, the Commission testing procedure calls for additional integration testing when a different platform or RNG can affect the original game testing and for representative retesting when relevant RGS or RNG changes may affect games.
What belongs in an RGS integration acceptance pack?
The pack should include the interface contract, state model, identifier rules, security boundary, configuration matrix, test environment, positive and negative cases, fault-injection evidence, exact artifact identities, approvals and applicable laboratory or authority records.
If you are commissioning a casino game, talk to Wizards about defining the RGS boundary, round protocol and release evidence as one testable integration contract.
