Lottery Platform Demo Checklist: What Operators Should Verify

Use it to assess any provider against your operating requirements. These are questions to verify, not claims that every feature is included in WhiteLotto or any other product. Begin with the lottery platform overview, then agree which capabilities and responsibilities your proposed configuration must cover.

1. Prepare a controlled demo agenda

Send your critical scenarios in advance. Include operations, finance, support and a technical representative, rather than evaluating the platform solely through a sales presentation. Ask the provider to identify the software version, enabled modules, integrations and limitations of the demonstration environment.

Use synthetic player identities, test documents, sandbox payments and isolated draw data. Never request production credentials, real player records, live payments or changes to operational systems. Agree what can be recorded, who can receive exports and how test material will be removed afterwards.

For each scenario, record the expected result, evidence requested, owner and unresolved dependency. Bring your go-live checklist so demonstration gaps become explicit launch conditions, not assumptions.

2. Follow a ticket through the complete player journey

Ask the demonstrator to use one synthetic player and one test transaction throughout. Switching between unrelated screenshots makes it harder to connect customer experience with operational records.

1. Registration: show validation, the applicable age-check workflow, account status and separately recorded consent choices. Distinguish mandatory acknowledgements from optional marketing consent.
2. Verification: open a synthetic KYC case, show its decision history and explain which verification service and operator policies determine the outcome.
3. Funding: initiate a sandbox payment and inspect pending, successful and failed states. Follow the payment reference into the wallet ledger.
4. Purchase: select a test draw, confirm the ticket, inspect the purchase reference and show the wallet movement. Ask how cutoff times and duplicate submissions are handled.
5. Results and settlement: load controlled test results, identify the result source and follow settlement into player history, wallet entries and reporting. Ask how corrections are approved and recorded.

Explain whether the model involves lottery tickets, a courier arrangement, betting on results or operator-run draws. Similar-looking screens do not establish identical transaction ownership or market permissions.

3. Test failures, restrictions and support escalation

Choose several relevant exceptions rather than asking for an unlimited improvisation session. For each, inspect both the player message and the administrative outcome.

• Interrupted payment: simulate a timeout or delayed callback. Does the transaction remain traceable, and can support establish whether funds were credited?
• Repeated notification: demonstrate how duplicate integration messages are identified without creating an extra wallet movement or ticket.
• Verification mismatch: route a synthetic case for review, show the permitted account state and demonstrate who can approve or reject it.
• Responsible-gaming restriction: apply an agreed test limit or self-exclusion state and check its effect on login, purchase and communications. Establish the scope across brands and channels where relevant.
• Disputed transaction: open a support case, reconstruct events and show how finance or compliance receives an escalation without exposing unnecessary personal data.

Do not treat a configurable control as proof that the proposed settings satisfy a particular jurisdiction. Market-specific requirements need separate review.

4. Inspect the back office, reporting and reconciliation

Ask someone to navigate the administrative tools live. Follow the test ticket into an operational report and reconcile its payment, purchase, wallet and settlement references. Confirm how time zones, currencies, fees, reversals and adjustments are represented.

Export a small synthetic dataset and compare it with the screen totals. Request field definitions, filters and an explanation of report refresh times. If the operator needs accounting or regulatory extracts, identify the required format and who owns its implementation.

Show how a support agent investigates a case, how promotions or draw settings receive approval, and where changes are logged. Include localization: inspect editable language strings, currency display and a real translated journey rather than a language-selector mockup. A busy dashboard alone does not demonstrate these workflows.

5. Verify access controls and security evidence

Use separate synthetic support and administrator accounts to demonstrate role-based access control. Ask the provider to show an allowed action, a denied action and its audit trail. Check who can adjust balances, export records, change settings and grant privileges; record how elevated access is approved and removed.

The OWASP Application Security Verification Standard provides a basis for specifying and verifying application security requirements. It can help structure requests for evidence about access control, authentication and logging. Reference the applicable version and assessment scope rather than using a vague “OWASP compliant” label.

A demo is not a penetration test or certification. Request relevant assessment reports, remediation status and operating responsibilities separately using the security, uptime and SLA checklist. Establish which evidence can be shared confidentially before contracting.

6. Separate available capabilities from implementation promises

Mark each item as standard in the proposed release, configuration-dependent, an optional module, custom development or roadmap. Label prerecorded footage and prototype screens explicitly. A sandbox demonstration shows behaviour in that environment; it does not establish production capacity, availability or regulatory approval.

For white label and turnkey lottery deployments, document who manages hosting, player support, payments, KYC decisions, draw or ticket fulfilment, incident response and reporting. Model names alone do not define this split.

For each external integration, identify the provider, contract owner, sandbox limitations and production activation conditions. Capture recurring charges, implementation work and acceptance dependencies in your platform pricing and total-cost assessment.

7. Score evidence and agree acceptance criteria

Apply the same rubric to every critical scenario. Record observations rather than awarding points for presentation quality. This is a suggested procurement tool, not an industry certification or a vendor ranking.

Keep must-have blockers separate from aggregate scores. A missing reconciliation or access-control requirement cannot be offset by several attractive screens. Add gaps, accountable owners and due dates to your provider evaluation and RFP checklist.

Lottery platform demo FAQ

Is a prerecorded demo enough?

It can introduce the product, but it should not replace controlled navigation through your critical scenarios. Identify what is recorded, what is available now and what requires further implementation.

Should we test with real money or customer data?

No. Use agreed synthetic data and sandbox integrations. Production readiness and security testing need a separately authorized scope; a sales demo does not provide that authorization.

What should we receive after the session?

Request an evidence log, proposed responsibility split, unresolved dependencies and acceptance criteria. For your next step, discuss your operating model and demo requirements with WhiteLotto, including the market, integrations and workflows you need to verify.

Editorial update, 5 October 2026: expanded with a controlled demo script, exception checks, an evidence rubric and implementation handoff criteria.