Slot Aggregator Platform Case Study: Designed So a Player Is Never Charged Twice

Our client is a European iGaming aggregator — the layer between game studios and casino operators. Slots, and increasingly crash and instant titles, flow from studios worldwide into one catalog, then out to operators through one API on top of a unified Player Account Management system.

Simple to describe. Less simple to build.

For this client, we didn't build a website with games on it. We built the layer underneath one.

One API, many dialects

Every studio integration runs through a normalized provider adapter — launch, debit, credit, rollback — all speaking the same internal contract on a Node.js microservices core. That's why onboarding the twelfth studio looked a lot like onboarding the third.

A ledger that doesn't lie

The wallet sits on an append-only PostgreSQL ledger, with an idempotency key on every external transaction. When a provider retries a BET because a response got lost in transit, the second request gets back the original result. Charged once. Rollbacks are compensating entries, never balance overwrites — because a duplicated €10 bet isn't a bug ticket, it's a player complaint, then a reconciliation nightmare, then possibly a regulator's letter. Boring design, deliberately. Boring is what money needs.

Kafka as the nervous system

BET_CREATED. WIN_CREATED. ROUND_COMPLETED. Every step becomes an event on a Kafka stream, so analytics, reporting and reconciliation all consume the same data without ever sitting on the hot payment path. Per-provider latency monitoring trips circuit breakers the moment a studio degrades.

Redis where it counts

Session tokens, idempotency locks, hot game state. Honestly, most of the gap between a sluggish spin and an 80ms one was caching discipline and connection pooling, not exotic hardware.

Compliance as a product

The catalog is jurisdiction-aware down to the individual game: market availability, certification status, operator license. eCOGRA-format logs export automatically, and UK rules — the £5/£2 stake limits, the 2.5-second minimum spin interval — are enforced at engine level rather than patched in per market. When a new regulated market opens, enabling it is a configuration change, not a project.

• 2,000+ titles live from global studios under one API and one PAM
• P95 wallet transactions under 80ms — the brief said 100
• 99.99% uptime, held across the first 12 months of live traffic
• Daily reconciliation has remained clean across millions of rounds a month, with mismatches surfaced automatically rather than discovered by accident
• No operator-reported financial disputes arising from duplicate transactions since launch
• New studios live in days, not weeks

One afternoon, a studio's retry storm sent us the same BET eleven times in under a minute. The idempotency layer returned the original result eleven times. The player was charged once. That's the whole platform in one story.

The hard part of an aggregator was never showing a thousand games. It's making sure 2,000 games × dozens of studios × millions of spins still produces the right financial answer — every time, even when networks drop, providers time out, and the same callback arrives twice.

We've carried that lesson into everything since, from crash game development — where the transaction cadence is even harsher — to full casino and sportsbook builds.