Embedded Files
Choose the route by the event in dispute. When two routes apply, record the owner and review cutoff for each open question.
A sportsbook incident can start with one sentence from support: the player saw a bet, the balance changed, and the result looks wrong. That sentence contains several questions. Did the sportsbook accept the bet? Did the operator wallet commit the corresponding debit? Did the player accept a particular cashout offer, or did a later settlement change the balance? The same bet identifier can be relevant to all three questions. It rarely tells a reviewer which record to request first.
Start by naming the event the player disputes. Use the acceptance route for a placed bet with a timeout, a missing confirmation or a disputed stake debit. Use the cashout route for an offer that appeared at one amount and produced a different result. Use the settlement route for a result, credit or correction after the bet was accepted. When a case crosses routes, carry forward the identifiers and confirmed facts. Give each remaining question its own owner and cutoff.
This hub is for integration engineers, sportsbook operations and wallet teams that need to make that first handoff. It uses two fictional cases to show how a review changes as evidence arrives. The proposed records and decisions are examples. Their names, timing and financial rules belong to the examples. Check the corresponding rules and record access in your own integration.
Route the incident by the event in dispute
Route the incident by the event in dispute
The routing table separates three kinds of evidence that support teams often receive together. Read across the row for the disputed event. Take the first evidence pair to the named custodian, then check what that pair leaves open. If two rows apply, start with the earliest unresolved business decision that affects the later question. A known accepted bet with a disputed payout can go directly to settlement. A disputed acceptance with a later credit may need both routes.
Keep an operational timeline with one row per event. For each row, preserve the source, producer time, receipt time if available, native identifier and status as recorded. Add the source export range and the time at which the reviewer obtained it. Record the clock or timezone assumptions when they affect order. Two entries that appear a second apart are often easier to join by an attempt reference or a provider sequence than by timestamps alone.
Separate evidence a system recorded from what a reviewer concluded. For example, an HTTP timeout is a client or adapter observation. It says the caller did not receive a usable response within its deadline. A committed transaction is a wallet finding. A provider acceptance record is a sportsbook finding. An incident can contain all three without contradiction. Ask the custodian whether an export includes pending entries, completed entries, reversals or only a view of recent requests. The answer determines what an apparent gap can support.
Where possible, preserve the original identifier in the source's own namespace. Keep provider, route or tenant with it if the identifier can be reused across deployments. If a report masks a player identifier, record the controlled join reference or assign a person who can make that join. When a service emits a fresh delivery ID for a retry, keep it alongside the stable operation or settlement ID. Both values help, but they answer different questions about the same incident.
An export's boundary matters most when the answer depends on an absent record. Suppose the provider's response export stops at sequence 120 and the wallet journal extends to sequence 250 in its own namespace. Neither sequence gives the other system a cutoff. The reviewer needs a provider range that covers the original attempt and a wallet range that covers the relevant account, currency and operation. Document when a query uses a replica or a support view with delayed updates. If the custodian cannot establish coverage, leave the absence as a limitation of that export.
Also preserve the version of any decision rule you use in the review. An offer expiration window or a route's correction behavior can change after a release. Store a reference to the contract or configuration that applied when the event happened. If the current support procedure differs, keep its reference separately for the action the team can take today. In a handoff, the historical rule explains the finding, and the current procedure governs the next step.
Worked route one: A stake debit times out
Worked route one: A stake debit times out
In fictional case S-481, a player tries to place a EUR 18 bet. The sportsbook adapter records attempt P-17 and sends a debit request with operation key W-17. The caller times out. The support screen shows a placement attempt and a spinner. The first export also contains a wallet gateway receipt for W-17. That receipt shows the wallet interface received the request. The export ends before the complete journal range and contains no final sportsbook decision for P-17.
At review cutoff R1, support can say the attempt was recorded and the wallet interface received the request. The committed wallet outcome and the sportsbook acceptance outcome are both unresolved. Write them as two open questions. Route the first to the wallet custodian with W-17, the amount, currency and export boundary. Route the second to the sportsbook custodian with P-17 and the provider route. Record the next review time and the person responsible for bringing the answers back together.
At cutoff R2, the wallet custodian supplies journal J-92 with W-17, a committed EUR 18 debit and the complete relevant range. Under this example's cash-only assumptions, that range starts at EUR 100 and ends at EUR 82. The sportsbook custodian supplies acceptance A-38, bound to P-17 and bet B-481. The incident record now supports one accepted bet and one committed stake debit within the checked range. Keep the original timeout in the timeline so a reader can explain why the initial screen was inconclusive.
The two answers could have diverged. If J-92 were confirmed while P-17 remained unresolved, support would have a wallet finding and an open acceptance question. If a final rejection arrived instead, the wallet owner would use the integration's documented handling for a committed debit attached to a rejected attempt. Any authorized reversal would be a separate ledger event with its own link and evidence. The incident classification gives that owner a case to act on through the normal controls.
Ask the wallet team how it treats the original operation key before anyone retries a request. The retry window, key scope and lookup path depend on the implementation. A retry that falls outside the original key scope can create a second operation even if the caller believes it is recovering the first. An investigation can proceed through read-only exports and status checks while the authorization for any financial action remains with the designated owner.
For the full acceptance sequence, including the point where an ambiguous wallet attempt becomes a proved debit, use the earlier reconstruction guide. How to Reconstruct a Sportsbook Bet After a Wallet Timeout
Cashout: Match the instruction to the offer version
Cashout: Match the instruction to the offer version
When a player disputes a cashout amount, start with the offer identifier, version and amount shown to the player. The decisive join is the recorded player instruction or confirmation against that version, followed by the sportsbook decision on the instruction. A screenshot can establish what was displayed at a particular moment. A wallet credit can establish what reached the ledger. Neither tells the reviewer which instruction the sportsbook accepted without a record that joins the events.
Ask the offer custodian for the offer history covering the display and instruction. Ask the acceptance custodian for the instruction, any required confirmation and the result for that exact version. Then follow the accepted decision to its sportsbook settlement and wallet credit. Keep the currency, whether the cashout was full or partial and the applicable amount fields visible. The expected record chain can differ if the operator supports partial cashout or a separate quote refresh.
If the offered and credited amounts differ, distinguish a question about authorization from one about the posting itself. The sportsbook owner can determine whether the credited outcome belongs to an accepted instruction. The wallet owner can determine whether the recorded settlement reached the relevant ledger. When the link is missing, preserve both results at the same cutoff and keep the case open at the missing join. The difference between two amounts is a useful search clue. A correction requires its own evidence and approval.
For a deeper example, the cashout guide traces a displayed EUR 64 offer and a EUR 60 credit across two cutoffs. It shows what changed when the later export supplied a separate revised offer and its acceptance chain. How to Choose Evidence for a Sportsbook Cashout Dispute
Worked route two: Settlement arrives after a provider route change
Worked route two: Settlement arrives after a provider route change
In fictional case S-704, bet B-704 was accepted on provider route A before new placements moved to route B. The operator's retained placement record identifies route A and its generation G3. Under the example contract, route A continues to issue results for bets it accepted, and the wallet adapter recognizes a settlement by its issuing route, generation and settlement identifier. A late event can therefore belong to a valid old bet even though the current routing configuration points to B for new placements.
The first delayed callback arrives as delivery D-41. Its payload identifies route A, generation G3, bet B-704 and settlement S-21 for a EUR 42 credit. Check the provider result against the original placement before treating the callback as a candidate financial effect. In this case the sportsbook result export and the placement record agree. Wallet posting L-18 binds to the same settlement and shows the credit. If the pre-credit balance was EUR 80, the running balance in the example is now EUR 122.
A later delivery D-44 carries the same scoped settlement identity and the same amount and result. In the example, the adapter associates it with L-18 and records a duplicate delivery without a second posting. The acknowledgement of D-44 says the adapter handled a delivery. The wallet journal establishes how many credits committed. AWS Prescriptive Guidance describes the general duplicate-message control in its transactional outbox guidance. Transactional outbox pattern
make the consuming service idempotent by tracking the processed messages
The example's provider contract separately allows corrections. Delivery D-51 carries a new correction identifier C-9, references S-21 and revises the total credit to EUR 35. The review verifies the correction with the provider and checks that the operator's adjustment procedure permits a EUR 7 decrease against the original credit. The resulting wallet posting L-19 binds to C-9 and L-18. In the complete example range, EUR 80 plus EUR 42 minus EUR 7 leaves EUR 115. Two deliveries of S-21 account for one credit, and the correction accounts for one linked adjustment.
A changed amount arriving under the same settlement identity without a recognized correction reference would go to the provider custodian as a conflict. The evidence packet would include both payload versions, their delivery references and the existing ledger posting. The reviewer would request the provider's authoritative result history and applicable correction rule. This protects the operator from classifying a real correction as a duplicate or treating a transport replay as fresh authority.
This route also gives migration teams an exit question. Before retiring the old integration path, establish who can retrieve the original placement, receive or recover late results and export correction history. In the example, a support view that retains the bet ID but loses generation G3 would make S-21 harder to interpret. Record the provider identity and route at acceptance, then preserve the ability to trace old bets throughout the applicable review window.
Keep the same distinction when the provider result is known and the wallet position remains uncertain. The provider custodian can attest that S-21 was issued for the original bet. The wallet custodian still needs to determine whether L-18 exists and whether any offsetting posting belongs to the same settlement. If the provider uses a resend function, record the original business identity before requesting a resend. The delivery history should let the next reviewer identify every copy of the event and the wallet range that was searched for its effect.
Handoff record for an unresolved wallet outcome
Handoff record for an unresolved wallet outcome
A handoff should let another team resume the case without asking support to reconstruct the timeline from chat. Give it a stable case ID and one line for the decision being requested. Include the original player report or a controlled reference to it, the route selected and any other routes still open. Keep original exports and case notes under the access rules that apply to the incident. Share the minimum references needed for the recipient to retrieve the authorized evidence.
For S-481 at R1, the wallet request can read as follows. Establish whether operation W-17 for EUR 18 committed a stake debit in the applicable ledger, or whether its outcome remains unresolved. Reference P-17, the original gateway receipt and the R1 export boundary. The wallet custodian should return the scoped transaction and status with the covered range, or identify the missing source. The sportsbook owner separately owes a final decision on P-17. Support records the next review time and updates the case after both responses.
Add the current action boundary in ordinary language. At R1, the evidence supports read-only lookup. The handoff supplies no authorization for a new stake debit. Record the specific evidence needed to change that decision, such as a complete wallet export or the documented status of the original operation. If an authorized operator later issues a correction or recovery action, record the actor, basis, resulting reference and approval path separately.
Make each confirmed, open and superseded finding visible as the case evolves. The R2 journal and acceptance data can supersede the R1 uncertainty while the earlier review remains reproducible. For a settlement revision, keep the original result and posting accessible next to the corrected result and adjustment. A reviewer should be able to explain what was known before the correction, what was added and which action followed that addition.
Test evidence access before an incident
Test evidence access before an incident
Use a proposed tabletop exercise with the integration team before a release or supplier change. Pick one accepted bet with an ambiguous wallet response, one expired or revised cashout offer and one late result from an older route. Use synthetic data and known outcomes. Assign different people to the sportsbook, wallet and case review roles so the exercise exposes the handoffs. Give each person only the evidence they would normally be able to export or request.
At the first cutoff, deliberately withhold one record that changes the conclusion. Ask the reviewer to state which finding is supported, which remains open and who can provide the missing record. At the second cutoff, supply the missing item and ask for the join references and revised conclusion. Include one duplicate delivery and one genuine correction in the settlement exercise. Check that the reviewer can distinguish them through the identity and correction references, then verify the count of committed effects in the declared wallet range.
Ask the reviewer to deliver a written decision for each route. In the placement case, it should state acceptance and the wallet effect independently. In the cashout case, it should identify the version the player confirmed and the credit that followed it, or identify the missing join. In the settlement case, it should reconcile the original and corrected totals while showing which deliveries had no additional effect. Retain the exact export and cutoff behind each decision so that a different team can reproduce it.
Agree what a usable result looks like before the exercise starts. The recipient should be able to find the matching attempt or settlement with the exported references and account for the covered time or sequence range. If the export lacks an identifier, record the accepted substitute and who can join it. If a supplier has to retrieve the evidence, agree how the operator will make the request and which custodian can supply the missing record. Keep a record of the exercise outcome and repeat the relevant case when the interface or ownership changes.
For teams comparing integration scopes, ask for a concrete export or a walkthrough using a synthetic case. Which system owns the bet and offer decisions? Which wallet references are carried through the integration? Can both parties retain the original route for a late settlement? Who can explain whether the export is complete? Gambit Stream describes a hosted sportsbook iframe using the operator's wallet and player session. Use that product scope to start a discussion about who can retrieve the records in your deployment. Explore Gambit Stream's sportsbook iframe integration
Close the case against the disputed event
Close the case against the disputed event
A closeout should name the event that was resolved, its authoritative record and the confirmed financial effect within the checked range. Include the latest cutoff and any linked correction. Where a dispute crosses routes, close each supported finding and assign any remaining question. A reader who inherits the case should be able to follow the chain from the original report to the decision without guessing which record carried the authority.
For a placement incident, keep the acceptance decision and committed debit as separate findings. For a cashout dispute, preserve the accepted offer and instruction before reconciling the credit. For a delayed result, record the original provider route and distinguish delivery history from settlement and correction identities. If your sportsbook and wallet teams cannot retrieve these links during a handoff, bring a synthetic incident to the integration discussion and ask each side to produce the records it would own. Discuss sportsbook integration scope with Gambit Stream
Dmytro Nasyrov. Photo supplied by the author.
Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder of Gambit Stream. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.
Page updated
Report abuse