Frequently asked questions

Q: which method is used for api requests?

A: methods that we issue to your server like getGame for game launch are POST with json body. Seamless requests that are sent from game (balance, debit, credit and rollback) to our endpoint should be GET query string.

Q: How is session handled?

A: session is handled on your side. We expect two sessions, session_id and gamesession_id. Gamesession_id enables tracking the player game sessions (should be unique on every game launch) while session_id should be unique only per player - it is not required to change it at all. Both session should be returned to us when we call getGame and in seamless requests to our endpoint.

Q: What is the 'key' parameter in the balance/debit/credit/rollback call? It is described as 'Request validation cache key' - what is this and how to handle it?

A: key is used to sign seamless requests (balance, debit, credit, rollback), you'll have to generate it like this sha1([SALT KEY]+[QUERY STRING])

salt will be provided to you during setup
there is example there Seamless methods that your game server issues to our server

Q: We can see two error codes: 500 (server error) and 403 (the call is refused). Are there any other error codes available (e.g. account is suspended, no money, etc.)?

A: we have status 500 for general error and 403 when we want to refuse the bet. For example if player doesn't have enough money we will return 403. Status 500 should retry request or trigger rollback while 403 shouldn't. There is also status 404 used on rollback when transaction_id is not found on our side.

General flow for gameplay:

• we call getGame to your endpoint

• your api responds with game launch URL and sessions

• we will put launch URL into an iframe

• send balance call to our seamless endpoint

• send debit/credit until the round ends