For the full sportsbook product and trading configuration, see sportsbook software. This page addresses the work required to connect it.
Choose the interface work your team will own
| Pattern | Work to define |
|---|---|
| Embedded front end | Supplied interface, theming limits, authentication, account context, wallet and event reporting |
| API with your front end | Catalog presentation, live updates, betslip, placement states, history and relevant mobile journeys, alongside the integration |
An embedded interface can reduce front-end work, but it does not remove the account and financial integration. An API gives your team more responsibility for the experience and its failure states. Compare the actual supported journeys rather than assuming either option is immediate or unlimited.
Agree the bet and transaction contract
Document the identifiers that connect the placement request, accepted bet, wallet event and settlement. Specify the state returned for acceptance, rejection and an outcome that is still being resolved.
When a placement response times out, the interface must not guess whether the bet stands. Define how to recover the authoritative status and reconcile any reserved or debited funds. Repeating a request needs documented behavior that prevents an unintended second bet or financial action.
Keep the result of the original request and later corrections inspectable. Exact timeout, retry, signing and rate-limit rules belong in the versioned API contract.
Test the changing conditions of live betting
| Case | Acceptance evidence |
|---|---|
| Price changes before acceptance | The applied price-change policy, accepted price or rejection, and corresponding wallet result |
| Market suspends during placement | The authoritative acceptance decision and explained financial state |
| Response is lost | Recovery of the original request status without a second uncontrolled action |
| Cash-out quote expires | Clear distinction between a displayed quote and a completed execution |
| Result is corrected | Original settlement, adjustment and final balance reconcile |
| Account becomes restricted | The permitted action reflects the agreed account-state controls |
Use the required products and currencies in the test set. A successful single bet does not establish that multiple bets, partial cash-out or corrected results behave correctly.
Include reporting and support in the handoff
Define how the operator retrieves bet history, financial events and unresolved cases. Assign ownership when the interface, sportsbook and wallet report different states. Retain the documentation version and test results accepted for release.
Estimate the schedule from the existing wallet, front-end work, supplier approvals and engineering capacity. A generic time estimate cannot account for changes the ledger needs to record the required events.
Request documentation for your proposed integration with the current platform, wallet, target markets and interface approach. Include one difficult placement or settlement case you need to handle reliably.