RGS features and promotions

The remote gaming server (RGS) handles accounts, transactions, tickets, and operator integration. The frontend displays and requests supported actions.

Feature inventory

Capability	Frontend contract
Real, demo, and social play	Read session mode and currency. Apply isSocial and hideDemoBalance. Never simulate a real wallet locally.
Wallet balance	Replace from returned balance. Use updateBalance after external deposits or wrapper requests.
Engine bonus purchase	config.buyFeatures plus placeBet({ stake, featureToBuy }). See purchases.
Operator freeplay tickets	freePlaysAvailable plus useTicket and optional useTicketFeatureType. See freeplays.
Awarded feature spins	engineData or scenario spinInfo. These belong to the existing round.
Card, ladder, and other wager features	Original playerChoiceIndex or permitted continuation. See gamble.
Partial collection	collect({ amount }) can bank money without a wallet credit.
Persistent progression	Load counters, replace runtime values, and process events once. See progression.
Within-round jackpots	Slot singleGameRoundProgressionData. It is not a shared progressive jackpot feed.
Operator feature packages	Connect reply featuresAvailable. This is distinct from engine buyFeatures.
Live discounts	balance.discountInfo. Display eligibility while sending the ordinary undiscounted stake.
Operator promotions	Operator Interface free-round and promotion events. Use the negotiated adapter.
Provably fair verification	config.rng === 'pf', round pf data, and pfVerify. See verification.
Session refresh and history	Supplied refresh/history URLs and loadConfig recovery data.
Server time and broadcasts	Crash events through a shared request/broadcast socket.

Discounts

The SDK exports IDiscountInfo and IDiscountEntry. A discount contains text, currency, stake tiers, and optional campaign validity.

interface DiscountTier {
  stake: number;
  absoluteDiscountAmount: number;
  spinsRemaining?: number;
}
// balance.discountInfo also carries text, currency, discounts[], campaignId,
// validFrom, and validTo.

Match the current stake and currency. Check the validity interval and remaining eligibility. Show the full stake, discount, and effective debit when confirmed by the integration.

Send the original stake to the engine. Do not subtract the discount in placeBet, win conversion, or rules. The operator applies its discount during settlement. The server balance remains authoritative.

Replace discount information whenever a balance reply arrives. Do not assume a campaign survives refresh or its last available spin. See Operator API discounts.

Operator packages and shared jackpots

featuresAvailable describes operator packages with game, type, rtp, value, and an optional description. It is not an alias for config.buyFeatures.

The engine SDK has no generic purchase helper for those packages. It also has no shared-jackpot subscription or claim helper. Implement the operator's agreed protocol before exposing either function. Do not send an operator package type as featureToBuy without a documented mapping.

A game can display a fixed or within-round jackpot from its scenario. Do not present that value as a live shared jackpot pool. State reset conditions and odds in the rules.

Backend services and frontend extensions

The Game Studio API carries jackpot data types (jackpotContribution, jackpotPayout) and common-draw round fields. The jackpot feature is specified but not live: the spec marks those fields "Not currently implemented" and the engine ignores them. The published Game Studio API has no player-storage service. None of this is an operation of the engine SDK.

The audited engine request router does not expose generic getJackpotInfo or confirmJackpotWin operations to your frontend. A shared-jackpot deployment needs a supported backend bridge and its frontend contract. See the Game Studio API for server integration.

That contract must supply jackpot IDs, eligible stakes, currency units, current amounts, data age, and reconnection behavior. It must define prize notification, confirmation, credit timing, and replay handling. Display stale data as stale. Never count a jackpot notification as wallet credit before settlement confirms it.

Common-draw games need a draw identifier, participation state, authoritative deadlines, result messages, and missed-event recovery. The creator's ordinary Bingo and Crash modes do not automatically supply a shared-draw service. Do not advertise a multiplayer or jackpot function solely because the RGS supports its backend primitives.

Persist player state behind your own game server. Keep frontend preferences separate from persisted engine counters. Do not call private backend routes or embed server credentials in the game.

Provably fair data

Provably fair (PF) rounds expose commitment and replay data where the configured engine supports it. Preserve the live audit and revealed seed. Verification must compare both the random-number audit and the resulting scenarios.

Do not show successful verification before those comparisons succeed. A missing seed is not a passing verification. Send original opening data and player actions in the correct order to pfVerify.

PF data can appear as additional reply fields outside the SDK's declared result types. Validate those extensions. Follow the PF guide and each vertical's replay instructions.

Functionality outside the frontend

Game certification, jurisdiction approval, age verification, wallet settlement, exclusion checks, and ticket grants require platform or operator services. The frontend must honor their results and restrictions.

There is no frontend API that can make an uncertified game approved or grant a missing permission. A complete integration includes those services and the acceptance evidence.