RTP, house edge and the number operators should actually check
RTP is the long-run share of stakes returned to players; the house edge is what is left. The number worth checking is not the advertised RTP but whether the running game reproduces it — which requires the operator to be able to see their own round history.
The definitions, briefly
RTP is the proportion of everything staked that a game returns to players over a very large number of rounds. A 97% game returns 97 units for every 100 staked, in the limit.
The house edge is the remainder — 3% in that example. They are the same fact stated from two directions, and any source that treats them as separate levers is confused.
Volatility is a different axis entirely. Two games can share an RTP and feel nothing alike: one pays small and often, the other rarely and large. Volatility describes the shape of the distribution; RTP describes its mean.
Why your last thousand rounds prove nothing
A thousand rounds on a high-volatility game is a small sample. Sitting meaningfully below the published RTP over that span is ordinary, and so is sitting above it. Operators new to this reliably mistake the first for a broken game and the second for luck.
The useful check needs volume and needs to be done per game and per release, because a single RTP figure across a mixed catalogue tells you about your traffic mix rather than about any game.
The check that matters
A published RTP is a claim until you can test it against your own rounds. That requires two things from a supplier, and it is worth asking for both before you integrate:
- The RTP of the exact release a round was played on, not of the game in general. Games get new versions; a figure that is not pinned to a version is not pinned to anything.
- Your own round history, in bulk, with stakes and payouts — so the arithmetic is yours to do rather than ours to report. Ours is documented here.
If a supplier can give you both, the advertised number is checkable. If they can give you neither, it is a number on a slide.
What we do about it
Every round we settle is pinned to a certified release, and that release's RTP is the binding figure. It is on the game page, in the catalogue API, and on the round itself.
Operators on a paid plan can set their own RTP within a published band on games that support it, and the value used is the one recorded against the round — so changing it changes future rounds and leaves past ones auditable.
Try it against a real API
Sandbox keys are issued instantly, with play money and every game enabled. No card, no call, and the documentation is public whether or not you sign up.
More notes
- How a provably fair crash round is actually generatedA crash multiplier is derived from a hash of a server seed the operator committed to before the round, combined with a client seed the player controls. Publish the commitment first and anyone can check afterwards that the result was not chosen.
- What a casino wallet integration actually has to doFive endpoints: balance, debit, credit, refund and rollback. The only hard requirement is that debit and credit are idempotent on the transaction id you are given — everything else is detail.
- Idempotency in a betting API, and why the key is yoursThe safest design gives the caller the idempotency key rather than generating one. If you mint the transaction id, a retry after a timeout is unambiguous — and a timeout is the one failure every integration eventually meets.