This buyer’s comparison explains how to build a shortlist, what the named providers publicly describe and how to test a proposal. It is not a league table or an independent product test. WhiteLotto is included as the publisher’s own platform, alongside other providers with official lottery offerings.
Define the project before the shortlist
Write a one-page brief covering your markets, permitted product model, licence status, player account and wallet, payment dependencies, languages and operating responsibilities. Decide whether you need managed delivery, your own operator-controlled environment, individual modules or an institutional modernisation programme.
Use the White Label versus Turnkey comparison to separate delivery labels from contractual responsibility. For a new operation, the lottery business launch guide helps organise the decisions that precede software selection.
Lottery software providers: public offering profiles
These profiles summarise the linked provider pages, not an assessment of implementation quality. The list is not exhaustive and the order is not a ranking. Ask each provider to confirm the current scope for your project; public descriptions do not establish commercial terms or market approval.
| Provider | Public offering focus | Question to take into discovery |
|---|---|---|
| WhiteLotto | Lottery-first platform conversations spanning branded delivery, operating modules and AI workflows. | Which modules and responsibilities belong to our White Label or Turnkey scope? |
| iLotto | A managed white-label lottery offering with brand customisation and access to lottery jackpots. | How are the managed service, product arrangements and operational hand-offs defined? |
| GammaStack | Turnkey lottery development covering tickets, draws, player accounts, payments and retail management. | What is standard configuration, what is bespoke development and who operates it? |
| Digient | White-label lottery software with branded player experiences, back-office functions and integration services. | Which services are managed and which remain with the operator or external suppliers? |
| EveryMatrix | Turnkey and modular technology for national and state-owned lotteries, including digital and omnichannel modernisation. | How will the proposed scope connect to existing institutional and retail systems? |
| Allwyn Lottery Solutions | A portfolio covering iLottery platforms, engagement, data insights, games and digital applications. | Which components, interfaces and delivery responsibilities are included in the proposal? |
Evaluate the same six dimensions
- Operating fit: match products, channels and licensing responsibilities to your intended operation.
- Player and financial journeys: test registration, verification, payments, tickets, settlement and reconciliation.
- Architecture: define existing-system interfaces, data ownership, export formats and dependency management.
- Daily operation: examine staff roles, support escalation, reporting and changes to configuration.
- Delivery and service: agree acceptance criteria, launch dependencies, incident handling and contractual service commitments.
- Commercial fit: compare implementation, recurring charges, external services, change requests and exit assistance.
The provider evaluation checklist provides a deeper RFP structure. Keep mandatory requirements separate from preferences: a strong aggregate score should not hide a failed requirement.
Example: a transparent scoring model
For an illustrative operator adding lottery to an existing business, allocate 30% to operating fit, 25% to integration, 20% to financial controls, 15% to service and 10% to commercial fit. Score each category from 0 to 5 against demonstrated evidence, then calculate a weighted result. These weights are an example, not scores assigned to the providers above.
Record unanswered questions rather than guessing a score. Define non-negotiable gates such as a workable account interface, agreed reconciliation or an acceptable data export. Have commercial, technical and operational stakeholders review the same evidence.
Run the same demonstration with every shortlisted provider
Ask each supplier to show a mobile purchase, delayed payment confirmation, verification exception, support escalation and report reconciliation. Include your languages and intended product model. A slide saying “API” or “AI” is not a substitute for explaining inputs, outputs, permissions and operational handling.
Review the security and SLA checklist, then compare complete proposals rather than unquoted prices. Clarify what happens when you change a payment service, add a market, migrate data or end the contract. Support arrangements and exit work can materially change the scope.
Trace each proposal claim to delivery evidence
A useful lottery software comparison records what is available for the proposed release, what must change and what remains unresolved. Use the same requirement identifiers in your brief, proposal, demonstration notes and acceptance plan. A proposed function and a demonstrated function should not receive the same evidence status simply because both appear in a feature list.
Ask each shortlisted supplier to classify every required deliverable using the following matrix. Keep scope status separate from evaluation score: a configurable function may fit well, while a delivered function may not meet your workflow. The provider evaluation checklist supplies the wider purchasing structure.
| Delivery status | Clarify in the proposal | Evidence to attach |
|---|---|---|
| Delivered capability | Which version, environment and workflow were shown; differences from your intended release. | A demonstration reference tied to the requirement and observed outcome. |
| Configuration required | Settings, configuration owner and approval needed to meet the requirement. | The proposed configuration and a plan to test it before acceptance. |
| Custom work proposed | Specification, delivery dependency, acceptance owner and change process. | An agreed deliverable and test criteria, with completion still recorded as outstanding. |
| Third-party dependency | External service, contracting party, onboarding condition and failure responsibility. | Confirmed dependency scope and the required integration-test evidence. |
| Excluded or deferred | The omitted requirement and any resulting operating limitation. | A written exclusion and a buyer decision about its impact on the release. |
Record the demonstration’s operating context
For each demonstrated requirement, record a stable reference to the walkthrough, date, environment, product version and configuration. State whether a payment, ticket source or result feed is real test integration, simulated or presented only in slides. Use synthetic records; procurement notes do not require player data or credentials.
- Record the input, expected result and observed account, ticket or transaction state.
- Identify who performed the action and which permissions were used.
- Link the normal path and error path to the same requirement; record unresolved outcomes explicitly.
- Ask what must be repeated when your configuration or external dependency is substituted.
The API integration guide helps define system boundaries. Turn the resulting evidence into release-specific checks through the UAT acceptance checklist, rather than treating a sales demonstration as completed acceptance testing.
Compare equal scope and keep a decision log
Normalise proposals to the same products, languages, integrations, operational responsibilities and release assumptions. Show excluded work and external dependencies beside included fees. Ask how configuration changes, new interfaces, supplier onboarding and exit assistance are charged and approved. Use the pricing and TCO guide to compare the same scenario, not unmatched headline prices.
For each open requirement, record its evidence reference, owner, missing answer, effect on launch and the decision needed. Distinguish “awaiting evidence” from “not suitable”; neither deserves an invented score. Include the date, reviewers and rationale when a requirement is accepted, deferred or made a condition of the agreement.
Keep data access and exit arrangements and security and service evidence visible in that log. Bring your requirement matrix and unresolved decisions to CONTACT for a scope-specific WhiteLotto conversation using the same evidence standard as your other shortlisted suppliers.
Frequently asked questions
Is there one best lottery software provider for everyone?
No universal shortlist fits every operating model. Use mandatory requirements and the same demonstrated scenarios to choose the right fit.
Should the lowest headline price win?
Compare the full proposed scope and ongoing dependencies. A headline price alone cannot show the cost of integration, operations or future changes.
Where does WhiteLotto fit?
Evaluate its lottery-first platform and Turnkey delivery against your requirements, using the same criteria as other suppliers.
Wojciech Lysak is Managing Director of White Lotto and a senior iGaming B2B expert with nearly 20 years of experience. He specializes in white label online lottery platforms, turnkey solutions, gaming systems, and scalable B2B solutions for operators across global markets.
A recognized industry leader and visionary, he actively participates in major iGaming events worldwide and has led the creation of multiple successful platforms and projects across the gaming sector.
If you’re interested in starting your own online business in the iGaming sector, Wojciech will help you take your first steps on the path to success. LinkedIn