An aggregator’s decision about a commissioned slot is usually described as a quality decision: is this game good enough for the catalogue? That framing produces the wrong test list. The catalogue question is narrower and more commercial: in which markets can this title be switched on, and what breaks on the way there?
A title can be excellent and still fail the second question. It can be excellent and hardcode the game server address it was built against, so it works for the first operator and nobody else. It can be excellent and render a Brazilian real balance with the wrong number of decimals. It can be excellent and have no Italian strings, because the platform’s language list never included a code the build recognised.
Those failures are not art problems or math problems. They are integration problems, and they are cheap to find before exposure and expensive to find afterwards. This article sets out the tests worth running, and what a studio should hand over so they can be run without a call.
The platform’s launch URL is the contract between whoever opens the game and the game itself. Engine’s RGS documentation specifies it as a set of query parameters the front end reads on load: a session identifier, the RGS host, the language, the currency, the device class, a social-casino flag and a demo flag.
Two of those parameters carry most of the integration risk.
The RGS host is passed in the URL and the documentation is explicit that it must never be hardcoded, because it can change at any time. A build that reads it from the launch parameters can be pointed at a different environment; a build that baked it in cannot. When an aggregator asks whether a title is portable between operators, this single line is often the answer.
The social flag tells the game it is running for a social or sweepstakes operator, and it is expected to match a jurisdiction flag returned by the wallet authentication call. A title that ignores it will present a real-money frame to a player whose account is not a real-money account. That is not a cosmetic difference, and it is invisible in a desktop review of the game on the studio’s own staging environment.
The demo flag is the third. A demo launch is a play-money session, and the game’s own behaviour in it — what it shows, what it disables — is part of what an aggregator’s sales team will use to sell the title to operators.
The round lifecycle is where integrations actually fail
Engine’s basic flow is short: authenticate the session, place the bet and open a round, play the round’s animations, then settle the round. The interesting behaviour is in the states between those calls.
A round that pays nothing is closed by the bet call itself; the returned round is marked inactive and there is nothing to end. A round with a win stays active until the end-round call settles it. A game that assumes every round needs an explicit end, or that none do, will reconcile badly against an operator’s wallet even when every individual spin looks correct on screen.
Only one round can be active at a time. A second bet while a round is open is rejected. That single rule is what makes the disconnect test worth running: kill the session mid-feature, relaunch the game, and check that the unfinished round comes back from authentication with the last recorded step intact. The API exists for exactly that — a bet-event call records how far the player watched, and authentication returns that value so the front end can resume the sequence rather than restart it.
An aggregator that has onboarded a title whose resume path was never exercised has onboarded a support queue. The test costs one browser session.
Money is integer, and currency is only a display layer
Amounts on the RGS are integers with six decimal places of precision. One unit of the major currency is one million. That is unremarkable until a build treats the amount as a float and a player’s balance drifts by a fraction of a cent over a session.
The more useful fact for a catalogue decision is that currency affects only the display layer and not gameplay logic. The game’s mathematics do not change between currencies; the presentation does. That matters because presentation is where the failures are: the same title has to render a Brazilian real balance, a euro balance and a Japanese yen balance, and only one of those has two decimals.
There is a trap here that a studio testing with three- and four-letter codes will find quickly. The documented currency list includes codes longer than three letters, and passing one of those to a standard number-formatting call throws rather than formatting. A build that formats whatever code the wallet returns, without a fallback, will break on the first operator whose currency is not in the language runtime’s tables. The documented guidance is to handle unknown codes gracefully and show the code after the amount — which is a one-line decision that belongs in the build, not in a support ticket.
The bet ladder has to fit the market, not the demo
Bets must fall between a minimum and a maximum and be divisible by a step, all three returned at authentication. A recommended ladder of bet levels is offered as guidance rather than a requirement, and the platform’s own documentation asks new submissions to support small denominations — starting at one cent — because that is not yet standard across the market.
That single requirement pulls two others behind it. At very small base bets, a win multiplier below one produces a win smaller than the smallest displayable unit, so more decimal places are needed on win values: three when the game’s minimum win is at or above a tenth of the stake, four when it is below. The balance itself does not need more than two decimals; in-game wins do.
Bet modes add a second layer. Where a game defines multiple modes, the player is debited the base bet multiplied by that mode’s cost multiplier, and each mode carries its own maximum bet. A catalogue listing that publishes one maximum for a game with several modes is publishing a number that is true for one of them.
For an aggregator, the practical question is not whether the ladder is generous. It is whether the ladder, the cost multipliers and the win precision are consistent with each other in the market the title is being exposed in. A euro ladder with a cent minimum behaves differently from a market where the smallest sensible stake is closer to a whole unit.
Language is supplied by the operator, and it can be anything
The language parameter is an ISO 639-1 code, and the documentation is candid that it carries whatever the operator sent: it can be empty, and it can be a code outside the platform’s supported list. The instruction is to fall back to English for any value not supported.
That produces a specific test, and a specific answer to a question aggregators ask constantly. The documented supported list covers Arabic, Danish, German, English, Spanish, Finnish, French, Hindi, Indonesian, Japanese, Korean, Polish, Portuguese, Russian, Turkish, Vietnamese and Chinese. Italian is not on it.
The correct reading is not that an Italian version is impossible. It is that an Italian launch will arrive at the game as an unsupported code and the game’s own fallback decides what the player sees. If the commission includes an Italian market, the Italian strings and the Italian fallback path are part of the delivered build and part of the integration test — not an assumption inherited from the platform’s list.
The help screen is a market artefact
In the United Kingdom, the material a player can read before committing to a bet is a regulatory surface, not marketing copy. The Gambling Commission’s remote technical standards require an explanation of the rules to be easily available and accurate, an indication of the game’s current state as it progresses, information sufficient to judge the chances of winning — including house edge or return to player — and the potential prizes or the means by which they are determined.
For a studio, that means the help screen and the paytable are integration outputs that vary by market. A title exposed in several jurisdictions carries several disclosure expectations, and the version that satisfies the strictest market it is offered in is usually the one worth building rather than maintaining variants.
The front-end acceptance criteria for a platform submission cover how those surfaces are reached and how the interface answers the player’s questions; this is the layer beneath them, fixed per market.
What the dossier should contain
An aggregator can run all of the above as a review, and a studio can make the review short by delivering a dossier. Seven items:
The launch-parameter handling, stated. Which parameters the build reads, and what it does when one is missing or empty.
The round lifecycle evidence. A recording of the disconnect-and-resume path, not an assurance that it works.
The money and currency table. Every currency the build has actually rendered, with its decimal count, plus the behaviour on an unknown code.
The bet ladder per mode. Minimum, maximum, step and cost multiplier for each mode, and the win-precision decision that follows from the smallest stake.
The language matrix. Which codes are served with native copy, which fall back, and to what.
The disclosure surfaces per market. The help and paytable content, mapped to the jurisdictions the title is being offered in.
The open questions. What the build does not yet handle, written down. A dossier with no open questions is usually a dossier that has not been read closely.
None of this is a substitute for certification, and none of it promises approval. It is the difference between a title that enters a catalogue once and a title that enters it market by market, with the same conversation every time.
For a studio commissioning or porting a title for several operators, the cheapest moment to settle these questions is the brief. The Engine project brief is where the market set, the modes and the integration target get written down before the build exists — and the earlier handover evidence is covered in the math-to-client parity guide. Where the catalogue is assembled through one gateway rather than direct integrations, the aggregator model explains what that gateway does and does not absorb.
Frequently asked questions
What should an aggregator test before adding a commissioned game?
Four things beyond the game’s own quality: whether the build reads its launch parameters instead of hardcoding them, whether the round lifecycle survives a disconnect mid-feature, whether money and currency render correctly including codes the build has never seen, and whether the bet ladder and language support match the markets the title is going to be exposed in. Each is testable in a browser session or a short code review.
Why does the currency matter if it does not change the maths?
Because currency changes the display layer, which is where a title breaks visibly. Amounts are integers with six decimals, but the rendered balance and win values follow the currency’s own decimal conventions, and codes longer than three letters are not accepted by standard number formatting. A build that formats whatever the wallet returns without a fallback breaks on the first unfamiliar currency.
Does a slot need its own Italian or Portuguese translations if the platform supports those languages?
Portuguese is on the platform’s documented supported-language list and Italian is not. A language code outside that list is passed through to the game and the game is expected to fall back to English. If a commission covers an Italian market, the Italian copy and the fallback behaviour are part of the delivered build and have to be tested in it rather than assumed from the platform’s list.
What happens if a player disconnects in the middle of a bonus round?
Engine keeps the round open. A bet-event call records how far the player watched, and authentication returns the unfinished round with that last recorded step, so the front end can resume the sequence rather than restart it or abandon it. A build that never exercises this path will still look correct in a demo and will still produce disputes in production.
Is supporting one-cent bets optional?
The platform’s documentation recommends using bet levels as guidance and states that bets must fall within the session’s minimum, maximum and step. It separately asks new submissions to support small denominations starting at one cent, which then requires more decimal places on in-game win values: three decimals where the minimum win is at or above a tenth of the stake, four where it is below.
