Skip to main content
All Seamless Wallet calls include a unique requestId. Network timeouts, gateway hiccups, or internal PlayStarters retries can cause the same request to arrive at your endpoint more than once. Your implementation must handle this without re-applying the financial movement.

The rule

If you receive a request with a requestId you have already processed, do not reapply the movement. Return HTTP 200 OK with the player’s current balance.
1

Store processed requestIds

On every successful BET, WIN, or VOID, persist the requestId together with the resulting balance in a transactions table or cache. Use a unique index/constraint on requestId to prevent duplicates at the database level.
2

Check before applying

Before applying a new transaction, look up the requestId. If it already exists, skip the movement and return the previously stored balance.
3

Wrap the read + write in a single transaction

The check, the movement, and the requestId write must be atomic to avoid race conditions when the same request arrives twice in parallel.

Example pseudocode

Idempotency is mandatory. Without it, a single retried BET can debit the player twice, or a retried WIN can credit them twice — both create reconciliation issues that are painful to unwind.