Separate the PAM, wallet, content and sportsbook decisions.
Test failure and migration scenarios before commercial selection.
Keep evidence gaps visible in the shortlist.
Define the platform boundary
A platform proposal can bundle player accounts, a wallet, content distribution, payments, sportsbook services and a front end. Buying them together is a different decision from replacing one layer. Draw the current and proposed operating models before requesting a demonstration. Mark the systems you will retain, the supplier-controlled services and every hand-off between them.
Which systems are being replaced, retained or introduced?
Who owns the wallet ledger, player record and customer-facing experience?
Use the same scenarios in every demonstration
Public platform documentation illustrates capabilities, not proof that your configuration is ready. Turn the requirements into a short acceptance script: create an account, apply a limit, reject a duplicate payment, reconcile a balance and resolve a failed game round. Record the result, dependency and responsible team for each scenario. Ask to see the operator console as well as the player experience.
Can support explain a disputed balance from one auditable transaction history?
Which controls require another product, configuration or integration?
Identify integration work hidden behind the API
An API is an interface, not a delivery plan. Ask for a sandbox, authentication model, versioning policy, rate limits and an example error catalogue. Request a dependency schedule with named owners for platform, wallet, payment and front-end work. Keep vendor engineering effort separate from work your own team or another supplier must deliver.
What changes when an existing payment or content partner is retained?
How are schema changes announced, tested and rolled back?
Treat migration as its own workstream
Prepare an inventory of player records, balances, account restrictions, bonus states and reporting history before discussing a cut-over date. Agree how opening and closing totals will be reconciled, which records cannot move, and what evidence authorises the switch. Rehearse a failed cut-over. A rollback plan must describe what happens to transactions accepted during the migration window.
Who signs off the migration reconciliation and exceptions?
What is the recovery plan if the new service fails after cut-over?
Compare the cost of operating and leaving
Build a common cost sheet covering initial delivery, recurring services, transaction or revenue-linked charges, third-party contracts and internal staffing. Separate quoted prices from assumptions. Ask for sample exports and an exit process before signing. For service levels, define the measurement point, severity criteria, escalation owner and recovery evidence rather than accepting an uptime percentage on its own.
Which costs change with volume, new markets or new brands?
Can the operator export usable data without buying an additional service?
Turn the research into a qualified brief
Send each candidate the same market list, current architecture, required capabilities, launch window and unresolved questions. Ask for a supported, unsupported or subject-to-review response for every requirement. The companies below illustrate different procurement routes; they are not a ranked recommendation. Product availability and regulatory suitability need confirmation for the exact contracting entity and deployment.
Continue the research
Company evidence, not a paid ranking.
These profiles illustrate different products and operating models. Confirm the exact market, service and contract fit before treating any company as a qualified candidate.
EveryMatrix
Consider EveryMatrix when evaluating a platform migration or a modular casino or sportsbook addition that must connect to existing operational systems.
Read the company evidence
SOFTSWISS
Consider SOFTSWISS when comparing an integrated operating stack with individual casino, sportsbook or aggregation modules for an existing business.
Read the company evidence
Playtech
Consider Playtech when evaluating a multi-product platform requirement in which player accounts, wallet operation, content and safer-gambling tooling must be assessed together.
Read the company evidence
Kambi
Consider Kambi when deciding between an end-to-end sportsbook partnership and an odds-feed component for an operator-controlled platform.
Read the company evidencePut the questions to work
Build a more useful shortlist.
Start with this guide’s ready-to-edit brief in Pulse. Add your company, markets and non-negotiable requirements. Nothing is sent until you review and submit the form.
Prepare a private briefSources and scope
Product documentation supports the capability examples. Procurement questions and assessments are IGW³ editorial analysis, not supplier endorsements. Sources reviewed 2026-09-22; check the linked originals for later changes.
EveryMatrix Platform: account, wallet and API capabilitiesEveryMatrix Casino: modular integration contextSOFTSWISS: product and deployment optionsCompare the same requirements across suppliers and record evidence, tests and unresolved gaps. The editable workbook starts with no supplier results or approvals.
Get the free supplier evaluation worksheetThis educational guide is independent, free to access and designed as a practical starting point. Regulatory and legal requirements should always be confirmed with the relevant authority and qualified advisers.
Our evidence methodology