How S2S tracking and postbacks work

1) What is S2S and why is it needed

S2S (server-to-server) tracking is the exchange of events between the servers of the traffic source (your redirector/tracker/network) and the servers of the operator (casino), without dependence on browser cookies and locks.

Postback - an outgoing HTTP request with an event (reg/KYC/FTD/2nd_dep/...) from the sender's backend to the recipient's URL.

Advantages:

Data is not lost due to adblock/ITP/private modes.
Higher accuracy of attribution and quality of billing.
You can securely transfer amount/currency and service flags.

2) Basic chain and roles

1. Click: the user clicks on the ad → your redirector creates a 'click _ id' and logs the parameters (utm, geo, device, sub_id).

2. Redirect: the user goes to the operator's landing, 'click _ id' is pushed to the URL or encrypted.

3. Registration/CCM/deposits occur at the operator.

4. Postbacks: the operator's server sends' registration ',' kyc _ approved ',' deposit _ success', etc. events to your tracker, binding them to the original 'click _ id'.

5. BI/Reporting: you aggregate events across UTM/creative/geo/device sections, consider CPA/ROAS/LTV.

Text scheme:


Ad → Click → [Your redirector generates click_id] → LP/App →
↑             │
└──────── Postback (S2S) ─┘

3) Event identifiers and linkage

click_id (mandatory) - unique ID of the first touch; attribution key.

event_id (yellow) - unique ID of each event (for idempotency).

user_id/ account_id (wholesale) - Player ID on the operator side (transmitted only to S2S).

session_id (wholesale) - for parsing UX/speed.

aff_sub/campaign/ creative_id - sections for analytics.

Rule: click_id is created by you; the operator on its side stores the mapping 'click _ id ↔ user/account'.

4) Event fields: minimum composition

4. 1. Registration

json
{
"event": "registration",  "event_id": "reg_8f9...",  "click_id": "clk_123...",  "account_id": "u_456...",  "geo": "BR",  "device": "android",  "ts_event": "2025-10-21T14:54:12Z",  "ip": "203. 0. 113. 7",  "ua": "Mozilla/5. 0",  "signature": "hmac_sha256(payload)"
}

4. 2. KYC Approved

json
{
"event": "kyc_approved",  "event_id": "kyc_b21...",  "click_id": "clk_123...",  "account_id": "u_456...",  "ts_event": "2025-10-21T15:10:05Z",  "kyc_level": "basic    full",  "signature": "..."
}

4. 3. Deposit (FTD/Repeat)

json
{
"event": "deposit_success",  "event_id": "dep_9aa...",  "click_id": "clk_123...",  "account_id": "u_456...",  "amount": 100. 00,  "currency": "USD",  "is_ftd": true,  "payment_method": "card    pix    crypto    wallet",  "ts_event": "2025-10-21T15:12:31Z",  "signature": "..."
}

Required fields are 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'.

Currency fields are always together with'currency '(ISO-4217) and as numbers, not strings.

5) Security: Signatures and access

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; canonize field order → stable validation.

Short-lived tokens (JWT/opaque) at the authorization level: TTL 5-15 minutes.

Idempotence: Repeat POST with the same 'event _ id' should yield '200 OK' without a double.

IP allow-list and mTLS (if possible) on the prod.

Rate limiting: Protect endpoint from "bursts" and bots.

Prohibition of HTTP redirects from the postbeck endpoint; direct answers only.

6) Reliability: Retrays, queues and order

Queue (Kafka/RabbitMQ/SQS) between event reception and report processing - so as not to lose data at peaks.

Retrai with exponential pause and backoff jitter; limit of attempts and DLQ (dead-letter queue).

The order is optional, but it is desirable to have 'ts _ event' for sorting in BI.

Request/response logs (without sensitive data), correlation by 'event _ id'.

7) Time zones, currency and consistency

All time stamps in UTC ('2025-10-21T15: 12: 31Z').

In reports, specify the project timezone, but store events in UTC.

Store the amounts in the transaction currency and duplicate them in the report currency through a reliable rate (date-time-based FX).

8) Deduplication and business rules

event_id idempotency: Repeat → "already processed."

Deduplication by (click_id + event type + ts-window) as a fallback mechanism.

FTD validity rules: minimum deposit, no bonus "zero" replenishment; Fix in the contract.

Chargeback/Refund are separate "negative income" events for an honest NGR.

9) Confidentiality and compliance

Do not pass PII to URL and front; S2S is a place for sensitive fields.

Store consent (analytics/ads) and version them.

Minimize fields: only what is needed for attribution and billing.

Regularly review retention log policies.

10) Web2App and mobile realities

For applications, bind 'click _ id' ↔ 'install _ id' on the MMP/SDK side.

When there is no deterministic ID (iOS privacy) - use a probabilistic match + server rules, and S2S remains the "truth" for billing.

11) Monitoring and SLAs

Metrics:

Successful/erroneous postbacks (%/min), p95 latency, proportion of retrays, proportion of duplicates.
Event discrepancy between the parties (operator vs tracker) by day.
Delivery delay (ingestion lag) and "failures" by the hour.

SLA (example):

Postback reception availability ≥ 99. 5 %/month
The average delay before writing to DWH ≤ 60 seconds; p95 API response ≤ 500ms.
Desynchronization of data> 3% → mandatory reconciliation of raw logs within 5 working days.

12) Checklists

12. 1. Tech check before launch

Redirector with click_id generation and logs.
Postback endpoint: TLS, HMAC, JWT, IP allow-list, idempotency.
Payload schemes and canonical field order are documented.
Queues + DLQs, Retrays, Error/Delay Alerts.
UTC time, ISO currency, FTD/Refund/Chargeback rules.
Runs in sandbox with fixing reference logs.

12. 2. Operating check (every week)

Reconciliation of "operator ↔ tracker" by the volume of events and amounts.
Analysis of duplicates and "lost" events; audit of retrays.
Checks keys/tokens, lifetimes, and rotation.
View incidents and adjust rules.

13) Frequent mistakes and how to avoid them

1. No idempotency → FTD duplicates in Retrays. → Enter 'event _ id' and store "seen."

2. Different time zones → "floated" D0/D1. → Always UTC in the event log.

3. String sums/comma → parsing errors. → Pass numbers with a period and ISO currency.

4. The signature on the "raw" JSON → breaks from the order of the keys. → Do canonization.

5. No DLQ/Retrays → Loss of events on Microsobes. → Queue + backoff + Alerts.

6. Weak authentication → fake postbacks. → HMAC + JWT + mTLS/IP list.

7. Lack of FTD rules → billing disputes. → Fix the definitions in the contract.

14) Sample requests and responses

14. 1. POST/postback (operator → tracker)


POST /postback HTTP/1. 1
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
X-Signature: sha256=ab12...

{ "event":"deposit_success","event_id":"dep_9aa",  "click_id":"clk_123","account_id":"u_456",  "amount":100. 00,"currency":"USD","is_ftd":true,  "ts_event":"2025-10-21T15:12:31Z" }

Answer:


200 OK
{ "status":"ok", "idempotent": false }

Resend with same 'event _ id':


200 OK
{ "status":"ok", "idempotent": true }

14. 2. Signature error


403 Forbidden
{ "error":"signature_invalid", "hint":"check canonical order" }

15) Incidents and parsing

Symptom: the operator has FTD = 120, you have 117.

Plan:

1. Reconciliation of time range (UTC) and currencies.

2. Unloading raw logs by 'event _ id '/' click _ id'.

3. Search for rejected token/idempotency due to signature/TTL.

4. Additional delivery of "stuck" events from DLQ, reconciliation acts.

16) 30-60-90 implementation plan

0-30 days - Circuit MVP

Launch redirector with 'click _ id' and logs.

Implement the reception of postbacks: HMAC, JWT, idempotency, queues, DLQ, alerts.

Raise the sandbox, run the end-to-end reg/FTD script with test amounts.

Document field schematics and canonization.

31-60 days - Quality and scale

Include monetary events and dual currency accounting (txn & report).

Set up monitoring of p95 latency, discrepancies and retrays.

Sign SLAs/incident procedures; add chargeback/refund events.

In BI, collect showcases: FTD, Payback, D7/D30 ARPU cohorts.

61-90 days - Sustainability and audit

Enter rotation of secrets/certificates, fault tolerance tests.

Perform load tests and "emergency drills" (queue drop/DB).

Formalize reconciliation playbooks and quarterly audit of FTD schemes/rules.

17) The bottom line

S2S tracking is the "backbone" of honest attribution and billing: click_id as the primary key, protected postbacks, idempotency, retrays and strict time/currency hygiene. Add to this transparent FTD validity rules, chargeback events and mature monitoring - and you get a reliable system where each conversion is confirmed by the server and converges in reports to a cent.