iGaming software solutions,
modular by design.

Buy the module, not the rebuild

You rarely need to build everything from scratch. Our iGaming software solutions are modular: take one component now, add more later, all on one API-first core.

Compare the full solutions overview or go deep on platform development.

Every module is a product with its own invariants

The systems map shows how a platform's parts connect. This page goes one level down — into the modules themselves. A module is not a feature on a slide. It is a product with its own data model, its own invariants and its own way of failing. Get one wrong and the damage surfaces somewhere you did not expect: a bonus bug drains the ledger, a stale player-state check lets someone play who should have been stopped.

This is also where the commercial argument lives. These modules are your business logic. Your margin sits in the wallet. Your retention sits in the bonus engine and CRM. Your player data sits in PAM. Rent them and all three live in a supplier's database, on their schema, behind their API — which is the point at which owning versus renting stops being about launch speed and becomes about who holds the asset.

The wallet: a ledger, not a balance

The wallet is the system of record for money, and the most common mistake is to model it as a balance — a number you read, add to and subtract from. Build it that way and you have no answer when a player disputes a withdrawal, when finance asks why GGR will not reconcile, or when two bets race and settle against the same funds.

Model it as a ledger instead. Balance becomes a derived value — the sum of immutable entries — not a stored field. Every movement is a double-entry transaction: a bet debits the player and credits the round; a win reverses it. Nothing is updated in place; corrections are new compensating entries. That gives you an audit trail a regulator and a court will accept, and it turns "what was this player's balance at 02:14 last Tuesday" into a query rather than a guess.

One balance is really three

"Balance" is not one number. Withdrawable (real) funds, locked funds — an unsettled bet, a pending withdrawal — and bonus funds are operationally and legally different money. They must be segregated in the ledger, not blended into one figure with flags bolted on. A player's real €50 and bonus €50 behave differently: one can be cashed out now, the other only after wagering. Blend them and you cannot say, correctly, what a withdrawal is actually made of.

Reconcile every round

Every game round — every spin, hand and bet — has to map to a ledger entry, and the provider's record of that round must reconcile against yours. When an aggregator says a round paid €120 and your ledger says nothing (a dropped callback, a timeout, a replayed message), you need to detect the gap and resolve it automatically, because that difference is either money you owe a player or money quietly leaving the business. It is the seam a game integration lives or dies on.

The bonus engine: where the wallet and promotions fight

The bonus engine is the module operators underestimate most. It looks like marketing configuration; it is actually accounting. A promotion is a promise to move money under conditions, and every condition is a rule the ledger has to enforce in real time.

Wagering requirements

Most bonuses carry a wagering requirement: the funds must be staked some multiple before they convert to withdrawable money. To track that, the engine has to attribute every bet to the right funds, weight contribution by game type (slots often count fully, table games less), and know the exact moment the requirement clears. This is precisely where the wallet and bonus module fight. The wallet wants one source of truth for money; the bonus engine wants to treat some of that money as provisional. If they disagree about which euro was staked, you either release bonus funds you should not have, or you void a legitimate win.

Abuse and advantage play

Bonus funds attract advantage players, and detecting them is a module responsibility. Low-variance play that only ever bets to clear a requirement, linked accounts farming a sign-up offer, hedged staking that locks in the value of a bonus — the engine needs the signals to catch these: bet distribution, device and payment fingerprints shared across accounts, timing. The point of detection is before a withdrawal clears, not after the money has gone.

Expiry and forfeiture

Bonuses expire, and when they do the funds and any winnings derived from them are forfeited. That forfeiture is a ledger event with a real accounting impact — not a flag flip. If bonus and real funds were never separated, expiry becomes impossible to compute: you cannot claw back what you cannot tell apart. It is the second reason the wallet has to segregate funds from the first commit.

PAM: the spine everything hangs off

Player Account Management is the identity and state layer for the player. It is not a login screen. It is the single record that KYC status, responsible-gaming limits, self-exclusion flags, segmentation and lifecycle state attach to — and every other module reads from it. The wallet checks PAM before a withdrawal. The bonus engine checks PAM before granting an offer. The game client checks PAM for session and limit state.

This is why buying PAM from one vendor and games or wallet from another creates the integration seam that breaks. PAM holds the answer to "is this player allowed to do this, right now?" If that answer lives in a different vendor's system than the module asking the question, every check crosses a boundary you do not control — with its own latency, its own downtime and its own version of the truth. When the two disagree — PAM says self-excluded, the game server never got the update — the failure is not cosmetic. It is a player gambling who should have been stopped, which is a KYC and responsible-gaming problem and a licence problem, not a bug ticket.

Reporting and back-office: the tooling a team actually works in

"Reporting" is three products wearing one name, each with a different consumer:

• Regulator feeds. Many licences require reporting into a regulatory system — player activity and transactions, sometimes close to real time, always in the regulator's format. Incomplete or late and the licence is at risk. It is generated from the ledger, which is another reason the ledger has to be right.
• Finance reconciliation. GGR, bonus cost, payment-provider settlement, chargebacks. Finance needs figures that tie out to the ledger and to the PSPs to the cent. "Roughly right" is not a category here.
• Operator tooling. The screen a support or fraud agent actually works a case in: find a player, read their full ledger and session history, trace a disputed round, apply a manual adjustment — which writes a ledger entry with a reason and an actor, never an in-place edit — freeze an account. Weak tooling means your team fights the software instead of the case.

Rent the platform and the back-office is whatever the supplier built. Your fraud team works the cases the supplier anticipated, with only the fields the supplier chose to expose.

CRM and segmentation: real-time triggers, one hard constraint

CRM turns player data into action: segment by value and behaviour, then trigger a message or an offer. The engineering question is real-time versus batch. Nightly batch segmentation is fine for a newsletter and useless for "this player just lost three deposits in an hour" — the moment that matters most for both retention and harm. Real-time triggers read the event stream as it happens.

Above all of it sits a hard constraint: you cannot market to a self-excluded or at-risk player. Not "should not" — cannot. That rule has to be enforced in the module, not left to a marketer to remember, and the enforcement point is PAM. Before any campaign, trigger or offer goes out, it checks the player's responsible-gaming and exclusion state — which only works if CRM reads the same PAM the rest of the platform writes to. It is the segmentation-side echo of the same seam: separate the owner of player state from the module acting on it, and the constraint eventually leaks.

When renting the modules is the right call

Owning the modules is not automatically the right move. A turnkey or white-label platform is genuinely faster and cheaper to launch: someone else already built the wallet, holds the certifications and runs the ops. If you are testing a market, short on capital or launching a single brand, renting is often the sensible first step — and we will say so.

Owning pays off when the numbers change. High volume turns a revenue share into a large recurring tax. A differentiated product needs bonus mechanics and a player experience the vendor's rules will not bend to. Multiple brands or markets multiply per-brand licence costs. And if you ever intend to sell the company, the owned platform — your ledger, your bonus logic, your player data — is the asset being bought; rent it and there is less to sell. That trade-off is the whole decision.