Overview

To prevent duplicate processing and ensure data consistency, Splash implements a temporary idempotency mechanism for jackpot contribution requests. This document outlines how Splash handles duplicate requests and defines the boundary where responsibilities shift to the client.

How Splash Implements Idempotency

When a client's user triggers a jackpot contribution request, Splash enforces a 20-minute idempotency window using a compound locking key based on the client's transaction identifier and their unique platform identifier.

Compound Key = [client_transactionId] + [splash_clientUuid]

The Workflow:

1. Initial Request: Splash receives the contribution request, extracts the transactionId, pairs it with our internal clientUuid (identifying the specific client the player belongs to) to form the compound key, and initiates the corresponding withdrawal request.
2. Within 20 Minutes: If an identical contribution request is received within 20 minutes, Splash's internal guardrails will catch the duplicate compound key and prevent a duplicate withdrawal request from being processed on our side.
3. After 20 Minutes: After the 20-minute window expires, the compound key lock is released.

Client Responsibility Shift

❗ Important Note on Edge Cases If a duplicate contribution request is sent by the client after the 20-minute window has lapsed, Splash will treat it as a new request and will forward a subsequent withdrawal request to the client.

In this scenario, it is strictly up to the client to implement their own idempotency checks on their receiving endpoint to ensure they do not process the duplicate withdrawal for the same user/transaction.