A retry should carry the same operation ID as the original request. A settlement also needs the original bet reference. These identifiers answer different questions: whether an operation was already applied, and which open stake it settles.
What you’ll take away
- Keep the operation ID stable when retrying the same transaction.
- A bet reference connects a win or refund to its original open stake.
- Ledger validation prevents certain duplicate operations; it does not prove a browser-reported result is genuine.
Use two identities for two jobs
The browser tags wallet changes with an operation ID, a kind such as bet or win, a signed amount and, where applicable, a game and bet reference. The server ledger identifies an operation within a user account. The bet record identifies the stake that a later win or refund is allowed to settle.
These are not interchangeable. A win is a new operation with a new operation ID, but it refers to the original bet. Retrying that win keeps its win-operation ID unchanged. Creating a fresh ID on every network retry would lose the connection to the original request.
Trace a repeated debit
Assume a demo account begins with 100 credits. It sends a 10-credit bet with operation ID op-bet-01 and reference bet-01. The server records the accepted debit and the balance becomes 90. If the response is lost, the client can send the same operation again.
The ledger’s uniqueness rules and pending-row checks prevent that already-applied operation from changing the balance again. The response returns the server balance so the browser can reconcile its local display. This is a replay of the same payload, not a general claim that arbitrary changed payloads are safe.
Settle an open bet once
A 20-credit win referencing that stake would bring the balance from 90 to 110. The server requires an open bet for the same user and game, within the settlement time limit, and a payout within the game’s maximum. It closes the bet when the accepted settlement is applied.
A refund follows a different amount rule: it must equal the original stake. It restores the 10 credits in this example, rather than paying a result multiplier. A second settlement of the same closed bet must not create another credit. The server tests cover retries, duplicate wins and refund amounts.
Keep accounting correctness separate from game authority
Hangar validates balances, stake ranges, open-bet references and payout ceilings, but the browser still computes the outcome. A manipulated client could report an invented win for an eligible open bet up to the allowed cap. Duplicate prevention is therefore necessary but not sufficient for an authoritative game service.
For an integration review, trace both sides: the source of the result and the transaction that records its payment. Test lost responses, repeated requests, attempted second settlements and reconciliation after reconnecting. Keep account-ledger evidence distinct from the simulated business data in other back-office views.
Sources & scope
Prepared from the Hangar project’s implementation and documentation. Source links point to the inspected revision, so the examples remain traceable as the project changes. These notes describe a software demo, not a certified real-money service.