Idempotency

The aggregator reuses one transaction_id for every retry of an operation, so the client treats a repeated transaction_id as a repeat: it moves no money again and returns its first answer.

One transaction id per operation

The aggregator generates one transaction_id for each money operation and sends the same one with every retry of it. Your wallet must treat a repeated transaction_id as a repeat: it moves no money again and returns its first answer, with the balance as it was then. A transaction_id that comes again with a different request is refused with DUPLICATE_TRANSACTION, status 409.

Retries

A bet has a deadline of 3 seconds, and an answer at 3,000 ms is still in time. When the deadline passes, or the call ends in a network error or a 5xx, the outcome of the bet is unknown: the aggregator refuses the bet toward the provider and sends your wallet a rollback of it, with its own transaction_id and the bet’s in refers_to_transaction_id. An unknown outcome of a win, a rollback or a round close is retried with the same transaction_id, after 5 seconds, then after twice the last interval up to 10 minutes, with no limit on attempts. A definitive business refusal of a win or a rollback is not retried: the operation is marked for attention, an alert fires and it appears on the reconciliation report.

Rollbacks

A rollback of a transaction your wallet has never seen must be acknowledged with the current balance, and a bet with that transaction_id that arrives later must be refused with DUPLICATE_TRANSACTION. A bet is reversed at most once: a second rollback of the same bet gets the first answer again. A rollback of a win takes its credit back, even when the balance goes below zero, and is never refused with INSUFFICIENT_FUNDS or PLAYER_LIMIT_REACHED. The Rollback page lists the fields.

Requests to the client API

The reads of the client API change nothing and are safe to repeat. A launch has no idempotency key, so every successful real-mode Create a session request creates a new session and a demo launch creates none; no money moves with it. Toward the providers the aggregator applies the same rule as toward your wallet: a matching repeat of a provider callback that has a stored final response gets that response without another call to your wallet, and a changed fingerprint is refused with DUPLICATE_TRANSACTION. While a settlement is still pending, a provider retry can trigger another wallet attempt when the previous attempt is older than 5 seconds.

Was this page helpful?