Quick Answer
- Setup S2S tracking iGaming affiliate programs around a durable click ID and a documented postback contract.
- Pass the click ID through every redirect and store it with the player or conversion event.
- Validate signatures, timestamps, statuses, and duplicate events before crediting a conversion.
- Keep a replayable log so missing or disputed conversions can be investigated.
Setup S2S tracking iGaming programs by connecting an affiliate tracker and casino platform through server-to-server postbacks rather than relying only on browser cookies. The flow is simple in concept: an affiliate click receives an identifier, the casino stores it with the player journey, and the casino sends a verified conversion event back to the tracker.

What setup S2S tracking iGaming actually requires
Key Definition: S2S tracking is a server-to-server attribution method in which a conversion system sends an event directly to an affiliate tracker using a stored click or transaction identifier.
| Component | Responsibility | Required decision |
|---|---|---|
| Tracking link | Creates or receives the click ID | Where is the ID stored and how long is it valid? |
| Redirect or landing page | Passes the ID onward | Which parameters must survive every hop? |
| Casino platform | Associates the ID with the account or event | Which event marks a conversion? |
| Postback endpoint | Sends the event to the tracker | How are authentication, retries, and responses handled? |
| CRM and reporting | Reconciles events and lifecycle value | How are duplicates, reversals, and corrections represented? |
Step-by-step implementation
- Agree the conversion vocabulary: registration, verified account, FTD, deposit, revenue, or another event.
- Generate a unique click ID and define its character set, length, and retention.
- Pass the ID through the affiliate link and preserve it across redirects.
- Store it with the player or conversion record using an auditable source field.
- Configure the postback URL with the click ID, event ID, status, timestamp, and approved value fields.
- Sign or authenticate the request and validate it before crediting.
- Test success, retry, timeout, duplicate, reversal, and invalid-signature cases.
A minimal illustrative payload might look like this:
{
"click_id": "abc123",
"event_id": "evt-456",
"event": "ftd",
"status": "approved",
"occurred_at": "2026-08-27T19:05:00Z"
}
This is an example schema, not a universal vendor contract. Map field names to the actual tracker and platform documentation.
Logging, retries, and deduplication
Store the outbound request, response status, retry count, and final attribution state. Use an idempotency key such as the event ID plus click ID. If the tracker returns a temporary error, retry according to a bounded policy. Do not retry indefinitely or credit a conversion every time a retry succeeds.
Implementation warning: do not accept a postback solely because the click ID exists. Validate the origin, signature, event status, timestamp, and duplicate state as separate controls.
Illustrative reconciliation example
If the casino records 120 approved FTD events and the affiliate tracker shows 118, do not assume the tracker is wrong. Compare click IDs, event IDs, time zones, reversals, rejected statuses, and duplicate suppression. The difference may be two late events or two platform records that were never eligible for commission.
Failure scenarios
Redirects may strip query parameters. A player can register on one device and convert on another. The casino may send “pending” and “approved” as separate events. An affiliate can retry the same postback. A firewall may accept the request but block the response. Design for each case and expose the state to support teams.
Conclusion
To setup S2S tracking iGaming programs reliably, define the event contract first and make the click ID, postback, logging, and reconciliation rules work as one system. The payoff is cleaner attribution and a more useful lifecycle record for affiliate and CRM teams. Explore practical CRM data workflows at NowG.net.