Casino API integration checklist: what to build, test and watch before go-live

Last checked 2026-10-09

A casino game API integration fails in predictable places: a retried debit charged twice, a rollback for a bet you never saw, a currency with three decimals. This checklist walks through each layer in the order a developer meets it, with the failure each check prevents.

This casino API integration checklist is for the developer who has the API keys and a deadline. It follows the order you meet things in practice: the contract between your wallet and the provider first, then the lobby, then the launch, then testing and the first week live.

Every item exists because something breaks without it. Tick them off in a shared doc, and send the open ones to the vendor’s integration team as questions.

0. Before the first line of code

• You have the full API documentation, not a sales PDF: every endpoint, every error code, example payloads.
• You know the wallet model. Seamless (the provider calls your server on every bet and win) or transfer (you move money into a provider-side balance). This checklist assumes seamless, which is what most aggregators sell.
• Staging credentials and a staging callback URL are separate from production.
• Request signing is clear: which header, which algorithm (usually HMAC-SHA256), which fields are signed, in which order.
• You know the provider’s outgoing IP addresses, if they want you to allow-list them.
• You have a named technical contact and a channel that answers within hours.

1. Wallet callbacks

The provider will call your server for four things. Build them before anything else.

• Balance. Returns the player’s current spendable balance in the player’s currency.
• Debit (bet). Subtracts the stake if funds allow, returns the new balance. Insufficient funds return the documented error code, not a 500.
• Credit (win). Adds the win. A credit for zero is valid and must succeed; many studios send it to close a losing round.
• Rollback (refund). Reverses a specific earlier debit.
• Every response is signed or validated the way the docs require.
• You verify the incoming signature on every call and reject bad ones with the documented code.
• Your endpoint answers well inside the provider’s timeout. Find the number in the docs. If it says 3 seconds, aim for under 300 ms at the 99th percentile.
• Amounts are stored as integers in minor units or as fixed-point decimals. Never as floats.
• Debit and credit carry a round ID and a game ID. Store both.

Scenario. A player on a slow mobile connection spins. Your debit succeeds, but the response takes 4 seconds and the provider gives up at 3. The provider now sends a rollback, or retries the debit, depending on its rules. Sections 2 and 3 exist for this moment.

2. Idempotency

• There is a unique constraint on the provider’s transaction ID in your transactions table.
• A repeated debit or credit with the same transaction ID does not move money again. It returns the original response, with the same balance values.
• A repeated call with the same ID but a different amount is rejected and logged loudly. That is a provider bug or an attack.
• Balance changes and transaction inserts happen in one database transaction. No window where one exists without the other.
• Concurrent calls for the same player are serialised (row lock or equivalent). Two simultaneous debits from two open game tabs must not both pass on a balance that only covers one.

3. Rollbacks

• A rollback references the debit it cancels. Look it up by the provider’s transaction ID.
• Rollback for a debit you never received: record it as a tombstone and return success (or the documented code). If the debit arrives later, the tombstone stops you charging it.
• Rollback for an already rolled-back debit returns the original response.
• Rollback of a debit whose round already has a win: follow the docs exactly. Some providers forbid it, some expect you to reverse both.
• Rollbacks never push a balance into an unexplained state. If they could make it negative, decide the rule now and write it down.

4. Rounds and unfinished games

• You can see which rounds are open (debit received, no closing credit).
• You know how the provider closes stale rounds: automatic credit after a timeout, a manual tool, or a support ticket.
• Bonus and free-round wins are tagged so your bonus logic can treat them differently from cash wins.
• Your back office shows a full round history per player: every call, every response, timestamps.

5. Currencies

• Each player has one fixed currency, set at registration, sent at launch, and echoed in every callback.
• You check that the callback currency matches the player’s currency, and reject mismatches.
• Decimal places are right per currency. Most fiat uses two, some use zero, some use three. Crypto can use eight or more; agree with the vendor on the precision used on the wire.
• Every game you list actually supports the currency you show it in. A studio may support EUR and USD but not BDT or ETB.
• Bet limits per currency make sense. A minimum bet that is small in EUR can be odd in IDR or very large in BTC.
• Display currency and settlement currency are not mixed up in reports.

6. Game list sync

• The game list is pulled from the API on a schedule, at least daily, and stored locally.
• Disabled or removed games disappear from the lobby on the next sync, not next quarter.
• New games land in a review state, not straight in the lobby, if you curate.
• You store the stable game ID from the provider, not the name. Names change.
• Images are cached on your side or served at a size suited to mobile.
• Each game carries its category, studio, device support and currency support, so lobby filters do not lie.
• Studios turned off for a market are filtered by your own rules, not left to chance.

7. Launch URLs

• Real-money launch passes a short-lived session token tied to the player. Never a password or a reusable ID.
• Token expiry is handled: an old tab shows a clear message, not a broken frame.
• Language, currency, device type and the return/lobby URL are set at launch.
• A deposit or cashier URL is passed where the game supports it, so “insufficient funds” leads somewhere.
• The game opens correctly both in an iframe and in a new window. Some studios block iframes on certain domains or browsers.
• Demo launches, if offered, never touch the real wallet. Test that explicitly.
• Launch time from click to first frame is measured on a mid-range phone on 4G. Over 5 seconds loses players.

8. Testing

• A test player per currency you will support.
• One full round per game type: slot, live table, crash, table game, virtual.
• Forced failures: your server returns a timeout, a 500, an insufficient-funds code. Watch what the provider does next.
• Duplicate calls replayed by hand: debit twice, credit twice, rollback twice.
• Out-of-order calls: rollback before debit, credit after rollback.
• Two tabs, same player, spinning at once.
• Session expiry mid-game.
• A big win and a zero win.
• Your reconciliation report matches the provider’s report for the test period, to the cent.

9. Go-live

• Production keys and callback URL swapped, staging disabled for production players.
• Monitoring on callback latency, error rate and signature failures, with alerts to a person, not a dashboard nobody opens.
• Daily reconciliation job: your totals per game and per currency against the provider’s.
• On prepaid models, a low-credit alert well above zero, and someone who can top up on a Sunday.
• A kill switch per game and per studio in your back office.
• The vendor’s support channel and escalation contact written in your runbook.

10. The first seven days

• Check reconciliation every morning.
• Review all rejected callbacks and open rounds.
• Watch launch errors per studio; one bad studio can drag down a lobby.
• Ask the vendor for their side of the error logs and compare.

A small team launching a crypto brand can get through this list in a week if the vendor’s documentation is solid. If the docs are thin, the list is also a good test of the vendor: count how many items you had to ask about. The seamless wallet ranking and the aggregators for new operators page score vendors on exactly this kind of integration work.