An affiliate postback URL is a request your server sends to the affiliate network or tracker the moment a conversion happens, carrying the click id that was captured when the visitor arrived through an affiliate link. It replaces or backs up the browser pixel, which gets blocked, fires twice, and cannot report refunds. Setting it up means capturing the click id on landing, storing it on the visitor, writing it into the order or lead record, and firing the network's postback or conversion API from the place in your code where the order becomes real. This piece covers the flow end to end, the formats used by Impact, Awin, CJ and Everflow, the publisher side, testing, and the mistakes that make counts drift.
One term to fix early. A postback, also called server-to-server or S2S tracking, is a conversion notification sent machine to machine, from the advertiser's server to the network, rather than from the customer's browser. The click id, sometimes called a transaction id, is the unique token the network appends to the outbound link on each click so the conversion can be attributed to that click and that publisher.
How the click id travels.
The whole system is one token making a round trip. Understanding the trip makes every network's documentation readable.
- Click: the publisher's link goes through the network's redirect, which generates a click id and appends it to your landing URL as a query parameter, such as irclickid for Impact, awc for Awin, cjevent for CJ, or a transaction id for Everflow
- Landing: your site reads the parameter on the first page view and stores it in a first-party cookie or local storage, with an expiry that matches the program's attribution window
- Checkout or form: when the visitor converts, your code reads the stored click id and writes it into the order record or the lead record as a field, alongside the order id and amount
- Conversion: at the point where the order is confirmed or the lead is accepted, your server sends the postback to the network with the click id, order id, amount, currency and status
- Reversal: if the order is refunded or the lead rejected, your server sends an update with the same order id and a reversed status or a zero amount
Two things break this trip more than anything else: the parameter is stripped by a redirect between landing and your site (a country redirect, a www redirect, a consent gate that reloads the page), and the click id is stored client-side but never copied into the order. If it is not on the order, the server has nothing to post.
What each network expects.
Every major network exposes a postback or conversion API that accepts the same core fields. The names differ; the shape does not.
- Impact: the click id arrives as irclickid; conversions are posted through the conversions endpoint of the Impact API or a postback template with the click id, order id, amount, currency, event type and customer status, and modifications are sent against the same order id
- Awin: the click id arrives as awc; server-to-server conversions pass it back with the sale amount, order reference, currency, commission group and voucher code, and the same order reference is used for later validation or decline
- CJ: the click id arrives as cjevent; the server-side conversion call carries it with the order id, amount, currency and item or action identifiers, with corrections posted against the order id
- Everflow: the click id is the transaction id set on the click; the postback URL takes the transaction id, amount and order id, plus optional fields for coupon code and your own custom values, with status and amount updates keyed on the same order id
Read each network's documentation for exact parameter names and endpoints, because they change and because some accept plain GET postbacks while others require an authenticated POST. What does not change is the requirement to send the click id, an order id you will reuse for reversals, an amount, and a currency.
Setting up the advertiser side.
Here is the sequence we follow when we wire a new program or repair one. It is the same on a custom stack and on a Shopify store; only the location of each step moves.
The publisher side: running your own tracker.
Publishers do the same thing in reverse. A publisher running a tracker, whether a self-hosted redirect or a commercial click tracker, places their tracker link as the destination in each network, and the tracker generates its own click id before forwarding to the network's link with that id appended in the network's sub-id or custom parameter. When the advertiser fires the postback to the network, the network fires its own postback to the publisher's tracker with the sub-id, and the publisher sees the conversion against their page, placement and campaign.
This is how a publisher reconciles what their pages sent against what the network paid, and how they spot a merchant whose postbacks stopped. We run this setup on the publisher side of our own portfolio, and it is the reason we can tell within a day when a program has broken tracking. The trade-offs between running through a network, a platform or an in-house program are covered in affiliate networks vs platforms vs in-house.
“If the click id is not written on the order, you do not have affiliate tracking. You have a cookie and a hope.”
Browser pixel vs postback vs API batch.
There are three ways to report conversions to a network. Most programs should run a postback as the source of truth, with a batch API as the reconciliation layer and the pixel as a fallback only.
| Method | Reliability | Dedupe | Refunds and reversals | Setup effort |
|---|---|---|---|---|
| Browser pixel on the thank-you page | Low: blocked by ad blockers and tracking prevention, lost on reloads | Weak: fires again on refresh unless guarded by order id | Not supported: the browser is gone by the time a refund happens | Lowest: paste a snippet |
| Server-to-server postback | High: fires from your server regardless of the browser | Strong: keyed on order id, one call per order | Supported: send a modification against the same order id | Moderate: capture, store, and fire from a webhook |
| API batch upload | High, but delayed: conversions arrive on your schedule | Strong: order id is required in the file or call | Supported: include status changes in the next batch | Moderate to high: scheduled job, file format, error handling |
Testing and weekly reconciliation.
Testing proves the pipe works once. Reconciliation proves it keeps working. Every week we export conversions by order id from each network and join them to our own orders for the same period. Three numbers come out: orders with a click id that the network never received, network conversions with no matching order, and amount mismatches. Each points to a specific failure: the first to a postback that is failing silently, the second to a duplicate or a test that was never reversed, the third to currency or a shipping and tax inclusion difference.
A tolerance of a handful of orders is normal because of timing at the week boundary. A growing gap is a broken postback, and the publisher noticed before you did. The launch checklist in how to launch an affiliate program assumes this reconciliation is running before the first publisher is recruited, and it is part of every program we build under affiliate partnerships.
Mistakes that make affiliate counts drift.
- Running a browser pixel only, which gets blocked for a meaningful share of visitors and fires again every time the thank-you page is refreshed
- Posting back without an order id, so the network cannot dedupe repeats and you cannot reverse a refund later
- Sending the gross amount when the program pays on net, or the wrong currency for a multi-currency store, so commissions are overpaid and disputed
- Mismatched status values, such as posting every lead as approved when your CRM later rejects a share of them
- Forgetting reversals entirely, which pays commission on refunded orders and cancelled leads until a finance review finds it
- Losing the click id to a redirect or a consent reload between landing and checkout, so a share of affiliate orders arrive with no attribution and publishers stop promoting
What is a postback URL in affiliate marketing?
A postback URL is the endpoint at an affiliate network or tracker that an advertiser's server calls when a conversion occurs. The call carries the click id captured at click time plus the order id, amount, currency and status, so the network can credit the right publisher. Because it fires server to server, it is not affected by ad blockers or browser tracking prevention.
How do I pass the click id into my order?
Read the network's click parameter, such as irclickid, awc, cjevent or the Everflow transaction id, from the landing URL and store it in a first-party cookie. At checkout, copy the cookie value into a field on the order: a cart attribute on Shopify, a hidden form field, or a custom property in your CRM. Your postback then reads it from the order record, not the browser.
Should I use a postback or a pixel for affiliate tracking?
Use a server-to-server postback as the source of truth and keep the pixel, if at all, as a fallback. The postback fires from your server when the order is real, deduplicates on order id, and supports reversals for refunds. A pixel is blocked for many visitors, fires again on page refresh, and cannot report anything after the browser closes.
How do I test an affiliate postback?
Click your own tracking link in an incognito window, place a test order, and confirm the conversion shows in the network's reporting with the right amount and order id. Then send a manual postback with a made-up order id and confirm it appears, then send a reversal for it. Reconcile network conversions against your orders weekly to catch failures after launch.