Postback (S2S) Tracking Setup for iGaming Affiliates

Postback or server-to-server (S2S) tracking is how a casino affiliate program reports conversions directly from its servers to yours. When your referred player registers or makes a first-time deposit (FTD), the platform calls a URL on your tracking domain carrying the click ID you originally passed in, so every conversion is matched to its source click without cookies or pixels. Here is how to set it up correctly and debug it when conversions go missing.

How S2S postback tracking works, step by step

The whole system rests on one identifier making a round trip:

• Step 1 - Click. A visitor clicks your tracking link. Your tracker generates a unique click ID and redirects the visitor to the casino's landing page with that ID appended, for example ?affid=1234&clickid=abc123.
• Step 2 - Storage. The casino platform stores the click ID against the visitor's session and, after registration, against the player account.
• Step 3 - Event. The player registers, deposits, or hits a qualification threshold. The platform's server sends an HTTP GET request to your postback URL, substituting the stored click ID and event data into your macros.
• Step 4 - Attribution. Your tracker matches the incoming click ID to the original click and records the conversion against the right campaign, creative, and traffic source.

Because steps 3 and 4 happen entirely between servers, S2S tracking is unaffected by Safari's ITP, ad blockers, or third-party cookie deprecation, which is why it displaced pixel tracking as the iGaming standard.

Postback vs pixel tracking: why iGaming standardized on S2S

The deposit-timing row is decisive for casino affiliates: an FTD often happens hours or days after registration, when no pixel could ever fire. Only a server-side event can capture it.

Setting up your postback URL and macros

Every tracker (Keitaro, Voluum, Binom, RedTrack, Bemob and similar) exposes a postback endpoint that looks something like:

https://track.yourdomain.com/postback?clickid={clickid}&status={status}&payout={payout}

You register this URL in the affiliate program dashboard, replacing your tracker's placeholder macros with the program's macros. This is where most setups break: each platform names its tokens differently.

Two rules prevent 90% of failures. First, the parameter you send out on the click must be the same parameter the program returns; if you pass your click ID in aff_sub but map the postback to subid, every conversion arrives orphaned. Second, URL-encode nothing manually; let the platforms substitute raw values, because double-encoded click IDs will not match.

Which events to request

Ask your affiliate manager to enable separate postbacks for registration, first deposit, and (if offered) subsequent deposits or a 'qualified player' event. Distinct events let you compute reg-to-FTD rates per traffic source, which is the single most useful optimization metric in casino traffic. If you run CPA deals, the qualification event, not the raw FTD, is what actually pays, so track both and watch the gap. Our CPA vs revenue share guide explains how qualification thresholds change which event matters.

Testing before you spend: the dry-run checklist

• Fire a manual test. Paste your postback URL into a browser with a real click ID from a test click and dummy values. Your tracker should log one conversion. If not, the endpoint or campaign token is wrong.
• Run a full-funnel test. Click your own link, register a test account (tell your affiliate manager first; unannounced self-registrations can flag fraud rules), and confirm the registration postback arrives with the correct click ID.
• Check the S2S log on both sides. Most program platforms (NetRefer, Income Access, MyAffiliates, Affilka and similar) expose a postback log showing each attempted call and the HTTP response code. A 200 on their side with nothing in your tracker means a macro mismatch; a 4xx/5xx means your endpoint rejected it.
• Verify HTTPS and no redirects. Postback endpoints must respond directly; a 301 to another URL will drop parameters on some platforms.

Deduplication, delays, and the other silent conversion killers

Once live, missing or inflated numbers almost always trace to one of these:

• Dedup set too aggressively. Deduplicate registrations by click ID (one reg per click) but never deduplicate deposit events by click ID alone, or every redeposit after the first is discarded. Dedupe deposits on transaction ID instead.
• Batch delays. Some operator platforms fire postbacks in scheduled batches rather than in real time; a conversion 'missing' at noon often arrives by midnight. Confirm the schedule before escalating.
• Cross-device signups. A player clicks on mobile but registers later on desktop by typing the casino name. No click ID exists on the second visit, so the conversion attributes to the operator's direct channel. This is a structural loss; reduce it with bonus codes as a backup attribution layer.
• Truncated click IDs. A few platforms cap sub-ID fields at 32 or 36 characters. If your tracker emits longer IDs, shorten them in settings.
• Firewall rules. If your tracker is self-hosted, whitelist the program's postback IP ranges; a WAF that challenges the request with JavaScript kills a server call instantly.

Compliance and data handling notes for regulated markets

Postbacks should carry identifiers and amounts, never personal data. In regulated markets you should refuse any setup that pushes player names or emails through tracking URLs: it is unnecessary for attribution and creates privacy liability on both sides under laws like Canada's federal privacy statute, PIPEDA, which is overseen by the Office of the Privacy Commissioner of Canada. Keep your tracking domains clean, disclose affiliate relationships on your pages, and remember that in Ontario your operator partners' marketing standards effectively extend to your funnels. When choosing which programs are worth this setup effort, our program reviews note which platforms offer real-time postbacks and per-event logs, and our program terms red flags guide covers the contractual side of the same relationship.

A minimal working configuration, summarized

Outbound link: https://operator.com/promo?btag=1234_{clickid}. Registered postbacks: one for registration, one for FTD, one for deposits, each carrying {clickid}, an event label, a transaction ID, and an amount. Tracker mapping: click ID to click ID, event label to conversion goal, transaction ID as dedup key on deposits only. Test conversion fired and confirmed in both logs before the first dollar of paid traffic. That is the entire system; everything else is naming differences between platforms.

Advanced setups: multi-program routing, sub-IDs and reporting hygiene

Once the basic postback loop works, the value comes from what you layer on top of it. Sub-ID discipline is the first layer: beyond the click ID, most programs accept two to five additional sub parameters, and serious affiliates standardize a schema across every program they work with, for example sub1 for traffic source, sub2 for creative or page, sub3 for keyword or placement. When those values ride out on the click and echo back on the postback, your tracker can answer the questions that actually drive optimization: which article converts registrations into depositors, which source produces FTDs that never redeposit, which placement's players qualify for CPA and which stall at registration. Without the schema, you have conversion totals; with it, you have a business.

The second layer is cross-program normalization. Every platform names events differently: one program's 'qualified' is another's 'CPA triggered' and a third's 'goal 3'. Map them all to a single internal taxonomy in your tracker (reg, ftd, deposit, qualified) on day one, because six months from now you will want to compare programs head-to-head, and renaming historical conversion data retroactively is somewhere between painful and impossible. While you are at it, store the payout value the postback reports, but reconcile it monthly against the program dashboard and the actual payment received: postback-reported revenue is an operational signal, not an accounting record, and drift between the three numbers is your early-warning system for shaved conversions or changed terms.

Third, monitor the pipe itself. Postbacks fail silently: a program migrates platforms, an SSL certificate expires, a macro gets renamed in a dashboard redesign, and your conversions simply stop arriving while clicks continue. Two cheap alarms catch nearly everything: an automated daily check that flags any program with clicks above a threshold and zero conversions over 48 hours, and a weekly comparison of tracker-recorded conversions against each program dashboard, with any gap above a few percent investigated immediately. Affiliates who run these two checks recover missing revenue in days; affiliates who do not typically discover the breakage at month-end, past many programs' claim windows for retroactive crediting. The infrastructure is boring, which is exactly why the affiliates who maintain it well end up with the cleanest data and, over time, the strongest negotiating positions.

19+. This article covers marketing infrastructure and does not encourage gambling; play involves risk and outcomes are never guaranteed. If gambling is affecting you or someone you know, ConnexOntario offers free, confidential support at 1-866-531-2600.

18+ only. Gambling can be addictive — please play responsibly and only bet what you can afford to lose. If gambling is affecting you or someone you know, contact a local support service. This content is informational and never a guarantee of winnings.

Written and reviewed by the iGaming Expert Hub editorial team. Facts checked against primary sources; see the reference above.

← All articles