Gamification for iGaming operators
Give your players a reason to come back tomorrow.
Levels, missions and rewards running on the events your platform already produces. Nothing to rebuild, no change to your game provider, and a control group in every programme so you can see what it actually changed.
Why it works
A bonus buys a session. A level builds a habit.
Bonuses have a ceiling. They reward the moment, not the routine, and most of the money goes to players who were going to play anyway — with no way to tell which ones those were. What keeps somebody coming back is unfinished progress, and progress costs nothing to hand out.
Progress
A level three quarters climbed is a reason to return that you do not have to fund.
Rhythm
Daily missions and streaks turn an occasional visit into a habit with a clock on it.
Status
A tier is visible, and visible things get defended. Losing one is felt more than gaining it.
Payoff
Rewards land when they are earned, so the reward reinforces the behaviour instead of replacing it.
The platform
Everything a complete programme needs.
Configured in a backoffice, not in a deployment. The people who run the programme change it themselves, and every change is signed and audited.
Loyalty ladder
Levels with their own thresholds, multipliers and artwork. Points can accrue for a lifetime, over a rolling window, or per calendar month, with an optional grace period before anyone drops.
Earning rules
Which game, which provider, which stake and which currency earn — and at what rate. Edited live, with a simulator that shows what a rule would have paid before it goes on.
Awards and triggers
Free spins, bonuses, cashback or tokens, granted on a level-up or a points threshold, with per-player caps, cooldowns and a campaign budget that cannot be overspent.
Token shop
Players spend what they earn on what you stock. Limited stock, minimum level and per-player limits, all enforced inside one transaction.
Game catalogue
Discovered from your own event stream, so it is never out of date. Exclude a provider or a single title and it stops earning from the next event.
Fulfilment
Prizes are delivered to your provider through an outbox with retries and a circuit breaker. A provider outage delays a prize; it never loses one.
Reports
Ten reports over closed days, exportable, plus a dashboard that tells you when the event stream has gone quiet instead of waiting for you to notice.
Operations
Dead-letter inspection, replay with a preview, background job history, and an audit trail with the before and after of every change.
Access control
Roles per merchant, mandatory two-factor for administrators, and tenant isolation enforced by the database itself rather than by remembering a WHERE clause.
Measurement
And we tell you how much of it was us.
Every programme holds back a percentage of players from the start. They play the same site, without the programme, and the platform compares the two groups on the metrics you care about — sessions, deposits, retention, net revenue.
It is not a projection over your own history, which always flatters the vendor. It is a measured difference against real players. The report says when the gap is not big enough to trust, and it will say so about our own numbers.
The holdout is opt-in and configurable, and it is fixed once players are assigned — changing it mid-flight would leave you comparing two populations that no longer match.
Illustrative figures from the demo dataset.
Integration
One event on a queue.
Publish what you already record — a bet, a deposit, a login — and the platform does the rest. Nine signed endpoints read the player's state back so you can draw it into your site.
// your backend, when a player places a bet publish("gp.events.your-casino", { EventUid: "a3f1…", CustomerID: "9f2c…", Action: "Bet", Amount: 25.00, Currency: "EUR", Provider: "Pragmatic", GameID: "2324" });
// and to draw the player's state GET /v1/customers/{id}/gamification { "level": { "code": "GOLD", "ordinal": 3 }, "levelPoints": 4820, "nextLevel": { "code": "PLATINUM", "at": 6000 }, "tokenBalance": 1250, "awards": { "claimable": 2 } }
Every request is signed with HMAC-SHA256. There is no bearer token and no session, and the operator a call belongs to comes from the credential rather than from anything in the request — so there is no parameter to change that would let one operator read another's players.
Talk to us
Tell us what you operate.
We will come back with a demo built on your own game catalogue, and an honest read on whether this is worth your time — including how long the integration would take with your stack.
Prefer to look first? The live demo is open, no sign-up.
Write to us
Tell us what you operate, roughly how many players, and what your event stream looks like today. That is enough for us to come back with something concrete.
Email usNo form, no tracking, nothing stored on this site. See the privacy notice.