Begin with your target markets, lottery products, existing systems and operating team. An established operator adding a lottery vertical has different requirements from a founder building a new brand or an institutional lottery replacing legacy technology. The proposed configuration should explain which capabilities are included, optional, supplied by third parties or developed for your project.
Lottery platform feature and module matrix
Use this matrix as a working specification, not as an assumption that every module belongs to every package. For each row, identify the system of record, operational owner and acceptance test. The provider evaluation checklist turns these requirements into procurement questions.
| Module | Operating task | What to demonstrate |
|---|---|---|
| Lottery catalogue and tickets | Present permitted products, purchase rules, draw cut-offs, results and settlement. | Follow one entry from selection to confirmation, result and an exception. |
| Player accounts and controls | Manage registration, account access, verification decisions and player restrictions. | Show eligibility checks, an unresolved verification case and staff permissions. |
| Wallet and payments | Record balances, deposits, withdrawals and reconciliation with payment services. | Show a failed request, duplicate notification and the authoritative transaction record. |
| CRM and affiliates | Organise permitted communications, attribution, campaign approvals and commissions. | Follow a consented campaign and explain reporting and approval ownership. |
| Back office and reporting | Support daily operations, finance exports, staff roles and audit review. | Trace a report total to the underlying records and demonstrate restricted access. |
| Brand and localisation | Configure player journeys, content, languages, currencies and time zones. | Review a mobile purchase and support journey in each launch language. |
| Integration and AI workflows | Connect the agreed systems and organise the data used by automation. | Explain data flows, failure handling, access limits and human review. |
The Powerball expansion analysis provides a market-entry example to discuss; catalogue availability and permissions still need their own assessment.
See an end-to-end journey, including failure
A useful demonstration follows registration, eligibility, funding, product selection, purchase confirmation, results and settlement. It also shows the staff view: the support record, financial reconciliation and the decision history. Attractive screens matter, but operations need continuity when one step fails.
Example: payment near a draw cut-off
Ask what happens when a customer initiates payment before the cut-off but confirmation arrives afterwards. Which timestamp determines acceptance? Is an entry actually created? How is the customer informed, and who resolves an unmatched payment? This is an illustrative acceptance scenario, not a promise about a particular payment provider or jurisdiction. Put the agreed behaviour into the delivery scope.
Choose White Label or Turnkey by responsibility
Both models can support a branded player experience. The important differences concern the operating entity, administrative control, third-party contracts, support duties and change process. Start with our White Label versus Turnkey comparison, then review the Turnkey lottery solution against your team and existing technology.
Create a responsibility schedule covering configuration, payment exceptions, verification decisions, customer support, reconciliation and incident escalation. Name an owner and approver for each task. Software delivery does not itself determine your permission to operate, the approved product offering or the responsibilities attached to a licence.
Define integration and data boundaries
For each interface, agree the participating systems, required records, access method, timing, failure handling and reconciliation owner. An API connection still needs a feasible specification and acceptance criteria. Explore the lottery API integration guide to structure that technical discussion without sharing player records or credentials in an initial enquiry.
For a migration, identify the authoritative balances and histories, permitted export formats and unresolved discrepancies that would prevent cut-over. Agree data access, retention responsibilities and transition assistance. WhiteLotto’s AI platform presentation introduces analytics, communication, content and support workflows; discuss the data and review boundaries of the configuration you want to demonstrate.
Connect scope, price and launch readiness
Separate standard configuration from custom development and external service onboarding. Request a proposal showing one-off work, recurring platform charges, usage dependencies and support boundaries. Do not compare headline fees while ignoring payment, verification, infrastructure or migration work.
Agree representative screens, example reports, interface documentation and acceptance checks before committing to a delivery date. Use the security and SLA checklist for service questions. A launch timeline depends on the agreed scope, approvals, integrations and operational readiness.
LMS, PAM and wallet: separate the operating responsibilities
Lottery management software is not one interchangeable module. The LMS coordinates lottery operations; player account management (PAM) manages the account and its permitted actions; the wallet records money movements. A CRM uses permitted events to organise communication. Define these boundaries before deciding which systems to keep, replace or connect.
| Component | Responsibility to define | Acceptance evidence |
|---|---|---|
| LMS / lottery operations | Catalogue, ticket state, draw cut-off, results and settlement workflow. | Trace an accepted ticket through a result and a correction. |
| PAM / player account | Identity, account status, access and restrictions shared across channels. | A restricted account is handled consistently at every entry point. |
| Wallet / ledger | Authoritative balances and separately identifiable financial entries. | Reconcile a purchase, refund and payout to their original references. |
| CRM / communication | Eligible audiences, consent, triggers and stop conditions. | A completed purchase suppresses an obsolete reminder. |
Treat this as a responsibility map, not a list of separately sold WhiteLotto products. One platform can combine several components, while an established operator may retain a system it already uses. For every handoff, name the system of record, the operational owner and the test that proves the integration works.
Full platform or selected modules?
Compare the work retained by your team, not only the number of features. If multiple brands are involved, specify which data, roles, configurations and balances are shared or isolated. Put those boundaries in the proposal and acceptance scope. A retailer’s physical scratch-card inventory system is a different requirement from operating an online lottery platform.
Review the wallet and reconciliation checklist, lottery CRM and retention guide, API integration requirements. CONTACT.
Specify the operating boundaries of a multi-brand lottery platform
A multi-brand lottery platform should be evaluated as an operating model, not simply a collection of branded front ends. List the brands, their operating owners and the services they may share. Then define which decisions remain brand-specific: product availability, currencies, draw calendars, campaign rules, staff access and reporting. A shared service does not remove the need for a separately approved configuration.
Distinguish a shared player identity from a shared balance or financial liability. The player account management guide helps frame identity and permissions; the wallet reconciliation checklist addresses the accounting boundary. State whether cross-brand movements are prohibited or permitted under defined approval and recording rules. Do not let a common login silently decide this policy.
Put shared and brand-specific controls in the procurement matrix
Ask each proposal to identify the scope, decision owner and acceptance evidence for every shared control. The matrix below describes buyer requirements, not assumed platform capabilities. Include access and export rights from the data ownership and exit checklist, especially where one administration team serves several brands.
| Boundary | Scope decision | Acceptance evidence |
|---|---|---|
| Configuration | Shared defaults versus approved brand overrides | Change affects only its declared brands |
| Staff permissions | Brand roles and explicitly authorised group roles | Brand A user cannot access brand B records |
| Balances and liabilities | Separate ledgers and any permitted transfers | Entries retain brand, reference and approval |
| Reporting | Brand totals and controlled group aggregation | Group report reconciles to its brand totals |
| Migration and closure | Open tickets, records and continuing obligations | One brand changes without losing another’s records |
Accept brand changes without obscuring the rest of the portfolio
Adding, migrating or closing a brand needs an explicit record of affected configurations and outstanding items. Preserve historical brand references when names or identifiers change. Agree who resolves open tickets, payment exceptions and support cases, and what remains available after closure. Use the platform migration guide to structure that handover.
In the UAT acceptance plan, test a brand-scoped change, an unauthorised access attempt and a reconciliation mismatch. Record who may approve shared changes and how unaffected brands are protected. Use CONTACT to discuss your portfolio boundaries and the evidence needed for procurement.
Frequently asked questions
Can we keep an existing player account or wallet?
Include it in the initial architecture brief. The interface, ownership of balances and reconciliation process determine the integration scope.
Are all modules included in one price?
The proposal should identify included modules, options, third-party charges and project-specific work. The matrix helps you request that breakdown.
What should we bring to a first call?
Your company, role, markets, product model, licence status, existing systems and intended launch window. Describe requirements; do not send confidential customer data.