When a win is refused by your wallet (win_rejected)

Your wallet took the bet but gave a definitive "no" to the win: nothing is paid, nothing is resent, and the round is held for a manual decision.

Who this is for: operators who connect their own wallet to our RGS (seamless wallet). It describes one specific case: your wallet accepted the bet of a round and then refused the win.

In one sentence

If your wallet takes the bet but then refuses the win with a definitive "no", we do not pay the win anywhere, we do not send it again on our own, and we mark the round win_rejected so it can be found, checked and settled by hand.

When does a round reach `win_rejected`?

All of these must be true:

The game runs in seamless-wallet mode (the player's balance lives in your wallet).
Your wallet accepted the bet of the round (the bet was debited).
The round produced a win, and we sent it to your wallet with a balance_adj request of type win.
Your wallet answered with a definitive decline: status 0 or -1 in a normal HTTP answer (2xx/4xx).

It is not win_rejected when:

What your wallet did	What we do instead
Accepted the win (`status` `1` / `OK`)	The win is paid once; nothing is held.
Did not answer, timed out, or answered something we cannot read	The win stays pending and our cron sends it again with the same `uniqid` (backoff 5, 10, 30, 60, 120, 300, 600 minutes). See Handling Timeouts.
Answered `status -1` inside an HTTP 5xx error	Treated as not delivered (your server failed, it did not decide): pending and resent, as above.
Refused the bet	The round never starts; nothing is debited and there is no win to hold.

What you (the operator) see

The request we sent you: one balance_adj call — type=win, the round's gpid, the amount, the uniqid (our idempotency key for this transaction), signed with HMAC-SHA256 like every call.
The refusal you sent back: your own status (0/-1) and errormsg. We store it on our side of the transaction ledger with the reason rejected, and it is shown on our support list of held rounds.
The round id: the gpid in the request is the round. In our database that round keeps status = ok (it does not block the player's next game) and gets wallet_state = win_rejected.
The player: sees a message that the win could not be credited ("Communication error … please wait a few minutes or contact support") and can keep playing. Their balance shows what your wallet reports — the bet taken, the win not added.

What you should do

Find out why your wallet refused the win (a closed account, a limit, a fraud rule, a currency mismatch, a bug).
Decide with us:
- Pay it: we resend the win by hand with the same uniqid. Your wallet must treat a repeated uniqid as already processed (answer OK and move no money the second time) — so even if the resend is sent twice, the player is paid once.
- Do not pay it: the round stays held with its record; nothing is ever sent automatically.
Never credit the player on your side and ask us to resend — that is the only way the win could be paid twice.

NOTE: a repeated uniqid must always be answered as already processed. This is the same idempotency rule that protects every retried balance_adj call.

How we see it on our side

Round analysis: our crash analyzer reports such a round as held, win rejected — it never proposes to credit the base win.
Support list: our support team has a list of every held round: round id, player, game, date, amount, currency and the refusal text your wallet sent, newest first.
Game replay: the replay shows the round's outcome (what the reels drew and what it would pay). It does not yet say that the win was refused and held; until it does, our support checks the round's wallet_state and the list above.

Why we hold instead of retrying

A definitive "no" from your wallet is a business decision, not a network glitch. Resending it automatically could pay a win your system deliberately blocked; crediting it locally would create money your wallet never agreed to. Holding keeps both ledgers honest and makes the decision visible to a person.

The wallet states of a round

Value	Meaning
`unmoved`	No money moved for this round yet. On a seamless-wallet round this is also the normal state after a settled spin: its win is read from the transaction ledger.
`bet_taken`	The bet was debited, the outcome is not settled yet.
`paid`	The round's base win was credited (local balance).
`paidjp`	The round's jackpot win was credited.
`win_rejected`	Seamless wallet only: your wallet took the bet and definitively refused the win; nothing paid, nothing resent, held for a manual decision.