Integration Guide · 2026
Casino API security: signatures, allowlists and idempotency explained
A casino API moves money on every spin. Security here is less about firewalls and more about three questions: is this request genuine, is it harmless if it arrives twice, and can every balance change be traced afterwards? These are the controls to agree with your provider before the first real bet.
The short version
- Sign every request in both directions and reject anything that fails the check.
- Allowlist server IPs on both sides; wallet endpoints are never open to the internet.
- Make every wallet call idempotent on the transaction ID.
- Keep session tokens short-lived and bound to one player and one game.
- Log every request and response; you will need them in a dispute.
What a signed request proves
A signature is a hash of the request body and a timestamp, made with a secret only you and the provider hold. The receiving side recomputes it; if the two values differ, the request was forged or altered and is rejected. The timestamp matters too: accept requests only within a short window, and a captured request cannot be replayed an hour later.
At IGP every call through the casino API carries a hash so the server can prove it came from you. Ask for the same protection on the callbacks that reach your wallet, and test both directions, not just the one you send.
IP allowlisting
Your wallet endpoint is where money moves, so it should answer only the provider’s servers. Agree fixed outbound IPs on both sides, keep separate lists for staging and production, and treat any change to the list as a change request, not a quick fix.
Idempotency: the control that protects balances
Networks time out. When a provider does not get your answer in time, it sends the same debit or credit again. If your wallet treats the retry as a new transaction, the player pays twice or is paid twice.
The fix is simple and non-negotiable: store every transaction ID, and when one arrives again, return the original response without moving the balance. Rollbacks must reference the transaction they reverse. Our casino API integration checklist has the tests for all three cases.
Session tokens and game launch
A game session starts with a token your platform issues at launch. Bind it to one player, one game and one currency, give it a short life, and check it on the first wallet call. Do not put personal data in launch URLs; a player ID and a token are enough.
| Control | What it stops | Who owns it |
|---|---|---|
| Request signature | Forged or altered calls | Operator and provider |
| Timestamp window | Replayed requests | Operator and provider |
| IP allowlist | Calls from unknown servers | Operator and provider |
| Idempotent transaction IDs | Double debits and credits on retry | Operator wallet |
| Short-lived session tokens | Hijacked or reused game sessions | Operator platform |
| TLS on every call | Interception in transit | Operator and provider |
| Audit logs | Disputes you cannot prove either way | Operator and provider |
Before go-live
- Send a request with a wrong signature and an expired timestamp; both must be rejected.
- Call the wallet from an IP that is not on the list; it must be refused.
- Send the same debit twice and the same credit twice; the balance must move once each.
- Launch a game with an expired token; it must not open a real-money session.
- Pick a random round from yesterday and trace it end to end in your logs.
Frequently asked questions
One signed integration, 150+ providers
Signed requests, one wallet and one normalised transaction stream for 18,000+ games, with a sandbox to test every control above.