Skip to Content
WalletSeamless WalletRequests FlowOverview

Seamless Wallet Requests Flow

This section shows how the wallet calls follow one another through a bet’s lifecycle: which transaction GR8 Tech sends at each stage, what your wallet is expected to return, and what happens when a call fails.

Each page below pairs the flow diagram for one stage with the request payloads sent at that stage. If you are looking for the endpoint contract itself rather than the sequence, start with perform-transaction.

Bet lifecycle

Which transaction arrives when

StageTypeReasonFlow page
Player places a betwithdrawalbetPlace Bet
Bet placement fails technicallyrollbacksport rollbackPlace Bet
Event is settleddepositsettleSettlement
New payout is greater than the previous onedepositresettleSettlement Corrections
New payout is smaller than the previous onewithdrawalresettleSettlement Corrections
Settlement is reverted entirelywithdrawalcancelsettleSettlement Corrections
Partial cashout is settleddepositpartial settlePartial Cashout
Partial cashout payout is adjusteddeposit / withdrawalpartial resettlePartial Cashout
Partial cashout is revertedwithdrawalpartial cancelsettlePartial Cashout

Bonus and freebet transactions follow their own flows — see Bonuses.

Response shape

Every stage uses the same two envelopes, so they are shown once per transaction type rather than for every case:

  • Success (HTTP 200) — echo the fields of the request back and add balances (the player’s balances after the operation) and alreadyProcessed. See Response Structure.
  • Error (HTTP 400) — return an error object with code, message and origin, plus alreadyProcessed. See Wallet Error Codes.
Important

Always answer with either HTTP 200 or HTTP 400 and a valid body. A 5XX response or a timeout is treated as “unknown” and triggers retries — the retry budget differs per stage and is documented in Rollback and Retry Logic.

Get Transaction by IDPlace Bet