Skip to main content
Common questions about integrating your casino site with the PlayStarters aggregator. If you can’t find the answer here, see the Troubleshooting guide or contact the support team.
PlayStarters is an iGaming aggregator. We give your casino site a single integration point to access a catalog of games from many providers. We do not provide a player-facing site, KYC, payments, licensing, or back-office tooling — those remain on your side.Your side owns: the player accounts and wallet, the casino site UI, payments, KYC/AML, licensing, and CRM.PlayStarters owns: the games catalog, provider relationships, game session orchestration, and the wallet callback protocol.
Contact the PlayStarters team. After onboarding you receive:
  • An Operator API key (format ps_<your_api_key>) for calling the Operator API.
  • A wallet key that PlayStarters will use as a Bearer token when calling your wallet callback endpoint.
  • The base URL for the Operator API.
Store both keys in a secrets manager or environment variables. Never commit them to source control.
Two things:
  1. Backend calls to PlayStarters — call /operator/providers, /operator/games, and /operator/launch to populate your lobby and start game sessions.
  2. A wallet callback endpoint — a single POST endpoint we call to read balances and process BET, WIN, and VOID transactions. See the Seamless Wallet Overview.
Everything else (player accounts, deposits, withdrawals, lobby UI, KYC, responsible gaming) stays on your side.
The currency on each game session is whatever you pass as currency in POST /operator/launch, as long as the game supports it. Use ISO 4217 codes (e.g. EUR, USD, BRL).Talk to your account manager about specific currency support per provider.
Each transaction has a unique request_id. WIN and VOID calls include a parent_transaction_id referencing the request_id of the original BET, so you can group them into a single game round.
PlayStarters will retry failed calls. To stay safe:
  • Respond within a few seconds, ideally under 1 second.
  • Implement idempotency keyed on request_id so retries don’t double-debit or double-credit the player.
  • Reject BET with 400 and { "msg": "Insufficient user credit" } only when the player truly lacks funds — never for transient errors. Other errors will be retried.
Yes. Your sandbox base URL and credentials are provided during onboarding. Use the sandbox to test your wallet callback end-to-end before switching to production.
See the Contact page. When reporting an issue, include your operator ID, the affected endpoint, the request_id from the call, the timestamp (with timezone), and the request/response payloads with secrets redacted.