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 arequestId you have already processed, do not reapply the movement. Return HTTP 200 OK with the player’s current balance.
Recommended implementation
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.
