For a complete new business, compare white label and turnkey. For a sportsbook inside an existing platform, review the API integration.
Follow one bet through the platform
Start with the event, market and selection shown to the player. The placement request must preserve the relevant price and rule context. Acceptance then needs to agree with the wallet and risk decision; a request sent by the interface is not proof that the bet was accepted.
At settlement, trace the result source and rule applied to the position. If the result is corrected, retain the original settlement and the adjustment so the final player balance can be explained. The same identifiers should support the player view, support investigation and financial report.
Ask for this walkthrough in the configuration you intend to buy. A screen showing prices and a balance does not demonstrate reconciliation between them.
Compare functions against the actual launch catalog
| Function | Question for the demonstration |
|---|---|
| Pre-match and in-play | Which priority competitions and markets are supported, and when are they suspended? |
| Singles, multiples and systems | How do rejected selections, void legs and revised results affect the remaining bet? |
| Bet builder | Which combinations are permitted for the relevant fixtures and supplier? |
| Cash-out | When may an offer change or disappear, and what proves that acceptance completed? |
| Risk controls | Which roles may change limits, override a rule or approve manual settlement? |
| Shared player account | How do verification, limits and exclusions reach every connected product? |
| Streaming and trackers | Which rights, territories and interfaces are included in the proposed service? |
Agree any supplier or market restrictions alongside the relevant feature. A catalog total cannot answer whether your most important competition is covered.
Choose the front-end boundary
An embedded sportsbook can reduce the interface work your team owns, while leaving integration, account state and event reporting to be agreed. An API gives your team more responsibility for the player journey, including price changes, delayed responses and errors.
Choose according to the experience you need to control and the engineering capacity available to maintain it. Ask which promotions, analytics events, authentication flows and mobile journeys each option supports. The integration model guide provides a comparison brief.
Separate planned margin from realized hold
The margin implied by offered prices and the result after settled bets are different measures. Realized hold is commonly calculated as gross gaming revenue divided by settled stakes for a defined period. For example, €50,000 of GGR on €1,000,000 of settled stakes is 5%, before any costs excluded from that GGR definition.
Use consistent rules for voids, unsettled positions, promotions and currency conversion when comparing reports. A change in hold can reflect results, bet mix, promotions or operational problems. A platform feature alone does not establish the cause or guarantee a particular margin.
Rehearse interruptions before choosing the configuration
Test a price change during placement, an uncertain response after funds are reserved, a feed interruption and a corrected result. Establish the expected player message, market state, wallet record and staff action for each scenario.
If a secondary feed is proposed, test event mapping and recovery rather than assuming every market can switch automatically. Existing bets still need to settle under their applicable rules and result source.
Request a configuration demonstration with your markets, priority competitions, current wallet and preferred trading model. Include the failure scenarios that your team must be able to investigate.