Test suite scenarios
The integration test suite runs 42 scenarios against your real Test (staging) wallet. You start it in the Test environment of the portal, on the Integration test suite card of the Developers › Integration & API page. Each scenario ends as PASS, FAIL, WARN or NOT DONE.
Go-live condition
- Only the latest Test run counts, and all 42 scenarios must be PASS. WARN and NOT DONE block too.
- The Request production button opens when this condition is met and you have at least one Live IP entry; it closes once the request is sent or approved.
- A provider’s Go live button opens once the latest run for that provider, or the latest operator-wide run, has fully passed. See Going live.
Running it
- Save the operator-wide wallet settings in the Test environment first; a site wallet setting is not enough. Without it, test data cannot be saved and the suite does not start (422 WALLET_NOT_CONFIGURED).
- The suite uses your first site and its default currency; the test player needs a balance in that currency.
- Only one run at a time (409 TEST_RUN_IN_PROGRESS). The result arrives as a portal notification and by email; each row shows the details of its scenario.
Test data
| Field | Used by | If missing |
|---|---|---|
| Test player, valid token | All scenarios | The suite makes up a player and a token; most scenarios end as FAIL |
| Expired token | AUTH-03; WIN-04 and RB-06 use it too | AUTH-03 is NOT DONE |
| Blocked player | BET-05: must answer PLAYER_BLOCKED | BET-05 is NOT DONE |
| Limited player and an amount over the limit | BET-06: must answer LIMIT_EXCEEDED | BET-06 is NOT DONE |
The scenarios call your wallet directly and move real money: the test player’s balance changes. The seven engine scenarios (REQ-01, ERR-01…03, TMO-02, RND-01, RND-02) go through Boss Hub’s own bet flow and a relay in between; they need a game open to you in Test that supports your currency and limits, otherwise they are NOT DONE. Engine scenarios use the game’s minimum bet and can leave a few bench rounds open in your Test reconciliation.
Wallet calls
| Code | Call | Pass condition |
|---|---|---|
| AUTH-01 | authenticate | Valid token: OK with the test player’s player_id |
| AUTH-02 | authenticate | Invalid token: INVALID_TOKEN |
| AUTH-03 | authenticate | Expired token: INVALID_TOKEN |
| BAL-01 | balance | OK with balance |
| BAL-02 | balance | Unknown player: any ERROR |
| BET-01 | bet | 1.00 bet: OK |
| BET-02 | bet | 0.01 bet: OK (decimal precision) |
| BET-03 | bet | Another currency: ERROR, the balance does not change |
| BET-04 | bet | A huge amount: INSUFFICIENT_FUNDS |
| BET-05 | bet | Blocked player: PLAYER_BLOCKED |
| BET-06 | bet | Limited player: LIMIT_EXCEEDED |
| BET-07 | bet | Two identical bets at the same time: both OK, byte-identical replies, charged once; a later repeat gets the same reply |
| BET-08 | bet | Same transaction_id, different amount: DUPLICATE_TRANSACTION |
| BET-09 | bet | Same body and X-Request-Id, new timestamp: the same reply, charged once |
| BET-10 | bet | Free round: amount 0.00, is_freeround: true, freeround_bet_value set: OK |
| WIN-01 | win | 2.50 win: OK |
| WIN-02 | win | Zero win with round_closed: true: OK |
| WIN-03 | win | Same transaction_id again: the same reply |
| WIN-04 | win | OK even with an expired token in the body |
| WIN-05 | win | A rollback for an unknown ID first, then a win with that ID: TRANSACTION_ROLLED_BACK |
| WIN-06 | win | jackpot: {pool_id, level} set: OK |
| RB-01 | rollback | Refund of a processed bet: OK |
| RB-02 | rollback | Same rollback again: the same reply |
| RB-03 | rollback | Unknown transaction: HTTP 200 and OK |
| RB-04 | rollback | A rollback for an unknown transaction, then a bet with that ID: TRANSACTION_ROLLED_BACK |
| RB-05 | rollback | Same rollback, new timestamp: the same reply, refunded once |
| RB-06 | rollback | OK even with an expired token in the body |
Signature and request
| Code | Pass condition |
|---|---|
| SIG-01 | A correctly signed balance: OK |
| SIG-02 | A timestamp 120 s old is rejected, one 10 s old is accepted. Apply ±30 s |
| SIG-03 | A signature made for another path or another method (PUT) is rejected |
| SIG-04 | Wrong secret: JSON with status: ERROR and code: INVALID_SIGNATURE in the body (a bare 401 does not pass) |
| REQ-01 | Engine: the first attempt reaches you and Boss Hub sees a 502; the retry comes with the same X-Request-Id and body and must be charged once |
| REQ-02 | An unknown body field is ignored: OK |
"Rejected" means HTTP 401 or 403, or the code INVALID_SIGNATURE or TIMESTAMP_SKEW in the body. On callbacks, HTTP 200 with INVALID_SIGNATURE is recommended: Authentication & signing.
Errors and timeouts
| Code | Pass condition |
|---|---|
| ERR-01 | Engine: every bet attempt gets INTERNAL_ERROR; exactly 1 + your retry count attempts are made, then you answer OK to the automatic rollback of a transaction you do not know, and the balance does not change |
| ERR-02 | Engine: the first attempt reaches you and Boss Hub sees a 503; the bet is OK on the second attempt, charged once |
| ERR-03 | Engine: 200 with an HTML body; the bet stays uncertain and is refunded or voided, the balance does not change |
| TMO-01 | A 0.10 bet is answered within the timeout you chose. A reply over 80% of it is a WARN, over the timeout a FAIL |
| TMO-02 | Engine: a late reply is recorded and the bet does not count as OK |
Rounds and free rounds
| Code | Pass condition |
|---|---|
| RND-01 | Engine: a bet and two simultaneous wins; one call at a time per round, both wins OK |
| RND-02 | Engine: a win arriving while the bet is pending is queued, not sent before the bet, then OK |
| FR-01 | A free round bet (amount 0) does not change the balance |
| FR-02 | A free round rollback refunds no cash; the balance does not change |
Common failures
| Code | Cause | Fix |
|---|---|---|
| BET-07 | The second reply returns the current balance, or two simultaneous copies are charged twice. | Lock the player record, then look up the ID; store the first reply and return it as is. See bet. |
| BET-08 | On a repeated ID the first reply is returned without comparing the body. | Store a hash of the raw body; if it differs, answer DUPLICATE_TRANSACTION. |
| RB-03 | 409 TRANSACTION_NOT_FOUND is returned for an unknown transaction. | Return 200 with status: OK. See rollback. |
| RB-04, WIN-05 | The rollback is not recorded, so a late bet or win is processed. | Record the ID and answer TRANSACTION_ROLLED_BACK to a later bet or win. |
| SIG-03 | The signature covers only the timestamp and the body. | Include the method and the path too. See Calculating the signature. |
| SIG-04 | A request that cannot be verified gets a bare 401. | Return HTTP 200 with {"status":"ERROR","code":"INVALID_SIGNATURE"}. |
| WIN-04, RB-06 | INVALID_TOKEN is returned for an expired token. | win and rollback must be accepted regardless of the token’s expiry. |
| ERR-01 | The automatic rollback does not get OK for a bet you have no record of. | Answer OK to a rollback of an unknown transaction and record it. |
| TMO-01 | Replies close to the limit (WARN) block going live. | Make the callback faster; if needed, choose the 5 s timeout in the portal. |