How RTP Is Set, Tested and Certified: A Developer Breakdown

By Ankur Gupta | Updated May 2026 | 18+ | Play Responsibly

There is a number sitting quietly in the information panel of every slot game you have ever played, and most players scroll past it without a second thought. Return to Player or RTP. You will see it written as a percentage, anywhere from 96% to 96.5%, sometimes as high as 97% or as low as 92% on games that have no business being on a reputable platform. Players who know what they are doing use it to decide which games deserve their bankroll. Regulators use it to define what is and is not acceptable. Operators use it to calibrate their margins and studios like ours use it as one of the first and most important design decisions we make before a single line of code gets written.

What I almost never see explained properly is where that number actually comes from. Not the definition, because plenty of sites will tell you RTP means the theoretical return over millions of spins, but the real process. How a studio decides what RTP a game should have, how that decision gets translated into code, and what independent certification actually verifies before a game is allowed to go live. I have been through this process more times than I can count with our games at TopSpin, and I still find that most of what gets written about it online is either too surface-level to be useful or so technical it loses the plot entirely. So let me walk you through it the way I would explain it to someone sitting across from me.

What does RTP actually mean?

The textbook definition is straightforward enough. Return to Player is the theoretical percentage of all wagered money that a game returns to players over an infinite number of spins. A slot with a 96% RTP will, across enough rounds, return 96 paise for every rupee put into it. The remaining 4 paise is the house edge, the margin that sustains the operator’s business and, through revenue share, the studio’s as well.

The word theoretical carries more weight than people give it credit for. RTP is not a session guarantee, and it is not a promise about what you personally will get back in any given sitting. I have played our own games during testing and had sessions where I returned 200% of my stake and sessions where I burned through a test budget in far fewer spins than the math would suggest. That is not the game misbehaving. That is variance doing exactly what it is supposed to do. The stated RTP only begins to assert itself as a reliable average once you are looking at tens of millions of spins, not the few hundred a typical player might put in on an evening.

The other number that always needs to be understood alongside RTP is volatility, and this is where I think a lot of player guides do a disservice by treating them separately. Two games can carry identical RTPs and feel completely different to play, because one pays out in infrequent but significant wins while the other drips returns steadily in smaller amounts. When I sit down to design a game, I am not just targeting an RTP figure in isolation. I am thinking about the shape of how that return is distributed, because a game that feels wrong in the hand, too cold for too long or too flat to be exciting, will fail in the market regardless of whether the math is technically correct.

How does a studio actually set RTP?

The process begins long before development starts, which surprises people when I tell them. RTP is not something you calculate at the end and check against a target. It is a foundational design decision that gets locked into the math model at the very start of the project, and everything that follows is built around it.

The math model is the document at the heart of every slot game. It defines every symbol the reels carry, every possible combination those symbols can form, the frequency at which each combination appears, the pay multiplier attached to each outcome, and the rules that govern every feature, including how the free spins trigger, how the multiplier accumulates and what happens when scatters land during a bonus round. Every variable that influences how money moves through the game lives in the math model. 

When I am working on a new title, this document is the one I spend the most time in, because getting it right is what determines whether the game is commercially viable and whether it will pass certification.

The target RTP we set is shaped by a combination of pressures. On one side, there are operator requirements: serious licensed platforms have minimum RTPs they will accept into their libraries, and the market standard for a mainstream slot sits somewhere between 94% and 97%. Go below that and you will struggle to get distribution with operators worth having.

On another side, there is the competitive landscape. If the titles we are going up against in a particular category are paying at 96.5%, we need to understand what we are saying to the market if we launch at 94%. And running through all of it is the commercial reality that the house edge is the margin that keeps the lights on. There is a viable range, and working within it is not optional.

Once the target is set, the math team runs the model through simulation before any code gets written. We are talking tens of millions of virtual spins, checking that the theoretical RTP converges on the target and that the volatility profile, meaning the distribution of wins across the pay range, matches the intended feel of the game. I have sat in sessions where a model that looked right on paper produced a volatility curve that nobody wanted to ship, and we went back to the whiteboard. That is entirely normal and far better than discovering it after development is underway.

How does RTP get into the actual game code?

After the math model is signed off, the development team implements it in code. The engine that drives every spin is the Random Number Generator, and understanding what the RNG actually does and does not do is important for making sense of how RTP works in practice.

The RNG generates a random number. That is its entire job. It has no awareness of what RTP the game is designed to produce, no memory of previous outcomes, and no mechanism for adjusting future results based on how a session has gone. What it produces is a raw number, and the game logic then maps that number onto a symbol combination using the weighting tables from the math model. The relationship between the RNG output and the resulting symbol combination is determined entirely by those tables. If the tables accurately reflect the math model, and the math model was built to hit the target RTP, the live game will pay at the right rate across a sufficient sample.

If either the math model contains an error or the code implementation does not faithfully follow the model, the game will pay at a rate different from what it claims. This is not a theoretical risk, it happens, and I have seen it happen to us during internal testing. It is exactly why the certification step exists and why it cannot be treated as a formality.

What does certification actually test?

When we submit a game to a testing laboratory, whether that is GLI, iTech Labs, BMM Testlabs or eCOGRA depending on the jurisdiction, we hand over two things: the complete source code and the math model the code is supposed to implement. The lab then runs its own independent verification across three areas.

• RNG itself

Using statistical test batteries including the NIST suite, the lab verifies that the RNG output is genuinely random, free from patterns, and cannot be influenced externally. A biased or predictable RNG is a root-level failure that makes everything else about the certification irrelevant, because the game cannot be considered fair if its outcomes can be anticipated or manipulated.

• Math model verification

 The lab runs the game in independent simulation, typically hundreds of millions of rounds conducted entirely outside our systems, and checks that the actual return converges on the stated theoretical RTP within an acceptable tolerance. If we have declared 96.5% and their simulation comes back at 94.8%, that is a failure and we resubmit. We have had to do that. Finding the discrepancy usually means a painstaking comparison between the math model specification and the code implementation, looking for the place where the two diverged. It is not glamorous work but it is necessary, and I would rather catch it in certification than have a live game paying incorrectly.

• Rules and pay table verification

 The lab checks that the in-game rules accurately describe how the game actually behaves, that the pay table matches the math model, and that every feature operates exactly as documented. A game that claims free spins trigger at one frequency but actually triggers them at a different rate will fail this check even if the headline RTP is correct, because players are entitled to accurate information about the game they are playing.

Only when all three components pass does the lab issue a certificate. That certificate names the exact build, the stated RTP and the jurisdictions for which it has been approved. It is the document that tells operators and regulators that an independent party has verified this game does what it claims.

What operators are actually buying when they add a certified game?

When an operator adds one of our certified titles to their library, they are licensing the certified build, not a version of it, not something similar, but the exact code that went through testing. If they want to offer the same game at a different RTP configuration, which happens more often than players realise because different markets carry different margin requirements, that is a separate certified build with its own certificate. The two versions are legally distinct products.

This distinction matters particularly for Indian players, because the platforms accessible here operate under a range of licensing regimes and the standards are not equivalent. A Curacao-licensed game has been certified to Curacao requirements. A UKGC-certified game has been held to a considerably stricter standard, including more rigorous RNG testing and a requirement that operators make RTP information genuinely accessible to players before they start playing. At TopSpin, our framework aligns with UKGC standards because that is the level we hold ourselves to, not because we are required to by every market we operate in. Every game goes through independent certification before it goes live, and I would not have it any other way.

How to find the RTP of a game before you play?

Every certified game is required to make its RTP accessible to players. In practice, you will find it in one of two places: the in-game information panel, usually accessible through a menu icon within the game interface, which will list the RTP either as a single figure or as a range if the title is available in multiple configurations; or the studio’s official game page, which should carry the certified figure for every title in the catalogue.

If you open a game and genuinely cannot find the RTP, treat that as a meaningful signal. It does not automatically mean the game is rigged, but it does mean the operator is not being transparent about information they are required to disclose. That is not a platform I would be comfortable recommending, and it is not one you should feel obligated to stay on. Every game we feature on this site carries a publicly available, independently verified RTP figure, and I would not include a title that did not.

As a general rule, anything below 94% should prompt a pause unless you are consciously choosing a high-house-edge title with your eyes open. That is not a moral judgement, there are legitimate reasons to play a wider range of games, but you should be making that choice knowingly rather than discovering it after the fact.

Conclusion 

RTP starts as a target set during game design, built into a math model that defines every aspect of how the game pays. That model is translated into code, and before the game goes anywhere near a live platform, an independent testing laboratory runs hundreds of millions of simulated rounds to verify that the actual return matches what the studio claims. The certified build, the exact code the lab approved, is what operators licence and what players interact with.

The number is not marketing and it is not a guess. It is the output of a designed probability model and the signature of an independent third party confirming that the model works as described. After years of building games and going through this process, I still think it is one of the most important things a player can understand before they decide where to put their money.