Server-to-Server Postback Tracking for Forex and Casino Affiliate Programmes

Most disputes between forex brokers or casino operators and their affiliates are not really about commission rates. They are about counting. The affiliate says it sent 40 first-time depositors last month; the operator’s back office says 31 qualified. Without a tracking setup both sides trust, that gap turns into invoices on hold, clawback arguments and good partners quietly moving traffic to a competitor.

Server-to-server (S2S) postback tracking is the standard way to make that counting reliable. This guide explains how a postback flow works, how to define the events that trigger payment, how to reconcile numbers at month end, and the fraud and data-protection checks that belong in the design from day one. It is written for acquisition and affiliate managers at brokers, exchanges and gambling operators, and for the affiliates who work with them.

What a server-to-server postback actually is

With browser-based (pixel) tracking, a script or image tag on the operator’s confirmation page fires in the user’s browser and tells the tracking platform that a conversion happened. It is simple to set up, but it depends on the browser: ad blockers, privacy settings, cross-device journeys and pages that are never reached all cause missed conversions.

A postback removes the browser from the reporting step. The flow is:

1. Click. A user clicks an affiliate link. The tracking platform (or the affiliate’s own tracker) generates a unique click ID and appends it to the operator’s landing URL, for example ?clickid=abc123&aff=457&sub1=campaign-x.
2. Capture. The operator’s site stores that click ID and writes it to the user’s registration record in the CRM or back office.
3. Event. Later, the user completes a qualifying action: passes KYC, makes a first deposit, reaches a wagering or trading threshold.
4. Postback. The operator’s server sends an HTTP request to the tracking platform’s postback URL containing the click ID, the event type and any agreed values. No browser is involved.
5. Attribution. The platform matches the click ID to the original click and credits the affiliate.

The key property is that the click ID is the join key. If it is lost anywhere between landing and the back office, the conversion cannot be attributed, however good the rest of the setup is.

Where click IDs get lost

In practice, most “missing conversion” complaints trace back to a handful of breaks in the chain:

• Redirects that drop query strings. Geo redirects, language redirects and HTTP-to-HTTPS hops sometimes strip parameters. Test every entry URL affiliates are given, in every market.
• Marketing site to client portal hand-off. Brokers often run the marketing site and the trading or cashier portal on different domains or subdomains. The click ID needs to be passed explicitly across that boundary, not assumed to be available.
• Mobile app installs. A user who clicks on the web and registers in the app breaks the chain unless your mobile measurement setup passes the attribution through. Agree in advance how app registrations are attributed.
• Returning users. Decide the attribution window and what happens when a user clicks two different affiliates’ links. Last click within the window is common, but it must be written into the terms, not left to the software default.
• Manual onboarding. Accounts opened by an introducing broker or a sales desk often bypass the web form entirely. If those accounts can also carry affiliate credit, they need a defined process.

Storing the click ID on your own site also has privacy implications. In the UK, PECR requires consent for storing information on a user’s device unless it is strictly necessary for a service the user has requested, and the ICO notes that cookies which are helpful or convenient but not essential do not qualify for that exemption (ICO: cookies and similar technologies). Work out with your data protection lead whether your click-ID cookie needs consent and what happens to attribution when it is refused. The honest answer is sometimes “that conversion cannot be credited”, and affiliates should know that before they sign.

Define qualifying events before you write any code

The postback is only as good as the event definitions behind it. Each event that affects payment should have a written definition in the affiliate terms and a matching technical definition in the back office. For a broker or operator this usually means:

• Registration — a completed account application. Rarely paid on its own in regulated verticals, but useful for funnel reporting.
• Verified account — KYC approved. Define whether this means fully approved or provisionally approved.
• First-time deposit (FTD) — specify the minimum amount, the currency conversion rule, whether bonus or promotional funds count, and whether a deposit that is reversed or charged back within a set period still counts.
• Qualified player or qualified trader — for CPA deals, the activity threshold (for example a wagering amount or a number of trades) and the window in which it must be reached.
• Revenue events — for revenue share, how net revenue is calculated, which costs are deducted, and whether negative balances carry over between months.

Then give every event a stable name and a fixed set of parameters in the postback, for example event=ftd&clickid=…&amount=…&currency=…&txid=…. A unique transaction ID on each postback matters more than it looks: it lets the tracking platform reject duplicates when your server retries a request, and it gives both sides a reference for any disputed line.

If you are still deciding between buying leads and running an affiliate programme, our comparison of forex leads versus forex affiliates covers the commercial trade-offs; this article assumes you are running affiliates.

Securing the postback

A postback URL is an instruction to pay someone. Treat it that way.

• HTTPS only. Never send postbacks over plain HTTP.
• Sign or authenticate requests. A shared secret in the URL is the minimum. A stronger approach is to sign the payload with a keyed hash such as HMAC (RFC 2104) so the receiver can check that the request came from you and was not altered.
• Server-side only. Fire the postback from the back office after the event is confirmed, never from a browser page where the URL can be copied and replayed.
• Allow-list where possible. If the tracking platform supports it, restrict accepted postbacks to your server IPs.
• Minimise the payload. Send the click ID, event, value and transaction ID. There is no reason to send names, emails or phone numbers to an affiliate network.

That last point connects to data protection. Under UK GDPR, an “online identifier” can make information personal data where it relates to an identifiable person (ICO: what is personal data). Click IDs linked to customer accounts may fall into that category, so document what you send, to whom and why, and put it in your data-sharing terms with the network.

Month-end reconciliation that actually closes

Even a well-built postback setup will not match the back office exactly, because payment rules are applied after the event: chargebacks, duplicate accounts, bonus abuse and KYC reversals. The aim is not a zero variance; it is a variance that both sides can explain line by line.

1. Export from both sides using the same keys. Click ID, transaction ID, event type, event timestamp (in one agreed time zone) and value.
2. Classify every mismatch. Typical buckets: postback sent but not recorded (delivery failure), event in back office with no click ID (tracking break), event later disqualified (business rule), duplicate.
3. Fix delivery failures, not just the numbers. Log every postback request and the response code. Retry failed requests automatically, and let the transaction ID stop duplicates.
4. Share the disqualification reasons. An affiliate told “9 FTDs rejected” will assume the worst. One told “4 chargebacks, 3 duplicate accounts, 2 below minimum deposit” can fix its traffic.
5. Close the period. Agree a cut-off after which the month’s numbers are final, and how later clawbacks are handled.

For the wider programme structure — commission models, compliance oversight and partner tiers — see our casino affiliate programme management guide.

Fraud checks to build into the flow

Postback tracking makes counting reliable; it does not make traffic genuine. Common patterns to monitor per affiliate and per sub-ID:

• Click-to-registration time. Registrations seconds after the click, or clustered at unusual hours, suggest automation.
• Device and IP overlap. Multiple accounts from the same device fingerprint or IP range, especially where each receives a bonus.
• Deposit patterns. Clusters of deposits at exactly the FTD minimum, followed by no further activity, are a classic CPA-farming signal.
• Geo mismatch. Traffic from markets the affiliate is not approved for, or where you are not licensed.
• Self-referral. Affiliates registering their own accounts or those of connected people.

Set the rules in the affiliate terms first, then enforce them consistently. Holding back commission for reasons that are not in the contract damages the programme faster than fraud does.

Compliance: tracking does not transfer responsibility

Better tracking also means better oversight, which regulators expect. Great Britain’s Gambling Commission says that when licensees use affiliates for direct marketing, it and the ICO consider the licensee primarily responsible for any breaches (Gambling Commission: affiliates or third parties). Sub-IDs and click-level data make it possible to trace which affiliate, campaign and creative produced a complaint or a non-compliant ad, and to switch that source off quickly. Financial promotion rules for brokers work the same way in practice: if you cannot see where traffic came from, you cannot show you controlled it. Our affiliate marketing service page sets out how we approach this for regulated brands.

Postback data also feeds your own ad optimisation. The same qualifying events you define for affiliates are the ones worth sending back to paid media platforms, which we cover in offline conversion tracking for brokers.

A short implementation checklist

• Every affiliate entry URL tested in every market, with the click ID arriving in the back office.
• Written definitions for each paid event, mirrored exactly in the postback logic.
• Unique transaction ID and retry logic on every postback.
• HTTPS, a signature or secret, and no personal data in the payload.
• Consent position on the click-ID cookie agreed with your data protection lead.
• Monthly reconciliation file format agreed with affiliates before launch.
• Fraud rules written into the terms and applied the same way to every partner.