Requests and responses
Test valid and invalid input, authentication boundaries, required fields, precision, identifiers, status handling and documented error behaviour.
Acceptance criteria
Define “ready” before
the launch review.
These criteria evaluate selected FastGamesAPI games and the RGS integration before production review. The operator wallet remains the balance authority; testing must show that each game result, RGS round record and wallet response stay aligned through normal, repeated and failed requests.
Core test groups
Test the game, money path and recovery together.
Run the agreed cases in the intended environment and keep enough information to reproduce a failure without relying on screenshots alone.
Money-path correctness
Verify debit, credit, insufficient balance, duplicate delivery, timeout, retry and reconciliation behaviour against the operator’s ledger.
Game-rule outcomes
Cover normal, boundary and invalid player choices; confirm the visible result, backend record and settlement describe the same round.
Reproducible evidence
Capture commitment and reveal inputs, reproduce selected outcomes and confirm that support can retrieve evidence by round identifier.
Configuration boundaries
Check minimum and maximum inputs, currency precision, payout or exposure constraints and behaviour when configuration changes between sessions.
Player experience
Test supported viewport and browser targets, interrupted sessions, refresh and resume behaviour, localization, loading and clear error feedback.
Results and exit criteria
A pass should be easy to reproduce.
For each case, keep the test identifier, environment, game and configuration version, player action, expected result, observed result, round and transaction identifiers and relevant timestamps. Sensitive values belong in the approved test system.
Agree severity and exit criteria before execution. Money-path, authorization or reproducibility defects must remain visible until resolved. If a lower-severity presentation issue is accepted, give it an owner and follow-up date. Re-running a failed case should create a new result instead of overwriting the original.
- Every required test group has an accountable owner.
- Expected results are written before final execution.
- Failures, retries and duplicate requests are tested deliberately.
- Round, wallet and support records can be correlated.
- Open defects and accepted exceptions are included in the launch plan.
Extend this baseline for each format. Dice needs boundary choices; Plinko needs board and risk selections; crash games need timed-state and interrupted-session cases. Use the game pages for format-specific details, and align the selected set with the commercial proposal.