An in-play bet can show as pending because pressing “Place bet” is a request, not necessarily confirmation that a wager has been accepted. During that interval, the sportsbook may check the current event information, market status and price. A market can be suspended while an important event is being assessed; a changed price may have to be offered again; or the request may be rejected. The accepted betting acknowledgement—not a screenshot of the earlier odds—is the record of the wager that actually exists.
This guide is for sportsbook product and compliance teams, and for readers trying to understand an in-play bet that was delayed, repriced or not accepted. The regulatory examples are from Great Britain and were checked on 29 September 2026. Sportradar's Unified Odds Feed is used as a specific technical example, not as a model every bookmaker uses. This article covers bet acceptance before settlement; our separate sportsbook settlement guide follows an accepted bet through result, payout and correction.
Why an in-play price can go stale
In-play, or in-running, betting means wagering while the event is taking place. The UK Gambling Commission's in-play guide describes continually changing prices based on event information and operator liabilities. Operators use real-time data to revise prices, suspend markets and settle bets. The guide also explains the gap between action at a venue and a television or online stream: someone watching a delayed broadcast may not see an event when it has already affected the available market.
Think of three separate clocks. The event clock is what has happened on the field. The information clock is when an official, scout or other data source reports it to the sportsbook. The customer clock is what an app or stream displays when a person taps a price. These are conceptual clocks, not three mandated timestamps or a claim that one feed always arrives first. Network speed, the data product and the operator's own processing can change the gap between them.
A goal illustrates the problem without requiring a real match. A stream may still show play before the goal while an event feed has reported a scoring incident. The sportsbook may stop taking bets on the next-goal market while it checks that incident. A price displayed before the stop is not a promise that every ticket submitted during the transition will be accepted. The odds-feed versus managed-trading explainer details which supplier or operator can control the upstream price and risk decision.
How in-play betting delays work
The Commission's in-play position paper, originally published in 2016 and available as a current guide, says bookmakers place a delay between a customer's in-play bet request and confirmation. Its explanation is that the delay lets the operator check that the offered odds reflect the event's progress. It distinguishes sportsbooks, which use the delay to check their own prices, from exchanges, which use it to protect participants. The length varies by operator, event and the latency of the data source.
That description should not be turned into a claim that British law imposes a fixed three-, five- or ten-second delay on every live bet. We found no such universal period in the applicable RTS 15 in-play standard or the guide. The pending interval may also include routine request processing; a visible spinner does not reveal which control caused the wait. Operators should describe the acceptance policy clearly rather than rely on a countdown animation as a substitute for terms.
The customer-facing distinction is straightforward: request received and bet accepted are not the same state. If an important event occurs or the market closes while a request is pending, the sportsbook may decline it under its applicable rules. If the price moves, it must apply the customer's price-change choice. Whether a later dispute concerns a never-accepted request or a previously accepted wager is a different question with different evidence.
Open, suspended, inactive, accepted: the states are different
The following table separates a market's availability from the state of one customer's wager. The feed examples are from Sportradar's market-status documentation; they are not universal API codes.
| State | What the customer may see | What it means for a new ticket |
|---|---|---|
| Market open | Current price and an enabled selection. | A request can be submitted, subject to acceptance checks. |
| Bet pending | A submitted request without final acknowledgement. | Do not treat it as an accepted wager yet. |
| Market suspended | Odds may remain visible but selection is unavailable. | No new ticket should be accepted on the suspended market in the Sportradar example. |
| Market inactive | The selection or price may disappear. | No new ticket is offered until reactivation, if it happens. |
| Request rejected or repriced | The app reports non-acceptance or a revised offer. | No wager exists at the rejected terms; a new acceptance step may be needed. |
| Bet accepted | Ticket acknowledgement and accepted terms are available. | The wager exists and is later graded under its rules. |
In Sportradar's Unified Odds Feed, an active market has status `1`, a suspended market `-1`, and a deactivated market `0`. Its documentation says a suspended market can continue to display odds without accepting tickets, while a deactivated market no longer provides odds. A market may return to active status after a temporary stop. Those are feed-side market states; the bookmaker's consumer interface and account system must still handle each customer's request correctly. A settled or cancelled market is different again, and a temporary suspension is not by itself a voiding decision for an existing ticket.
Why markets stop during live play
The Sportradar `bet_stop` message provides a concrete implementation. It is designed to suspend all, or a defined group of, active markets quickly while odds can remain displayed. The message can be sent before a detailed cause is available; a later odds-change message may provide more context. The same documentation says an affected market stays stopped until an appropriate active update reopens it. A bet stop therefore is a market-control signal, not proof that a particular customer's ticket was accepted or rejected.
Sportsbooks may also suspend trading for reasons beyond one scoring incident: uncertainty about an event update, a missing live feed, a price re-evaluation, a market moving into a different phase, or a system fault. These are examples of operating situations, not a claim that every provider uses the same trigger list. A temporary pause can be a sensible way to avoid accepting bets against information the operator has not yet reflected in its prices. The operator still needs rules and controls for how customers are informed and what happens to requests already in flight.
The difference between suspended and deactivated matters in a review. A suspended market may preserve the quoted odds on screen but prevent tickets. A deactivated market may no longer display prices at all. A cancelled or settled market addresses a later lifecycle state. The mere visibility of a number is therefore weak evidence that betting was open at the instant the operator processed a request.
What happens when the price changes before acceptance?
The British RTS 2 transaction standard requires enough information about the bet, including relevant stake, selection, bet type and accepted odds, before the customer commits. More specifically, RTS 2C requires a customer choice about accepting price fluctuations after a bet is requested. Its guidance says the choice should normally be made for each bet; an account-level default cannot simply be set to accept all changes. If the customer has not chosen automatic acceptance, a changed-price bet must be reoffered before it is accepted.
There are consequently at least three different outcomes after a tap. The original offer may be accepted at the requested price; a revised price may be presented for a fresh decision; or the request may be rejected because the market is no longer open or another acceptance condition is not met. A customer-selected setting may allow specified price movement, but the mere existence of that feature does not prove a particular bet was accepted. The accepted price and terms need to be visible in the final acknowledgement.
For covered British betting licences, LCCP 4.2.6 requires full betting rules to explain treatment of errors, late bets and related contingencies. It also requires a slip or electronic acknowledgement for each transaction, except telephone betting, with operator identification and a statement that bets are accepted under its rules. The article is not claiming that a specific screen design or timestamp field is prescribed there; the point is that an accepted wager has a record distinct from a provisional on-screen offer.
“Live” does not mean simultaneous
British RTS 15 applies to betting and peer-to-peer betting. It requires information explaining that “live” TV and other broadcasts are delayed and that other people may have more up-to-date information. Main in-play pages must include that information where practicable, with accessible detail elsewhere when needed. This is a disclosure rule about information disadvantage, not a guarantee that the operator's feed is always faster or a rule setting a minimum processing delay.
There is a regulatory scope trap here. The Commission's in-play guide refers readers to RTS 4 when discussing technical speed disadvantages. But the current RTS 4 page states that it applies to gaming, lotteries and betting on virtual events—not betting on real sporting events. For a real-event sportsbook article, RTS 15 and RTS 2 provide the relevant direct standards; RTS 4 should not be presented as a blanket legal basis for every real-sports bet delay. This distinction follows the applicability line on the official standard, not an inference about virtual sports.
A practical control trail for operators and customers
An operator should be able to explain how a request crossed from a displayed offer into an accepted or rejected outcome. This is an editorial review checklist derived from the source documents, not a regulator-issued form or a list of database fields mandated by law.
- Identify the event and market. Record the sport, event, market, selection and whether the market was open, suspended or inactive when the request was processed.
- Separate the visible offer from the final terms. Preserve the price shown, the customer's price-change preference, any revised offer and the price actually accepted, if any.
- Reconstruct the request sequence. Compare the customer's submission, the feed or trading update, the acceptance decision and the acknowledgement. Do not infer an accepted ticket solely from a pending animation.
- Check the operator's rules. Identify how late bets, errors and market closures are described and which version applied at the time. A later explanation should not substitute for the applicable terms.
- Reconcile the account. If a ticket was accepted, confirm its identifier and eventual status. If the customer disputes a rejection or an accepted bet's later outcome, keep the acknowledgement and account history. Our complaints and ADR guide covers escalation of eligible unresolved British transaction disputes.
The Commission's RTS 5 says reasonable steps should be taken to accept, process and settle gambles according to published terms and the particular event or bet. Where an unexpected fault affects a customer, it calls for prompt remedy and fair treatment in the circumstances. That applies to the integrity of this acceptance chain as well as eventual settlement, but it does not require every submitted request to be accepted.
A provider and operator can divide the technical work differently. A feed may signal a market stop, managed trading may make an acceptance decision, and a player account system may record the wager. The customer contract and regulatory accountability still need to be understood at the operator level; a supplier's market code is not a complete consumer-facing explanation.
Bottom line
In-play betting delays are intervals in which requests are checked against fast-changing event information, market availability, price and the operator's rules. A temporary suspension controls whether new bets can be accepted; it is not the same as voiding one already accepted. A customer should rely on the final acknowledgement and accepted terms, then ask the operator to explain a rejection or repricing with those records. The British rules cited here have specific scopes, and other jurisdictions or bookmakers may use different processes.
Frequently asked questions
Why does my live sports bet say pending?
“Pending” ordinarily means the request has been submitted but acceptance has not yet been confirmed. The sportsbook may still be checking market status and price during a live event. The exact processing delay varies by operator and event. Look for a final ticket acknowledgement before treating the bet as accepted; a spinner alone is not confirmation.
Does a suspended betting market void my existing bet?
Not by itself. A suspension stops new tickets on a temporarily unavailable market in the technical example discussed here. An already accepted bet remains subject to its own market and operator rules and may later be settled or voided for a separate reason. Check the accepted ticket and published rules rather than assuming that a greyed-out price cancels it.
Can a bookmaker accept my in-play bet at different odds?
In Great Britain, RTS 2 requires a choice about accepting price fluctuations after a bet is requested. If the customer has not chosen automatic acceptance of a changed price, the revised bet must be reoffered before acceptance. The final acknowledgement should show what was actually accepted; a price displayed before the request does not prove the accepted odds.
Is there a mandatory in-play betting delay in Great Britain?
The UK Gambling Commission explains that operators set processing delays and that their length varies with operator strategy, the event and data latency. The sources reviewed do not set one universal number of seconds for every real-sports in-play bet. RTS 15 is primarily about warning customers that “live” broadcasts may lag behind the event.
Why can I still see odds when betting is closed?
A temporarily suspended market can keep displaying an old price while refusing new tickets. Sportradar's Unified Odds Feed uses that distinction explicitly: its suspended status displays odds but does not permit ticket acceptance. Other systems may present the state differently. Visible odds are therefore not proof that a new wager could be accepted at that moment.