Integration certification
Certification is performed per operator, environment, currency and deployed revision. A green deployment or a successful demo does not certify an operator’s wallet. Run financial scenarios with authorized test accounts and test funds.
What to hand over
Section titled “What to hand over”Record the tenant ID, sportsbook and wallet URLs, contract revision, currency, allowed embed origins, callback ownership and incident contacts. Exchange the integration API key and wallet signing secret through the agreed secret channel; never put them in tickets, screenshots or test evidence.
For each case retain: case ID, UTC timestamps, bet ID, transaction IDs, sanitized requests/responses, initial/final wallet balances, expected/actual outcome, deployed commit, tester and reviewer. An unexecuted case is not tested, not passed.
Sessions and interface
Section titled “Sessions and interface”| ID | Scenario | Required outcome |
|---|---|---|
| S01 | Create and reopen a session for the same external player | Same player identity within the tenant; another tenant remains isolated. |
| S02 | Redeem the same launch token twice; redeem an expired token | First valid redemption succeeds; reuse and expiry fail. |
| S03 | Anonymous browsing followed by login | No secret in the browser; login callback restores an authenticated session. |
| S04 | Logout, idle expiry and token renewal | Protected operations require a valid session; the host receives the documented events. |
| S05 | Unlisted iframe origin and forged postMessage sender | Rejected. Only the configured origin and iframe source are trusted. |
| S06 | Phone and desktop; English and Portuguese | Betslip, keyboard focus, scrolling, errors and cashier callbacks remain usable. |
Wallet and money safety
Section titled “Wallet and money safety”| ID | Scenario | Required outcome |
|---|---|---|
| W01 | Valid HMAC; changed body; wrong secret; stale timestamp | Only the correctly signed fresh request is accepted. Verify exact bytes, before JSON transformation. |
| W02 | Debit with sufficient and insufficient balance | Exact stake once, or a durable insufficient_funds refusal with no movement. |
| W03 | Concurrent duplicates and retry after restart | One financial effect and the original response, including refusals. |
| W04 | Reuse ID with changed player, amount, currency, kind, bet, reference or endpoint | Conflict; no new effect. |
| W05 | Debit commits but response is lost | Bet not accepted on uncertainty; rollback restores stake exactly once. |
| W06 | Rollback arrives before debit | Persist a tombstone for the original debit; reject that debit if it arrives later. |
| W07 | Debit never applied; rollback is repeated | No credit is created; rollback succeeds idempotently with unchanged balance. |
| W08 | Win, loss and void | Correct payout, explicit zero credit for a normally settled loss, or refund. |
| W09 | Credit applied with response lost; later retry | One credit, original transaction ID and stored result. |
| W10 | 2xx with missing/mismatching ID, missing/null balance or wrong currency |
Unknown, never accepted as payment confirmation. |
| W11 | HTML/empty 4xx, 408, 429, 5xx and timeout |
Unknown; never interpreted as proof that no money moved. |
| W12 | Structured definitive refusal | No automatic collection of a refused obligation; operator review is visible. |
| W13 | Won → lost or changed payout with available funds | Exact correction delta, distinct immutable correction ID, same bet. |
| W14 | Correction exceeds available balance; deposit afterwards | No partial debit or negative balance. Refusal remains final; later deposit is untouched. |
| W15 | Result corrected while the preceding credit is unknown | Obsolete credit is held for review without automatic replay; the later correction remains blocked. |
| W16 | Worker crash and recovery during callback | Same transaction identity; no duplicate economic effect or late-response status regression. |
| W17 | Wallet unavailable for two minutes and restored | Stakes remain unaccepted on unknown outcomes; owed operations recover under the documented retry policy. |
Betting lifecycle and market controls
Section titled “Betting lifecycle and market controls”| ID | Scenario | Required outcome |
|---|---|---|
| B01 | Single, accumulator, system, supported each-way and Bet Builder | Stake, combination count, settlement and rounding match the offered product’s rules. |
| B02 | Full cash-out followed by event-result correction | The closed position is not settled a second time. Credit delivery is independently traceable. |
| B03 | Partial cash-out, retry, then settlement of the remainder | Each partial closes only its stake share; retry does not close or credit it twice. |
| B04 | Automatic cash-out and simultaneous player request | One valid transition per request and no double consumption of remaining stake. |
| B05 | Disable a market for operator A | A cannot place a new bet on it; B is unaffected. Existing bets remain recorded. |
| B06 | Feed updates while A’s market is disabled | The operator hold persists. Feed reopening does not remove it. |
| B07 | Enable while feed or platform still blocks the market | Remove only A’s hold; UI accurately reports continued unavailability. |
| B08 | Restart immediately after a confirmed disable/enable | Acknowledged control survives, without depending on a graceful shutdown. |
| B09 | Read-only/support role or another tenant attempts mutation | Server refuses unauthorized action. Audit records successful authorized controls. |
| B10 | In-play stop or odds change during placement/cash-out | Exercise before, during and after wallet latency. Verify the acceptance boundary; do not infer this from the disabled button. |
| B11 | Special result authorized while settlement delivery is interrupted | The special closes and its result persists together; no later bet is accepted. Restart/replay settles existing bets with the original result version, once. |
| B12 | Quote update during final commit in each product | Repeat for catalogue, outrights, specials, virtuals, number draws and racing. Source changes wait for the local commit; the next commit sees them. A blocked commit must respect its timeout. |
Release decision
Section titled “Release decision”Attach the scenario evidence and resolve every financial mismatch before enabling real money. Confirm the actual feed source, freshness/recovery behavior, supported markets and result verification separately from wallet delivery. Simulation proves software integration, not the correctness or latency of a contracted live feed.
Re-run affected scenarios after changing wallet handlers, credentials, retry policy, market controls or financial posting logic. Preserve the previous release and its migration/rollback plan. Agree incident escalation and reconciliation ownership before launch; a pending financial obligation must never disappear merely because a support case is closed.