The mechanics are simple. When an affiliate sends a click, their platform generates a unique click ID and passes it in the tracking link. The operator stores that ID against the player who signs up. When the player converts, the operator's server calls a URL the affiliate configured in advance, the postback URL, appending the stored click ID and event details as parameters: event type, sometimes deposit amount, sometimes currency. The affiliate's platform receives the call, looks up the click ID, and credits the conversion to the right campaign, page and source.
Postbacks typically fire on a chain of events, not just one. A common setup reports registration, FTD, and subsequent deposits as separate postbacks. An affiliate on a CPA deal mostly cares about the FTD postback, since that is the paying event. An affiliate on RevShare wants the full deposit stream, because that is the only way to reconcile reported NGR against observable player activity instead of taking a monthly statement on faith.
Because the call travels server to server, it does not depend on the player's browser. No cookie needs to survive, no pixel needs to load, no ad blocker can intercept it. That is why postbacks are the standard in iGaming, where the gap between click and deposit can span days and several devices. The failure modes are operational instead: a misconfigured URL, a missing parameter mapping, or an operator that silently stops firing on certain events. Testing postbacks before scaling traffic to a new deal is not optional.
Why it matters
Every postback that fails to fire is a conversion you paid to generate and cannot prove. Affiliates who monitor postback health per operator catch discrepancies while they are small, and walk into reconciliation conversations with their own event log instead of relying entirely on the operator's dashboard.
Related