A complaint about one casino spin can arrive with a bank transaction number, an account name and a screenshot of the reels. None necessarily identifies the spin. Before debating the payout, support has to find the same event the player is describing.
A round reference helps locate that event; it does not establish what anyone is owed. The useful record connects the particular game, wager and settlement. This report separates those records using public operator help and Great Britain's technical standards, checked on 28 October 2026. No customer account or private casino log was accessed.
Keep the label attached to the reference
An account ID identifies the customer record. A deposit or withdrawal reference identifies a movement through the cashier or payment route. A wager reference concerns a bet, while a round reference concerns an occurrence of play. These are different questions to put to support, not a promise that every casino exposes four separate fields.
Operator terminology makes precision important. PokerStars' casino-history help offers filters by number of games, time frame or Game ID. It does not define that label as a universal provider-round identifier. Copy the value together with its label rather than renaming it.
Wiz Slots' published guide describes a copyable Transaction ID or Bet ID next to a casino session. Expanding the session reveals individual rounds with Time, Stake and Return. A session reference and a row within that session are not automatically the same level of detail. The guide also describes an Excel report generated from Bet History.
If support supplies another reference, ask how it maps to the one already recorded. A game title, provider and version, if shown, help narrow the search. A title alone does not identify a deployed build, as our game-version report explains.
One invented round, two amounts to reconcile
Consider a fictional cash-only record for Example Slot by Example Studio. Its made-up reference is R-EXAMPLE-41, dated 20 October 2026 at 18:04:09 UTC. The account has £40 before the wager. A £2 stake debit leaves £38; a subsequent £5 return credit brings it to £43. Assume there are no bonus funds, currency conversions or other entries between these amounts.
The return is £5, while the net change is £3. Calling the £5 a profit would overstate this example. Equally, seeing only the debit before the later credit would describe an incomplete sequence. The round reference gives the reviewer a way to ask whether both entries belong to the same event.
Now change one fact: suppose the recorded credit is £2. The closing balance becomes £40. If the applicable rules and the confirmed result establish a £5 return, the shortfall is £3. Without that confirmation, subtraction has identified a claimed discrepancy, not proved a debt. This is an original accounting illustration, not a reported malfunction or a real game's payout.
A focused enquiry could therefore ask the operator to locate that labelled reference, confirm the accepted stake and recorded result, and match the resulting credit to the account entry. Include the game and provider, time zone, currency and the amount being questioned. Where the ID is missing, give the narrowest known time range and retain the surrounding history rows. Do not invent a reference to fill the gap.
Keep the original export or screenshot as well as the explanation sent with it. An edited crop may omit the currency, session heading or neighbouring entry that makes the record intelligible. Send account-identifying material through the operator's official support route rather than publishing it in a forum.
Accessible history is not an unlimited replay archive
Great Britain's RTS 1B requires easy access to at least three months of account and gambling history, with at least 12 months available on request. Its gaming guidance permits full or summarised information. Where detailed historic game information is not directly available, it specifies access to the last game played and summaries of previous activity.
Those are history-access requirements within the British licensing framework. They do not promise that every old spin has a customer-facing replay, or set one worldwide retention period for every supplier log. PokerStars' cited help also limits its stored game-history feature to real-money play; that statement should not be applied to other operators' practice modes.
RTS 2 addresses clear stake amounts, conversions and the content of a gamble before commitment. It also requires the covered casino sessions to display net position, excluding peer-to-peer poker. A session total still does not identify which individual round produced a disputed credit.
A frozen picture leaves the settlement question open
The casino column in the Commission's applicability annex includes RTS 10 on interruptions. Its guidance distinguishes results that can stand after acceptance from unfinished play that may need restoration. A dropped connection alone does not select the treatment.
Our interrupted-bonus report covers saved feature state. Here the task is narrower: ask whether the identified round completed, resumed or was voided, then request the account entry and rule supporting that status. A replay of the animation and a wallet credit answer different parts of the enquiry.
In R-EXAMPLE-41, an answer saying only that the game worked normally leaves the £2 debit and claimed £5 return unreconciled. A checkable reply identifies the same event, explains the amount settled and connects it to the account record. It may confirm the payment, correct an error or explain why the claimed return was wrong.
