What is a casino games aggregator?

What an aggregator replaces

Without an aggregator, every studio you want on your floor is its own project. You negotiate a contract, pass that studio's certification, integrate its game launch call, implement its wallet callbacks in its own format, reconcile its reporting separately and keep up with its releases. Each one is a few weeks of engineering and a separate commercial relationship.

The work does not scale linearly either, because the second integration does not teach you much about the third. Studios differ in how they sign callbacks, how they identify transactions, how they handle rollbacks, what they call a round, and how they report GGR. Every difference is a branch in your wallet code and a column in your reconciliation.

An aggregator collapses that into one integration. One API for launching sessions, one callback format for the wallet, one place where transactions are identified the same way, one report. Adding a studio stops being an engineering project and becomes a catalogue change.

What one integration actually saves

The honest version of the saving is not "we are faster". It is that the cost of adding the tenth studio is roughly the cost of adding the second, and without an aggregator it is not.

Three things carry most of that saving:

• One wallet contract. Your server implements authenticate, balance, bet, win, rollback and reward once. Idempotency, signature verification and reconciliation are written once and used by every game.
• One balance. You fund one prepaid balance rather than settling separately with each studio on different terms and different cycles.
• One certification path. You pass the integration once rather than repeating a certification per studio.

What it does not save is the hard part of a wallet integration. Whether you integrate one studio or a hundred, your server still has to make repeated callbacks safe, reverse rollbacks exactly once, and keep player balances correct under retries. An aggregator reduces how many times you write that code. It does not write it for you.

What you give up

A page selling aggregation will not usually tell you this part, and it is what operators ask about in forums.

• You pay twice. The studio takes its share and the aggregator takes a share of GGR on top. A direct integration with a single high-volume studio can be cheaper per round than reaching it through an aggregator.
• You do not hold the studio relationship. Commercial terms, promotional tools, jackpot participation and early access to releases are negotiated by the aggregator, not by you.
• You inherit one dependency. One API outage affects your whole floor, not one studio's games.
• Catalogue is not uniform. Which games you can actually offer depends on the jurisdiction of the player, and the headline game count is never the number available in any one market.
• Migration has a cost. Moving aggregators later means re-integrating the wallet and re-mapping your game IDs, so the choice is stickier than it looks on day one.

None of these make aggregation the wrong answer. They make it a trade, and the trade is usually worth it below a certain volume per studio. Above that volume, going direct to your two or three biggest studios and using an aggregator for the long tail is a common arrangement.

What to check before you choose one

Game counts are the least useful number in this market, because they are counted differently by everyone and are not available everywhere. These are the questions that decide whether an integration goes well.

• How are wallet callbacks signed, and against what? Ask for the exact scheme. HMAC-SHA256 over the raw request body is a reasonable answer; "we check an API key in a header" is not.
• How are transactions identified, and is every callback safe to receive twice? Ask which field is the idempotency key. If there is no clear answer, your reconciliation will be a manual job forever.
• How are rollbacks handled? Specifically: a rollback for a transaction you never saw, and a rollback that arrives twice.
• Is there a free sandbox with simulated balances, and can you use it before signing? If testing requires money up front, you cannot evaluate the integration before committing to it.
• What is the full field reference, and when do you get it? Integrating against examples rather than a reference is how edge cases reach production.
• What is the real commercial shape? Revenue share percentage, setup fee, monthly minimum, minimum top-up, and what happens to an unused balance.
• Which currencies does a session support, and is the operator balance in the same currency as player sessions? These are often different, and it affects your reporting.
• What are the jurisdiction rules per studio? Ask for the availability list for the markets you actually serve, not the global catalogue.
• How are game IDs assigned, and are they stable? Unstable IDs break your lobby every time the catalogue changes.
• What does reporting give you, and at what granularity? Round-level data or daily totals is the difference between being able to investigate a dispute and not.

An aggregator that answers these precisely is telling you the integration is well built. An aggregator that answers them with game counts is telling you something too.

How to test one before you commit

You can answer most of the questions above yourself, before any money moves, if the aggregator has a free sandbox.

A useful evaluation is small and takes a day:

1. Get a sandbox key and launch a demo game session from your server. This tells you whether the launch call is sane and whether the documentation matches reality.
2. Point the wallet callbacks at a scratch endpoint and log them raw. Read the actual payloads rather than the documented ones.
3. Verify a signature by hand against the raw body. If you cannot reproduce the signature from the documentation, you have found a problem worth knowing about now.
4. Send the same bet callback twice and confirm your handler debits once.
5. Send a rollback for a transaction you never recorded and confirm nothing moves.

That exercise answers the signing question, the idempotency question and the rollback question with evidence instead of a sales answer. The full walkthrough, with cURL, Node.js and PHP samples, is in the free testing guide.

Questions to put to any aggregator in writing

• The exact wallet callback signing scheme, and what is signed.
• The field that identifies a transaction for idempotency.
• Documented behaviour for a repeated callback and for an unknown rollback.
• Whether a free sandbox with a simulated balance is available before signing.
• When the full field reference is provided, and whether it covers error codes and rate limits.
• Revenue share, setup fee, monthly minimum and minimum top-up, in writing.
• The currencies supported for player sessions and for the operator balance.
• Per-studio availability for the markets you actually serve.
• Whether game IDs are stable across catalogue changes.
• The granularity of reporting, and how long history is retained.