Failed possible tests
- Anej Hrobat
Balance → 7) seamless player balance callback *
Debit → 8) seamless debit players balance callback *
Credit → 9) seamless credit players balance callback *
Rollback → 3.4 seamless rollback transaction callback *
Basic test
Get first balance
We get balance from the player
Test credit win 10
To the player 's balance, we add a win amount: 10.
Rounds with only wins can occur due some providers supporting promo wins, which can be played out at random, so you should expect and accept those wins as well.
Test debit bet 5.
The amount is deducted from the player's balance
Rollback the previous bet without round_id, game_id and without amount – you should not rely on amount in rollback, only on transid
Rollback should work based on transactionid (and player) and you load amount from your existing transaction. you must get player balance from the previous bet
Test salt check using debit call - you should verify requests
Test salt check, if hash == key
Advanced test
Remove all balance
We place a bet in the beginning of the test for the amount of the users balance. Meaning, if the player's balance is: 1000, then we send a debit of 1000
Add 1000 initial balance
We place a win for 1000, so we start the tests with the user having 1000€.
Test zero Bet. status 200 expected
If the bet is 0, the transaction is not processed, status must be 200
Example: {“status”: 200, “balance”:1000}
Bet amount = 5 again with same transid: Balance must stay the same
if you receive bet with same transactionid for same player, you should not process it again, but return same response as first time
2 players test
Transactions are unique on individual players only, it can happen where 2 players playing same table at the same time, they will receive same rounds and transactions. You need to handle transaction_id as unique on players and must be processed separately.
What we are testing here is an extreme case that could happen if two players are playing on the same livecasino table. In that case, they would both receive debit/credit requests with different or same amounts, but with the same transaction_id and round_id. Other case where this could happen is if a Customer would be taking provider from 2 different servers, where transaction_id's could also double. It is suggested to internally check for transactions or rounds on player. (for example Customer internaltransactionid = transaction_id + remote_id).
Concurrent test
We basicially sycnhronously send 10 requests at the same time to your API, and would expect final balance to be correct.
Concurrent test with wins
This test generates duplicate transactions for each request sent to the client. Number of requests will specify number of rounds (credit and debit pair). So if number of requests is 10, it will send 40 requests, with 2 identical debits and 2 identical credits in a single round, out of which only single debit and single credit are to be processed.
For example: If we send 4 transaction debit x2 and credit x2:
At the beginning of a test, player has 915 balance. we send debit with amount 5 and transactionid ending on "count11" you process it and balance should be is 910.
Next, you receive another debit with amount 5 and transactionid ending on count11
And balance should be the same as previous debit is 910.
Then you receive credit with amount 5 and transactionid with “count12”.
You must return status 200 and balance should be 915
And then you receive another credit with amount 5 and transactionid with “count12”
The final balance should be 915