Casino game aggregation connects an operator to content from multiple suppliers through a common integration. A remote gaming server, or RGS, runs and delivers the supplier's games. Player accounts and balances belong to a separate account-and-wallet responsibility. These functions can share a vendor, but they are not interchangeable.
For product, technology and compliance teams, the useful question is what crosses each boundary. A game can appear in a catalogue without being enabled for a particular brand. It can launch successfully while wallet settlement still fails. This guide follows those boundaries and provides a checklist for reviewing the complete connection.
Casino game aggregation vs RGS vs PAM
| Role | What it means | Where to verify |
|---|---|---|
| Game aggregator | Connects an operator-facing interface to multiple content suppliers and may consolidate catalogue and reporting functions. | Operator and supplier API documentation, enabled products and distribution agreements. |
| Remote gaming server | Provides the game-serving environment, including game execution and session or round functions within its defined scope. | Architecture, game build records, responsibility schedule and testing scope. |
| Player Account Management (PAM) and wallet | Manage the player account and the relevant balance records; implementation can involve several modules or vendors. | Account architecture, ledger ownership and wallet integration contract. |
| Game client | The player-facing presentation and interaction layer, distinct from the authoritative backend records. | Launch flow, supported devices and rules for recovering an interrupted session. |
This is a functional map, not a rule that four separate companies must be involved. A vendor can supply several layers. The RGS explainer examines the game server in detail; the PAM guide covers accounts, wallets and controls.
Gaming Laboratories International makes this boundary explicit in its Platform/RGS testing description: the evaluation scope depends on how functionality is divided between supplier and operator platforms. Its possible assessment areas include transmission, recovery and logging. An RGS label alone therefore cannot tell a reviewer which company operates every component.
What does a game aggregator actually consolidate?
The clearest starting point is the connection between the operator and the suppliers. SOFTSWISS describes its Game Aggregator as a hub linking operators to studios' remote game servers through one integration, with distribution agreements supporting the supply relationship. That reduces the number of interfaces an operator must handle directly. It does not mean the connected games become one game engine.
Additional functions depend on the product. EveryMatrix's casino business models describe content management, reporting, monitoring and provider reconciliation, alongside separate platform and turnkey options. The page also identifies provider-specific features that can be unified, including free spins, jackpot feeds and game replays.
The procurement implication is to ask which functions are actually included. An available API method, a contracted feature and a feature supported by a particular studio are different things. Check the intended game and market combination instead of accepting the broadest description on the vendor's product page.
Commercial packaging can overlap with hosting. In a July 2025 Silver Bullet announcement, Relax Gaming described combining its own RGS technology with distribution to operators. This is a documented example of two roles offered together, not evidence that every aggregator owns or executes every game it distributes.
How a game launch crosses the integration
Hub88's core API flow provides a public example. The operator requests access to a selected game through Hub88; Hub88 communicates with the supplier to obtain the launch URL. During play, supplier-side events pass through the integration to support account updates. This describes that platform's documented flow, not a universal endpoint specification.
Separate three questions when reviewing a launch:
- Identity: which player, brand, game and environment does the request represent?
- Access: is that content enabled for this operator and permitted for the intended market?
- Accounting: which service will authorise and record the subsequent balance changes?
Keep the launch identifier and the financial transaction identifiers distinct in the review. Opening a game is not itself proof that a wager was accepted or a payout recorded. A screenshot of a working lobby answers a presentation question; it cannot answer the accounting question.
The iGaming platform guide explains the broader system around this exchange. Aggregation supplies a route to content within that system; it does not replace the whole operation.
Seamless wallet and transfer wallet are different models
In a seamless-wallet integration, the operator-side wallet responds to transaction messages. A transfer-wallet arrangement moves gameplay balance handling to a separate wallet environment. Review the actual product's definition: neither term, by itself, establishes who legally holds customer funds or which business owes the player money.
Hub88's gameplay documentation distinguishes these models. Its seamless flow calls the operator to check and update balances; its transfer-wallet flow handles game actions and balance updates on Hub88's side. The same documentation notes that demo play does not call the operator's API for balance handling.
Consequently, a demo test can confirm that the game opens while leaving the real-money wallet path untested. This is a limitation of the test, not necessarily a defect in the game. Review both the player-facing experience and the transaction evidence appropriate to the chosen wallet model.
Why retries and rollbacks matter
A network timeout is not a reliable statement about whether a balance changed. The receiving system may have processed a message while the response failed to arrive. A review must therefore cover repeated delivery and correction, not just the successful first attempt.
Hub88's Wallet API requires operators to avoid processing the same transaction identifier more than once. It distinguishes a financial transaction identifier from a request identifier used for tracing calls, and documents rollbacks that reference the original transaction. It also exposes supplier transaction references for investigation. These are concrete examples of why the integration needs more than a game URL.
Consider this invented acceptance-test scenario, not a record of live play: a wallet starts at £100, accepts a £2 debit and records £98. The acknowledgement is lost. Receiving the same debit again must not create a second £2 charge. If a valid correction later reverses that debit, the expected balance is £100, not £102. The example assumes no other transactions.
Use the agreed protocol to decide the exact response to a duplicate, an unknown reference or a late correction. Do not infer that a timeout makes it safe to create a new transaction or refund manually. The review should demonstrate one coherent record of the original action and its final status.
Catalogue access is not market authorisation
A supplier's headline game count is not the count an individual brand can necessarily offer. Hub88's My Products documentation separates contract status from enablement by operator, brand and environment. It also says requested RTP and exposure preferences remain subject to the configurations available from the supplier.
The practical consequence is to preserve the exact configuration in the release record. Requesting an RTP value does not create a new mathematical model on demand. The paytable mathematics explainer explains why the deployed rules and version matter more than a generic title name.
Great Britain supplies a useful jurisdiction-specific example. The Gambling Commission's gambling software guidance treats the final supplier to a Commission-licensed operator as requiring a gambling software licence, subject to the arrangements described in the guidance. It separately explains that a software licence does not itself authorise providing facilities for gambling. These are different activities, not one blanket approval attached to an API.
Under the Commission's testing strategy, relevant new products need approved-test-house testing before release. Where an operator relies on a B2B supplier, a games-register reference links the test reports. Read the applicable scope rather than translating this example into a universal international rule. The casino game testing guide explains the evidence chain.
Direct integration or aggregation: what should be compared?
Direct integration and aggregation move work to different places. BETTIMES' assessment is that the decision should be based on the content and responsibilities required, not on the smallest advertised API count.
For a direct route, establish who will maintain each supplier connection, negotiate access, coordinate releases and investigate discrepancies. For an aggregated route, establish what the intermediary maintains, which supplier-specific exceptions remain and how incidents are escalated. A combined arrangement needs a clear record of which route serves each title so that support and accounting do not confuse them.
Compare the contractual cost on a like-for-like basis. Separate setup, ongoing service, content charges and any agreed revenue-share base; do not assume a universal fee structure. The GGR, GGY and NGR guide explains why two identical percentages can produce different charges when the underlying revenue definition differs.
An integration review checklist
Use this as a starting evidence checklist, not a certification standard or a claim that BETTIMES has tested a supplier's production system:
- Responsibility map: identify the legal entities and services responsible for the game, account, wallet, release approval and incident response.
- Content record: retain the title identifier, supplier, build or configuration, enabled brand, environment and market evidence.
- Wallet model: document where balances are recorded and how gameplay records are reconciled with the account ledger.
- Failure cases: obtain test evidence for duplicate messages, timeouts, rejected wagers, corrections and interrupted sessions.
- Traceability: confirm that support can connect the player report to the relevant game round and financial transactions.
- Change control: identify who approves a new build, withdraws unavailable content and assesses the need for further testing.
- Commercial definitions: match invoices and revenue-share calculations to the agreed records, currency, period and deductions.
For casino game aggregation vs RGS, the conclusion is straightforward: aggregation connects the catalogue; the RGS serves the game; the account-and-wallet systems record the player's position. The next step is to put named owners and inspectable evidence against each function. One supplier may fulfil several roles, but a single contract should not leave their boundaries undefined.
Frequently asked questions
Is a casino game aggregator the same as an RGS?
No. Aggregation connects an operator to content suppliers through a shared integration. An RGS is the game-serving environment. A company can provide both services, so identify the component behind each title and its documented responsibilities. The aggregator's name alone does not establish where the game runs.
Does an aggregator replace a casino platform or PAM?
Not by definition. A standalone aggregation service provides a connection to content, while the wider platform handles other operational functions. Vendors may bundle aggregation with PAM, payments or additional services. Check the contracted modules and the account-and-wallet architecture rather than treating a broad product label as a complete specification.
Does a single API make every game available?
No. Catalogue inclusion, commercial agreement, brand enablement and permission for a particular market are separate checks. A game may also have different supported currencies or configurations. Verify the specific title and environment you intend to release; a provider's overall catalogue size is not evidence of access for one operator.
Can an aggregator change a game's RTP?
An aggregation interface may expose a choice among supplier-supported configurations. That does not mean it can invent an arbitrary RTP or rewrite the game's mathematics. Confirm the deployed version, available configuration, testing evidence and player-facing disclosure. A requested setting is not proof that the supplier has applied it.
Does a working demo prove an integration is ready?
No. Demo play may bypass the operator's real-money wallet path. It can show that the client loads without proving debit, credit, correction or recovery behaviour. Require evidence for the agreed wallet model and failure cases, then verify the intended content and market scope separately before treating the release as ready.