All posts
Security

Casino API Security Best Practices — Protect Wallet Callbacks in 2026

Sep 13, 2026 · 11 min read

Casino API security is wallet security. Every bet, win and rollback moves real money, so a weak callback endpoint is a direct route to chargebacks and licence problems. These are the controls we require from operators integrating GamingAPI — 16,000+ games and 150+ studios through a single wallet contract.

1. Sign every callback

Compute an HMAC-SHA256 signature over the raw request body using a per-client secret and compare it in constant time. Never parse JSON before the signature check, and never accept a request whose timestamp is more than 60 seconds old — that single rule kills most replay attempts.

2. Lock traffic to known IPs

Whitelist the aggregator's egress ranges on both sides. Operators running on serverless platforms need a fixed-egress proxy, otherwise the outbound IP changes and the provider rejects launch calls with a "no IPs whitelisted" error.

3. Make debit and credit idempotent

  • Store the provider transaction ID with a unique constraint.
  • On a duplicate, return the original result and the current balance — not an error.
  • Use row-level locks so two concurrent callbacks cannot read the same stale balance.
  • Rollback must reverse only a debit that exists and has not already been reversed.

4. Separate keys per environment

Sandbox and production credentials live in different secret stores. Nothing sensitive ships in the browser bundle. Rotate keys every 90 days with an overlap window so live traffic never breaks.

5. Rate-limit and monitor

  • Per-key rate limits on launch and wallet endpoints.
  • Alerts on signature failures, balance mismatches and unusual win-to-bet ratios.
  • Immutable logs of round ID, transaction ID, timestamp and raw payload for dispute resolution.

6. Reconcile daily

Compare your ledger against the provider settlement report every day. GGR is bets minus wins; if the two sides disagree, the cause is almost always a missed rollback or a duplicated credit that idempotency would have prevented.

Security checklist

  • HMAC verification on the raw body, constant-time compare.
  • Timestamp window and nonce replay protection.
  • IP whitelisting with a fixed egress address.
  • Idempotent debit, credit and rollback.
  • TLS 1.2+ only, HSTS enabled.
  • Key rotation every 90 days with overlap.
  • Rate limits, anomaly alerts, immutable audit logs.
  • Daily GGR reconciliation against settlement files.

Want the reference implementation? Our API documentation includes signed callback examples, and the integration checklist covers the full go-live path.