Display delay and acceptance
Video, score feeds and betting servers can update at different times. A price visible during a live event may change before a submitted instruction is accepted. A market can also suspend during important action. The rules should explain confirmation, changed-price acceptance and any delay in placing a bet.
Suppose a user sees decimal 2.20 but the accepted receipt records 2.00 after a permitted price-change confirmation. A ₹100 winning cash stake returns ₹200 under that receipt, not ₹220 based on the earlier display. If the instruction was rejected, there is no accepted stake merely because a selection briefly appeared on screen.
Market period and current score
Some live handicaps apply to the final score, while others apply only to the remaining period or a specific segment. A market title should make that distinction clear. The score at acceptance can be relevant, but it does not replace the exact rule used to settle the wager.
Cashout and suspension
Cashout can be unavailable or change while the event progresses. A displayed quote is not necessarily a completed early settlement. Keep its acceptance confirmation separate from the original bet. Neither a live price nor an early-settlement offer independently establishes the true probability of the event.
Records that help explain a result
Save the accepted time, market, period, line, odds and stake. Use the authorised final result source for settlement rather than a delayed stream or provisional graphic. Live availability creates a different timing context from pre-match betting, but it does not remove the risk of losing the whole accepted stake or make faster reactions a guaranteed advantage.
Does a live score update determine whether an instruction was timely?
Not by itself. The stream or app can be delayed relative to the betting system, and acceptance can occur under a documented delay or suspension process. The accepted timestamp, event state and relevant rule are the evidence needed for the transaction. A user seeing one score does not prove the server had the same state at that moment. Keep the confirmation rather than only the pre-submission screen, and avoid treating fast interface interaction as a guaranteed prediction advantage.