Use this checklist to prepare the project technical review and collect implementation evidence.
Last reviewed: 2026-08-10
- First content set and delivery scope are written down.
- Target languages, currencies, and market context are identified for review.
- Product, engineering, operations, and AG technical owners are named.
- Single-wallet or transfer-wallet direction is confirmed.
- Later-phase items are recorded.
- Merchant player identifiers are stable and use the minimum personal data required by the workflow.
- Game-session creation and return-path behavior are mapped.
- Session expiry, logout, and interrupted-return scenarios have expected outcomes.
- Request and transaction identities can be traced across both systems.
- The authoritative balance and ledger owner are unambiguous.
- Money-changing operations are idempotent according to the project protocol.
- Duplicate, delayed, rejected, and uncertain operations are covered by tests.
- A transaction query or reconciliation path exists before retrying an uncertain transfer.
- Balance precision, currency rules, and amount representation are mapped from the project specification.
- Game and wallet records can be queried for a bounded time range.
- Logs retain only the required timing, result code, trace identifier, and masked business identifiers; keys, full signatures, tokens, player details, and complete transaction payloads are excluded.
- Reconciliation has an owner, schedule, evidence format, and escalation threshold.
- Monitoring distinguishes transport errors, business errors, and record differences.
- Support evidence uses redacted player and credential data through the designated channel.
- Test and production hosts, credentials, and allowlists are stored separately.
- Signing keys and other secrets are stored only in the designated server-side secret-management system, not in browser code, client packages, logs, tickets, chat, or public issues.
- The final protocol defines accepted timestamp skew, nonce uniqueness, and rejection of expired or replayed requests.
- Merchant-level authorization limits access to the agreed endpoints, wallets, players, and records.
- Rate, concurrency, pagination, and transaction-value limits and their alerts are confirmed.
- Callback endpoints apply the agreed authentication, validation, replay protection, rate protection, and observability.
- Expired timestamps, reused nonces, concurrent duplicates, unauthorized access, and limit enforcement are covered by tests.
- Access rotation and revocation are independent from public documentation.
- The happy path passes through the real test entrypoint.
- Timeout, retry, duplicate, delayed callback, and record-difference cases pass.
- The provider and title delivery set is verified in the target environment.
- Operations can stop traffic, recover funds through the configured workflow, and escalate an incident.
- Regional launch requirements have named owners and recorded completion evidence.
For the reasoning behind these checks, read Reliability and transaction reconciliation.