Server-to-Server Postbacks vs. Pixels Explained

If you only fix one thing in your affiliate tracking this year, make it this: move your important conversions onto a server-to-server postback. I say that having built tracking software from the database up — I’ve written the code that mints click IDs, catches the postback and matches it to a click — and having sat in all three seats since: affiliate, affiliate manager, and merchant. From every seat, the postback is the part of the stack I trust when money is on the line.

This guide covers what a server-to-server postback is, the click-to-conversion chain, a real postback URL pulled apart, how it compares with cookies and pixels, setup, and the mistakes that quietly lose you commission. For the wider picture first, start with the affiliate tracking overview — this page is the deep dive on the method underneath it.

What is a server-to-server postback?

A server-to-server postback — S2S postback for short — is a conversion notification sent directly from the merchant’s server to the tracking server, with no browser in the loop. When a visitor buys or signs up, the merchant’s system calls a URL you gave it, carrying the identifier that ties the sale back to a specific click.

Compare that to the old way. A pixel or a cookie lives in the visitor’s browser, so anything that interferes with the browser — ad blockers, privacy extensions, cleared caches, a switch to a different device — can break the trail. A postback sidesteps the browser entirely: two servers talk to each other. That is why the technique is so hard to kill.

The mechanism rests on one small thing: a click ID. Everything else is plumbing to keep that ID alive from click to conversion.

How server-to-server postbacks work

Here is the chain the way it runs on a live program, step by step:

1. The click generates an ID. A visitor clicks an affiliate link. The tracker mints a unique click ID — a random string like a1b2c3d4 — and logs it against the affiliate, campaign and timestamp.
2. The redirect carries the ID forward. The tracker redirects the visitor to the merchant’s landing page and appends the click ID to the URL, for example ?click_id=a1b2c3d4.
3. The merchant stores the ID. The merchant’s site holds onto that click ID — in its session, its database, or a field on the order — for the length of the visit.
4. The conversion fires the postback. When the visitor completes the action you pay for, the merchant’s server calls your postback URL and passes the stored click ID back, plus the sale value.
5. The tracker matches and credits. Your server receives the postback, looks up the click ID, finds the original click, and credits the right affiliate.

The fragile joint in any tracking setup is holding the identifier steady between step two and step four. A postback wins because that identifier is stored server-side, not in a cookie hoping to survive a hostile browser.

A real postback URL, pulled apart

The postback URL is the part everyone finds abstract until they see one. Here is a representative example:

https://track.yoursite.com/postback?click_id=a1b2c3d4&payout=42.50&txid=ORDER-9981&event=sale&status=approved

Reading it left to right, the way your server does:

• https://track.yoursite.com/postback — your listener endpoint. Always HTTPS; a postback is a money message with no business travelling in the clear.
• click_id=a1b2c3d4 — the load-bearing parameter, the value the merchant received during the redirect and hands back now. No matching click ID, no attribution.
• payout=42.50 — the commission for this conversion, passed dynamically so different products or tiers report the right amount.
• txid=ORDER-9981 — the merchant’s unique transaction reference, your defence against counting the same sale twice; reject any postback whose txid you’ve already recorded.
• event=sale — the action type, so one endpoint can handle leads, sales and upgrades separately.
• status=approved — the conversion state, distinguishing a pending sale from a confirmed or refunded one.

Those key=value pairs are ordinary URL query parameters, documented plainly in the MDN reference on URL search params. Nothing exotic — that simplicity is exactly why it’s reliable.

Server-to-server postbacks vs. cookies and pixels

The ground has shifted hard under browser-based tracking. Browsers are phasing out third-party cookies, ad blockers strip pixels before they fire, and privacy rules such as the UK GDPR push everyone toward leaner, consent-aware data handling. A method that depends on the browser cooperating is a method on borrowed time.

• Where it fires: cookies and pixels run in the visitor’s browser; a postback fires from the merchant’s server.
• Surviving cookie blocking: cookies don’t survive it, pixels partly do, postbacks do.
• Surviving ad blockers: cookies partly survive, pixels don’t, postbacks do.
• Cross-device credit: weak for cookies and pixels; possible for postbacks via a stored click ID.
• Setup effort: low for cookies and pixels; moderate for postbacks, since both servers have to agree on the click ID.

None of this makes pixels and cookies useless — they’re still fine for simple, same-device, same-session sales, and we cover where each one fits in our wider tracking guides. But for paid media, mobile, and any program where the commissions are big enough to argue over, the postback is the method that keeps counting when the others go quiet. When I moved a program’s paid-media partners onto S2S postbacks, “lost” conversions dropped noticeably in the first month — the affiliates hadn’t improved, we’d simply started counting sales that cookie tracking had been silently dropping all along.

How to set up server-to-server postbacks

The setup is a handshake between two servers that must agree on the click ID.

1. Confirm your tracker mints a click ID. Every click must get a unique ID that survives the redirect to the merchant. If your platform doesn’t do this already, that’s your first fix.
2. Build your postback URL. Define your endpoint and parameters — click ID at minimum, plus payout, transaction ID and event type — using dynamic placeholders, not hard-coded numbers.
3. Hand the URL to the merchant. Tell them exactly which macro maps to your click_id. This is where most setups stall — both sides must use the same field name.
4. Have the merchant store and return the ID. They capture the click ID on landing and fire your postback with it attached the instant a conversion completes.
5. Test end to end before you spend. Run a real click, complete a real conversion, and confirm the postback arrives with the right click ID and payout.
6. Monitor and reconcile. Reconcile your tracker’s totals against the merchant’s sales report weekly. Discrepancies are normal early; unexplained ones are a warning.

Common server-to-server postback mistakes

The usual suspects, from years of watching these break:

• The click ID gets lost in a redirect. A cross-domain hop or a redirect that strips query parameters drops the ID, and conversions arrive with nothing to match. Test every hop, not just the first.
• No duplicate protection. Without a unique txid check, a retried or double-fired postback counts one sale twice — flattering until reconciliation catches it.
• Unsecured endpoints. A postback URL with no secret token or HTTPS is an open door to fake conversions.
• Mismatched field names. You expect click_id, the merchant sends subid. Everything looks configured; nothing matches. Agree the exact macro name in writing.
• Ignoring conversion status. Treating every postback as a confirmed sale means paying commission on orders that later refund. Handle status deliberately, and decide how it interacts with your attribution model.

Choosing tracking software that does postbacks well

Once you understand the mechanics, picking a platform is mostly about how cleanly it handles the postback: reliable click IDs, a flexible postback URL, and duplicate protection. We test the major platforms against exactly these criteria in our affiliate tracking software reviews.

Frequently asked questions

Some links on ClickProfits are affiliate links — see our affiliate disclosure.