Sportsbook Software Development: Core Systems, Integrations and Delivery

A sportsbook must answer a deceptively simple question: what exactly did the customer buy when they placed a bet? The answer includes the selection, stake, currency, accepted odds and applicable rules. It also includes evidence that funds were committed and that the platform can later calculate, explain and, when necessary, correct the return.

A fast betting screen does not establish any of that by itself. The difficult work sits between changing sports data, the acceptance decision, trading controls and money movements. This guide explains how to divide that work, what to demand from integrations and which behaviours to prove before launch. It is aimed at product owners and engineering teams building an operator sportsbook; an exchange or a pooled-betting product needs a different acceptance and exposure model.

Decide who owns the betting decisions

Start with a map of decisions rather than a list of services. Which system decides whether a market is open? Who sets the offered price and stake limits? Who can finally accept a ticket? Which ledger owns the customer's funds? Who interprets results and authorises a correction? Each decision needs an authoritative owner, even if several systems contribute information.

A managed sportsbook may delegate trading and ticket acceptance to a supplier while retaining the operator's account and wallet. A more independent model may buy sports data but own pricing, exposure and acceptance. Neither arrangement removes the need to trace a ticket across organisational boundaries. An odds feed and a ticket-acceptance service have different responsibilities; buying the first does not automatically provide the second.

Translate that map into a first-release scope: named sports and markets, supported currencies, singles or accumulators, prematch or in-play, and the handling of cancellations and disputed results. Features such as cash-out and bonuses introduce additional monetary rules. Include them when their operation is understood, rather than treating them as simple interface additions. The broader product decisions are discussed in sportsbook product development.

Make the wallet part of acceptance

The displayed balance is not a concurrency control. Two simultaneous bet requests can both see enough money and spend it twice unless the authoritative wallet serialises the competing commitments. Define available funds, reserved funds and committed stakes explicitly, including how cash and bonus balances interact if bonuses are supported.

In a single transactional system, the stake commitment and accepted ticket may be recorded together. With a remote wallet or acceptance provider, the same result requires a durable protocol: reserve funds, record the pending request, obtain the authoritative decision and complete or release the reservation. The exact order depends on the contracts involved. Prove that acceptance cannot leave an unfunded ticket and that a failed hand-off cannot create an unexplained debit.

An expired HTTP request is not proof that a bet was rejected. If a supplier may have accepted the ticket, retain a recoverable pending state and resolve it through status lookup or reconciliation. Do not release its funds merely because a local timer elapsed, unless an authoritative rejection or cancellation establishes that the ticket was not accepted and cannot still be accepted. Every financial operation needs a stable identity and a link to the ticket. See wallet and transaction-ledger design for the underlying money model.

Turn feed messages into a coherent betting offer

Model a selection with enough information to identify what was offered: provider and event, market type, the market's parameters, outcome and current trading state. A total of 2.5 goals and a total of 3.5 goals are different markets even when they share a market-type identifier. Keep supplier identifiers alongside the internal mapping so that a result or recovery message reaches the correct selection.

Read the actual update contract. For example, Sportradar's UOF odds-change documentation states that a message can cover only some markets; omitted markets remain unchanged. Treating every message as a complete replacement would erase valid offers.

Store both source timing and local processing evidence. Receiving a message now does not mean it was produced now. A healthy connection also does not prove that every event has usable odds. Admission checks should consider the relevant producer, market and outcome state, freshness policy and whether the data has been applied successfully.

Give the customer-facing offer an internal version that can be recorded on a ticket. It need not be the supplier's timestamp. Preserve the actual accepted price and selection parameters, not just a pointer to mutable current odds. After a goal, a line change or a provider switch, the old ticket still needs an intelligible record of its original terms.

Define what it means to accept a bet

Write the acceptance contract before implementing the placement endpoint. A request should identify the customer, selection, stake, currency, expected offer and the customer's permitted treatment of price changes. Use a stable request key so that retransmission resolves the existing request instead of creating another ticket. Reusing the key with different contents must produce a clear conflict, not a second interpretation of the first bet.

At the authoritative decision point, check account eligibility, current offer state, applicable limits and the ability to commit funds. Checks separated by network calls can become stale. Protect the final decision with the concurrency mechanism supported by the architecture; having validated a price earlier in the journey is insufficient.

Consider a customer requesting odds of 2.50 when the current offer has moved to 2.30. If the chosen policy forbids accepting a lower price, return a rejection or a new offer requiring consent. If the product supports a different price-change preference, record that preference and enforce its precise meaning. A timeout must not silently turn either case into a new bet at new odds.

The accepted receipt should show the authoritative ticket identifier, accepted odds and stake, with a reference to the terms used. Pending, rejected and accepted are different customer outcomes. Make them visible in history and support tooling. A duplicate submission should resolve the existing request, while a deliberate new bet should receive a new identity.

Control exposure before the next stake arrives

Trading decisions become software rules when they affect admission. Define where limits apply: customer, outcome, market, event, sport or a correlated group of selections. State whether a limit measures stake, potential return or another exposure measure. Summing stakes alone cannot reveal how much would be payable if one heavily backed outcome wins.

Competing requests must reserve the relevant risk capacity as well as funds when the design allows pending acceptance. Otherwise two requests can independently pass the same remaining limit. When a request is rejected or conclusively abandoned, release its pending exposure exactly once. Reconciliation should find both accepted tickets missing from the exposure calculation and reservations with no live request.

Simple singles are a useful starting point. Accumulators, related selections, each-way bets and cash-out require additional modelling; a collection of individually acceptable legs is not automatically an acceptable combined ticket. Choose the supported combinations explicitly and reject unsupported ones with a clear explanation.

Operators also need controlled intervention. A trader should be able to suspend an affected market and inspect the resulting pending requests. Record who changed a limit or price, why, when it became effective and which decisions used it. A manual adjustment should enter the normal decision path; an undocumented database edit leaves the next operator unable to explain what happened.

Settle tickets without erasing their history

Settlement starts with an accepted ticket, the relevant result evidence and the applicable market rules. Evaluate the ticket's original selection and price, not today's offer. An event-level result is not enough for every market: full-time, first-half and player-specific selections can require different evidence.

Provider result messages also have their own semantics. UOF settlement documentation distinguishes early and officially confirmed results and leaves ticket evaluation to the system integrating the feed. Its rollback message can undo an erroneous settlement, including at outcome level. Specify which evidence your product uses and how a later correction is authorised.

A hypothetical single illustrates the accounting. Assume a stake of 10 currency units at decimal odds of 2.50, no tax, fees, bonus funds or cash-out, and the stake already committed. A win returns 25, including the stake; a full void returns 10. If 25 was already credited and a valid correction changes the ticket to a full void, the accounting must reverse that 25 and credit 10, a net adjustment of minus 15. Adding another 10 without reversing the original return would overpay.

Keep the original settlement, its reversal and the replacement linked in the ledger. Redelivery of an already applied operation must have no extra financial effect, but a legitimate correction must remain possible. Do not deduplicate all settlement messages by event identifier. If funds from an earlier return have already been spent or withdrawn, route the discrepancy through an approved account-handling process; silently setting a negative result to zero hides the problem.

Published rules and operational behaviour must agree. For operators within its remit in Great Britain, the Gambling Commission's settlement guidance addresses rules for acceptance, voids, errors and result determination. This is a jurisdiction-specific reference, not a worldwide compliance specification.

Treat in-play as a distinct operating problem

In-play adds a moving event state to the acceptance problem. A suspension, score change or producer handover may arrive while a request is waiting. Decide which signals close admission, which pending requests require another check and who may reopen a market. A configurable acceptance delay may be part of the trading policy, but it cannot make stale data safe by itself.

Connection recovery and offer recovery are separate. UOF's heartbeat guidance describes producer-scoped suspension and recovery before reopening active markets. Set thresholds and procedures against the contracted feed and SDK; do not copy one provider's timing values into every integration.

A conservative operating policy is to reopen affected markets only after the required recovery has completed and the platform has applied its recovered state. Receiving a completion message is not the same as draining a local processing backlog. Keep evidence of the recovery request, affected producers and events, outstanding processing and the reopening decision. An outage in one producer need not stop unaffected betting offers when their dependencies remain sound.

Keep useful customer services available during containment where possible: history, request-status lookup and explanations for unavailable markets. Stop new admission in the affected scope rather than making accepted tickets disappear. Television is not an authoritative clock for acceptance: in Great Britain, RTS 15 on in-play betting requires information explaining broadcast delay and the possibility that others have more current information, on main in-play pages where practicable.

Evaluate integrations through their failure contracts

Evaluate a supplier with concrete questions about unresolved work. Can you look up a placement after a lost response? How long are request identities and results retained? How are corrections identified? What is the scope of a suspension? What happens when an event or market identifier changes? Ask for evidence from a test environment, not only descriptions of the normal path.

Feed recovery is not necessarily a historical archive. UOF recovery documentation explains that recovery can deliver current odds rather than every intervening price change, and can combine settlement messages. Keep your own accepted-ticket terms and test replay at the level of market outcomes and financial operations.

For multiple data sources, define event mapping, authority and handover rules. “Use the second feed if the first fails” is incomplete when the two identify selections differently or disagree about whether a market is open. Never merge them simply by the displayed team names. A replacement source must not rewrite already accepted odds or cause results to settle the wrong market.

Contract review should cover permitted data use, jurisdiction and product coverage, support ownership, recovery windows and export access. An API endpoint does not establish the right to offer a market. Keep responsibility for licensing, customer restrictions and approved betting rules explicit with the operator's qualified advisers. For technical responsibility boundaries, continue with sportsbook platform architecture.

Deliver a narrow product with evidence that it works

The first useful delivery is a complete betting journey within a deliberately narrow scope. One supported sport and a small set of prematch singles can be more informative than many half-connected features: display an offer, commit a stake, accept or reject, show the receipt, receive a result, credit the return and explain the record. This scope still needs correction and recovery paths; those are not optional simply because the catalogue is small.

Agree measurable operating limits before launch. Track the age of unresolved placements, funded versus accepted tickets, outstanding reservations, settlement-to-ledger discrepancies and the time until an affected market is safely reopened. Review end-to-end delays and errors for real journeys; successful feed ingestion alone does not prove successful bet acceptance. The observability guide explains how to connect signals to affected operations.

Rehearse a release while bets are pending and results are arriving. An application rollback must preserve accepted tickets, committed funds and compatible settlement records. Name the person who can stop admission, resolve unknown requests and approve a corrected result. Expand sports, combinations and in-play only after the added rules and failure cases have been demonstrated. The checks below provide evidence for that decision.

• Submit the same placement twice, then reuse its key with a different stake. Prove that the duplicate returns the original decision, the changed request is rejected and only one stake is committed.
• Place competing bets against the last available funds and risk capacity. Prove that concurrency cannot spend the same money or accept exposure beyond the defined limit.
• Change the price and suspend the selection while acceptance is pending. Verify the customer's price preference and the authoritative admission decision in the resulting receipt.
• Lose the provider response after it accepts a ticket. Resolve the pending request without creating another bet, releasing committed funds or leaving an untraceable reservation.
• Disconnect an odds producer, then recover it with a local processing backlog. Confirm the affected scope stays closed until the reopening conditions are met.
• Replay a settlement, then apply an authorised correction. Prove that replay adds no money, the correction has the intended net effect and both histories remain inspectable.
• Recover a message containing several markets and outcomes. Confirm that deduplication preserves legitimate unapplied operations and never treats the whole event as already settled.
• Roll back an application release with accepted and pending tickets in flight. Reconcile the ticket records, wallet and trading exposure and resolve every remaining exception.