By Editorial Team, reviewed by Editorial Team (approved by site owner) · Published · 1 min read
In-play betting means customers bet while the event is happening. Prices change constantly, and the system has to keep up without letting anyone bet on stale information.
Fast, reliable data
Live betting depends on a stream of scores, incidents and odds from your data provider. Ingest the stream into your own internal model, monitor how fresh it is, and treat a silent feed as a problem to act on, not as "no news".
Staleness guards
Every price should carry a timestamp. If a market has not been updated within a set time, suspend it automatically. This single rule prevents many losses.
Market suspension
Important moments, such as a goal, a penalty or a wicket, should suspend affected markets immediately, then reopen them with new prices. Suspension has to reach the customer screen and the bet-acceptance path at the same moment.
Bet acceptance and delay
Many operators hold a bet briefly before accepting it, so that a sudden change can be checked against the current price. On acceptance, compare the price the customer saw with the current price, and apply your policy: accept, reject or offer the new price.
Pushing updates to customers
Polling does not scale well for live prices. Use persistent connections such as WebSockets or server-sent events, and send only changes. Plan for reconnects, because mobile connections drop often.
Settlement
Live markets often settle fast and in many pieces. Automate settlement from official results where you can, keep a manual override with audit logging, and handle corrections to results.
Test with recorded matches
Replay full recorded events through the system, including feed gaps and corrections, and check suspension, acceptance and settlement behaviour at each step.
The details depend on your provider's protocol and your regulator's rules on in-play betting. Confirm both before you build.
