In-Play Betting Explained From Suspension to Settlement
7 min read
In-play betting means placing bets while a match is being played, on prices that change with every incident. Behind each price sits a loop: incident, suspension, repricing, reopening, then settlement and a webhook to the operator.
This article follows that loop step by step, from the moment a data provider reports an incident to the moment the operator's wallet receives a settlement. It ends with a table of the incident types that matter in each sport and what each one does to the markets. For the module that runs this loop for licensed operators, see the in play betting page.
The in-play loop at a glance
Every in-play system, whatever its size, repeats the same six steps for every live event:
- Incident in. The data feed reports what happened: a goal, a point, a foul, a timeout, a clock update.
- Suspend. Markets that depend on the incident stop accepting bets.
- Reprice. The pricing model takes the new match state and computes new probabilities and prices.
- Reopen. Markets that are still meaningful go back to open with the new prices. Markets whose question has been answered move to settlement.
- Settle. Finished markets are resulted from the incident data.
- Notify. The operator's systems receive the result, usually through a webhook, and update bets and balances.
Between incidents, the loop does not stand still. The clock is itself an input. In RealTimeBets prices are recomputed every second for every live event, so a "goal in the next five minutes" market drifts as the window runs down, even when the ball is in midfield.
The incident arrives
Everything starts with the incident feed. A good feed delivers structured messages, not free text: an event identifier, an incident type, the match clock, the score after the incident, and the team or player involved. RealTimeBets returns each incident with the second of the match it happened, and /events/{id}/incidents?after={second} lets you fetch only what is new since your last read.
Three properties of the feed decide the quality of everything downstream:
- Order. Incidents must be applied in sequence. A score update that arrives before the goal incident that caused it will confuse any model.
- Corrections. Feeds send amendments: a goal reassigned, a card cancelled, a point replayed. The system must treat a correction as a first-class incident.
- Completeness. If clock updates are missing, time-based markets cannot be priced or settled correctly.
Markets are suspended
The moment an incident that changes the balance of the match is known, the affected markets must stop taking bets. Some customers watch from the stadium or through a faster stream than the one the feed reports from. Without suspension, they would bet on outcomes they already know.
Suspension has to happen before repricing, not after. The engine flips the market status to suspended, publishes that status to every channel (API, streaming connections, widgets), and only then starts computing new prices. In RealTimeBets, micro-markets are suspended for a few seconds after a dangerous incident such as a goal, a card or a score.
Not every incident is dangerous. A throw-in in soccer or a timeout in basketball rarely changes the probabilities enough to justify closing the book. Suspending on every incident makes the product unusable, suspending on too few makes it exploitable. That balance is configured per market type and per sport.
The model reprices
After suspension, the model runs with the new state. The models differ by sport:
- Soccer and ice hockey. Poisson goal models, with the scoring rate adjusted for score, clock, red cards or power plays.
- Tennis. A serve-hold Markov chain, where the probability of winning a point on serve drives the game, set and match probabilities.
- Basketball and American football. Possession models that describe what each possession or play tends to produce from the current field position, score and clock.
The model returns fair probabilities. The engine then adds a margin (about 6 percent in RealTimeBets) and converts the result into decimal odds. Model-based pricing means the operator is not copying another bookmaker's line. It also means every price can be explained: the inputs and the margin are known.
Markets reopen or close
Once new prices exist, each suspended market goes one of two ways. If the question is still open (the next five minutes have not ended, the game has not been won), the market reopens with new prices. If the incident answered the question, the market closes and moves to settlement.
A clean implementation never reopens a market at the old price. If the model fails to return a price, the market stays suspended. A suspended market costs a few bets. A wrong open price can cost much more.
Markets settle from incidents
Settlement reads the incident data and decides which selection won. The rules for each market type need to be written down before the market is offered, because settlement is where disputes happen.
For time windows, the engine compares incident times on the match clock with the window start and end stored on the market. For event windows, it waits for the defining incident, such as the next point or the next drive result. Two exceptions need explicit rules:
- Corrections after settlement. If the feed reverses a goal, the market must be resettled and the change logged.
- Abandoned matches. If play stops inside a window, the market is voided according to the operator's published rules.
RealTimeBets settles markets from the incident feed automatically. Fan predictions in the play-for-points game settle through the same path, which is a useful public check that the settlement logic works on real match flow.
The settlement webhook reaches the operator
The operator's platform holds the bets and the balances, so it needs to know the result. Polling for results is slow and wasteful. A webhook pushes the result the moment the market is settled.
A settlement webhook should carry at least the market identifier, the winning selection, the settlement time and the incident that decided it. It must be signed. RealTimeBets sends a bet.settled webhook for each bet the operator recorded, with the market key, winning selection, status, payout and settlement time. It signs {timestamp}.{raw body} with HMAC SHA-256 using a secret shared with the operator and sends it in X-RTB-Signature. The receiving server computes the same signature and rejects any request where the two do not match or the timestamp is older than 5 minutes. Each delivery is tried up to 3 times.
Two receiving rules save trouble later. Make the handler idempotent (the same settlement delivered twice must not pay twice), and respond quickly, doing heavy work in a queue after the acknowledgement.
Incident types and their effect on markets
The table below summarises the incidents that drive suspension and settlement in the sports the RealTimeBets engine prices today. A dangerous incident suspends micro-markets for a few seconds.
| Sport | Incident | Effect on markets |
|---|---|---|
| Soccer | Goal | Suspend micro-markets briefly, reprice match result and next goal, settle the current goal window |
| Soccer | Shot on target or corner | Settle the 1-minute shot window or the 2-minute corner window, reprice |
| Soccer | Yellow card | Short suspension of micro-markets, reprice |
| Tennis | Point won or ace | Settle next-point and ace markets, open the following ones, reprice match winner |
| Tennis | Break of serve | Short suspension of micro-markets, reprice |
| Basketball | Score or three-pointer | Settle next-possession and three-pointer markets, reprice points window and winner |
| American football | Touchdown or field goal | Suspend, settle drive-result market, reprice points window and winner |
| American football | Turnover or punt | Settle drive result, reprice with the new drive |
| Ice hockey | Goal | Suspend, settle goal window, reprice next goal and regulation result |
| Ice hockey | Shot or penalty | Settle the 1-minute shot window, reprice |
| Baseball | Strikeout | Settle the plate appearance markets, open the following ones |
| Baseball | Run or home run | Suspend, settle run in the half inning, reprice winner |
| CS2 | Round won or bomb plant | Settle next-round and bomb plant markets, reprice map winner |
Where the loop breaks in practice
Most in-play failures are not model failures. They are plumbing failures:
- Feed gaps. If the feed drops for a moment, the safe default is to suspend every market on that event until the feed is back and in sync.
- Clock drift. Using server time instead of match clock creates settlement disputes around window edges.
- Webhook storms. A busy evening can settle thousands of markets. Receivers that process synchronously fall behind, then time out, then trigger retries.
- Missing audit trail. Without a log of each status change, there is no answer when a customer says a market was open when it should not have been.
The risk engine adds the commercial layer on top of this loop: liability per market, limits per customer, and flags on accounts that consistently beat the line.
Seeing the loop from the fan side
If you want to watch suspension and settlement without placing any money, open a match in the RealTimeBets prediction game. Markets lock after a goal or a point, new multipliers appear, and your call settles from the same incident feed. It is a game, no money is wagered and points have no cash value. The live page lists the matches running in the engine right now.
Questions about in play betting
Why are markets suspended after a goal?
Because the old prices no longer reflect the match. Until the model has repriced, anyone who saw the goal first could bet at a price that is already wrong.
How long does a suspension last?
For micro-markets in RealTimeBets, a few seconds after a dangerous incident. The exact length depends on the incident and on how quickly the model returns a new price.
How does the operator learn that a market has settled?
Through a signed webhook sent at settlement. The operator verifies the HMAC SHA-256 signature, records the result and updates the affected bets.
What happens when a feed sends a correction?
The correction is applied as a new incident. Markets that were settled on the wrong data are resettled and the change is logged with the reason.
Is in-play betting the same as micro betting?
No. In-play covers every market offered during the match. Micro betting is the part that asks about the next short moment, such as the next point or the next five minutes.
