Lottery Platform UAT & Go-Live Acceptance Checklist
Lottery platform UAT should establish that the agreed release handles real business journeys and their failures, not simply that its screens load. Use an acceptance matrix that links each requirement to synthetic test data, an expected outcome, evidence and an accountable approver. Go-live requires a separate operational decision based on those results and the remaining […]
Lottery platform UAT should establish that the agreed release handles real business journeys and their failures, not simply that its screens load. Use an acceptance matrix that links each requirement to synthetic test data, an expected outcome, evidence and an accountable approver. Go-live requires a separate operational decision based on those results and the remaining dependencies.
This checklist covers technical acceptance. The wider go-live readiness guide covers staffing, counterparties, scope and handover. Neither checklist authorises live payments, production data changes or bypassing mandatory controls.
Freeze the acceptance baseline
Record the release version, configuration, products, channels, locales and interface contracts under test. Distinguish available functions from planned custom work. Each test needs prerequisites, starting state, permitted synthetic fixtures, steps, expected business outcome and evidence references.
Write measurable criteria rather than “works as expected”. For example: replaying an accepted purchase produces no second ticket or financial posting; an account from another brand cannot access the tested record; a result correction leaves an auditable adjustment. Define the required behaviour against the actual contract, not an assumed WhiteLotto endpoint.
Test complete journeys and controlled failure
| Journey | Cases to cover | Evidence |
|---|---|---|
| Account and verification | Approval, rejection, resubmission, manual review and changed decision. | Provider outcome, account permissions and audit trail. |
| Funding and withdrawal | Success, decline, pending state, delayed webhook, refund and uncertain response. | Provider reference, one intended ledger effect and reconciliation. |
| Ticket purchase | Valid order, invalid selection, cut-off, duplicate request and lost confirmation. | Ticket identity, draw reference and final financial state. |
| Results and settlement | Missing, preliminary, final and corrected results. | Versioned result, settlement trace and owned exceptions. |
| Retail channel | Network loss, printer failure, device restart and reprint. | POS and central records with no duplicate issuance. |
| Access and controls | Unauthorised role, other-brand resource, revoked device/client and configured account restrictions. | Denied actions and safe error handling. |
| Operations | Provider outage, recovery, support investigation and finance export. | Working alert, assigned owner and usable recovery evidence. |
Use the focused guides for payments, KYC and draw/results interfaces to specify those cases. The OWASP business-logic testing guidance helps frame misuse and timing tests; a checklist is not evidence that a release passed them.
Judge the resulting records, not only the screen
A browser message can look correct while a duplicate wallet entry exists. Capture the relevant ticket, provider and ledger references using permitted test data. Confirm customer communication, staff access and finance reports as part of the same journey.
Test each supported locale and meaningful device/channel combination. A translated menu does not prove that verification errors, receipts, draw time displays or support messages are understandable. Record the configurations covered and identify untested variations explicitly.
Separate blockers from accepted follow-up work
Agree severity and decision authority before execution. Defects affecting funds, valid tickets, access boundaries, required controls or reliable recovery should not be renamed cosmetic issues because a campaign date is near. Retest the affected journey after a fix; do not automatically repeat unaffected checks without a reason.
For a non-blocking item, record the impact, compensating measure, named owner, authorised acceptance and due date. A PASS without a test result is not a pass. A passed laboratory case is not a guarantee of future uptime or commercial performance.
Define pause, rollback and data recovery separately
A previous software version may be safe to restore, but purchases, ledger postings and database migrations are not automatically reversed with it. Specify which conditions trigger a pause, who can decide, which version is recoverable and how unresolved operations are preserved and reconciled.
The NIST contingency planning guide is a reference for recovery planning and validation. Use it as background, not as a claim that a platform is certified or that a particular restore procedure has been tested.
Complete the go/no-go and handover pack
- Exact tested release/configuration and accepted scope.
- Completed test matrix, evidence and unresolved defect register.
- External dependencies, mandatory gates and correctly authorised residual risks.
- Monitoring owners, on-duty contacts and customer communication templates.
- Pause authority, safe rollback steps and data-recovery responsibilities.
- Support/finance access, runbooks and the post-launch review schedule.
Bring the matrix into your provider evaluation before signing the delivery scope. Acceptance requirements agreed late can become unbudgeted integration work.
Lottery UAT FAQ
Is a supplier demo UAT?
No. A demo shows selected functions; acceptance tests the agreed configuration, business outcomes and failure behaviour with recorded evidence.
Does a successful rollback erase transactions?
No. Code recovery and transaction/data recovery are different procedures. Preserve and reconcile live records under an authorised plan.
Bring your acceptance priorities and delivery dependencies to WhiteLotto. CONTACT.