Postback URL explained: how it differs from a pixel and a webhook

A postback URL is a callback link owned by the platform that sent you a click, such as an affiliate network or a tracker like Voluum.

After a sale, your server calls the link carrying the click ID and order value, and the platform logs the conversion without any browser.

A conversion pixel instead fires from the thank-you page and relies on a cookie to find the click. The difference matters most for subscriptions.

A thank-you page loads once, so a pixel on the page sees payment 1 of 12, while a server-side postback can report all 12 payments of a $49 plan.

The sections below compare 3 methods, including the Meta Pixel and Conversions API, and walk through a 6-step Stripe Checkout setup with code.

What does a postback URL look like?

Voluum's documentation describes server-to-server (S2S) tracking as a server on the offer owner's side passing conversion data back to the platform the visitor came from.

In Voluum's version, cid is the only required parameter, and 9 optional ones follow: payout, txid, et, currency and param1 to param5. The txid value is a unique ID per conversion, so 1 visitor can produce several.

The round trip has 2 legs, shown in the code block. First the platform appends a unique click ID to the visitor's link. Then your server returns the ID with the order value after the sale.

For example, a $49.00 order for click 7f3a91c2 reports payout=49.00 and currency=usd. Reusing the txid on a resend lets the platform drop the duplicate, and the Stripe Session ID, such as cs_live_a1B2c3, makes a stable txid.

1. The platform sends the visitor to your site with a click ID
   https://yoursite.com/pricing?clickid=7f3a91c2

2. Your server reports the paid order
   https://tracker.example.com/postback?cid=7f3a91c2&payout=49.00&currency=usd&txid=cs_live_a1B2c3

Sources: doc.voluum.com/article

How does pixel tracking work and where does it lose sales?

A conversion pixel is an image tag or script on the post-payment page.

Voluum's pixel documentation says the click ID sits in a browser cookie read by the thank-you page, the pixel stops working when cookies are disabled, and the pixel is the fallback for platforms without S2S postbacks.

More on the browser side in server-side vs client-side click tracking. A pixel works in 3 steps: the visitor clicks, the cookie stores the click ID, and the thank-you page fires the request. The pixel and the cookie fail separately.

A visitor can close the tab before the thank-you page loads, or a browser can delete the cookie first.

As of October 2026, the table lists how 6 browsers and blockers treat the cookie, and your loss depends on your browser mix.

Sources: doc.voluum.com/article

What a thank-you page pixel misses on renewals

A monthly subscriber loads the thank-you page once, so a pixel on it fires for the first payment only. Take a program that pays a 20% recurring commission. A $49 plan pays $117.60 over 12 months.

Measuring your own loss

Count the paid, non-refunded Stripe checkouts from the last 30 days that carried a click ID, then count what the platform logged. Suppose 120 checkouts earn a $9.80 commission each. A 10% undercount leaves $117.60 uncredited.

Postback URL vs pixel tracking in 6 scenarios

For a sale that a processor confirms, I treat the postback as the record and the pixel as optional. The 6 rows use a $49.00 sale.

How does a postback URL differ from a webhook?

Both are HTTP requests with event data. Ownership differs. Stripe picks the payload, signs it and retries failures (see Stripe's webhook documentation).

A postback is the receiver's endpoint, so the platform fixes the URL and parameters and you own the retries. A webhook flows from the platform to your server, usually as a JSON body with a signature header.

Stripe's libraries tolerate 5 minutes of clock skew by default, and Stripe retries for up to 3 days. A postback flows from your server to the platform, usually as query parameters.

You retry, because the platform never learns the call failed. Verification differs as well: a webhook carries a signature header, and a postback may rely on a secret token or an IP allowlist set by the platform.

TrackRev's outbound webhooks make 3 attempts inside a 10 second budget. Duplicates are handled differently too: dedupe a webhook on the event ID, and dedupe a postback on the transaction ID.

How do you send a postback from a Stripe sale?

The 6 steps use Stripe Checkout and run in order: save the click ID, pass the ID to Checkout, fire on paid, verify the signature, send the postback, and resend after downtime.

Paddle's route is custom data and Polar's route is checkout metadata (see Paddle checkout attribution with custom_data).

For subscriptions, save the Stripe customer ID next to the click ID after the first sale, because renewals arrive as invoice.paid events without the session's reference. Alternatives are in Stripe metadata attribution setup.

Stripe amounts use the smallest unit, so 4900 USD is $49.00, while JPY and KRW have no minor unit. Dividing every amount by 100 is wrong for yen and won.

Pass the click ID in client_reference_id, which allows 200 characters, while metadata allows 50 keys. A free trial reports paid with a $0 invoice, so require an amount above 0.

1import Stripe from "stripe";2 3const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);4const ZERO_DECIMAL = new Set(["jpy", "krw"]); // check Stripe's currency list for the rest5 6export async function POST(req: Request) {7  const raw = await req.text(); // raw body, required for the signature check8  const event = stripe.webhooks.constructEvent(9    raw,10    req.headers.get("stripe-signature")!,11    process.env.STRIPE_WEBHOOK_SECRET!,12  );13 14  if (!event.livemode) return new Response("ignored test event");15  if (await alreadyProcessed(event.id)) return new Response("duplicate");16 17  if (18    event.type === "checkout.session.completed" ||19    event.type === "checkout.session.async_payment_succeeded"20  ) {21    const s = event.data.object;22    const clickId = s.client_reference_id;23    // For delayed methods, "completed" arrives unpaid and is skipped here.24    if (s.payment_status === "paid" && clickId && (s.amount_total ?? 0) > 0) {25      const cur = s.currency ?? "usd";26      const amount = ZERO_DECIMAL.has(cur) ? s.amount_total! : s.amount_total! / 100;27      await firePostback({ clickId, amount, currency: cur, txid: s.id });28    }29  }30 31  await markProcessed(event.id);32  return new Response("ok");33}34 35async function firePostback(p: { clickId: string; amount: number; currency: string; txid: string }) {36  const url = new URL("https://tracker.example.com/postback");37  url.search = new URLSearchParams({38    cid: p.clickId,39    payout: p.amount.toFixed(2),40    currency: p.currency,41    txid: p.txid,42  }).toString();43  const res = await fetch(url, { signal: AbortSignal.timeout(5000) });44  if (!res.ok) throw new Error("postback failed with " + res.status); // Stripe retries the event45}

When is a pixel still the better tool?

A pixel is the better tool when the receiving platform accepts nothing else. Some platforms accept only pixels, as Voluum notes for networks without S2S postbacks.

Ad platforms run both: Meta recommends the Meta Pixel plus the Conversions API, matched on event_id and deduplicated only when the second event arrives within 48 hours of the first (Meta's deduplication guide).

If an affiliate sale fires both, send the same transaction ID in each, or a $49 sale can show up as 2 conversions and $98 of revenue.

In practice, run both where an ad platform recommends both, and keep 1 transaction ID across both.

For example, a $49 sale reported by the Meta Pixel and by the Conversions API with 2 different IDs shows 2 conversions, while 1 shared event_id within 48 hours shows 1 conversion and $49.

How does TrackRev record the conversion?

TrackRev is SaaS affiliate software with link tracking and revenue attribution built in, and TrackRev needs no postback from you.

TrackRev reads the paid charge from Stripe, Paddle Billing, Polar, Lemon Squeezy, Creem or Dodo Payments and joins the charge to the earlier click.

We built TrackRev to record the click on the server at the redirect, with 0 scripts on your destination page.

The visitor ID lives in a first-party vid cookie with a lifetime of 1 year, and the checkout carries the ID in client_reference_id or metadata.

Charges sync hourly through a read-only key with 4 read scopes, or in seconds with 1 optional webhook scope for 3 events. The first sync pulls 30 days.

The join looks in 4 places, ending with the buyer's email, and outbound signed webhooks cover 7 event types, including sale.created.

What does TrackRev write when a sale lands?

On TrackRev's affiliate program, the commission row is written when an attributed sale lands, once per order and partner, and reverses on a refund. The pixel writes its cookie with JavaScript, so Safari's caps on script-written cookies apply to it.

The redirect re-sends the visitor ID on every link click, and email matching, after an identify call, covers purchases with no ID.

There is no postback URL setting: subscribe a webhook to sale.created and map the order or email to your stored click ID. If a network owns your click tracking, use the conversion setup of the network instead.

In our pricing for 2026, Indie costs $29 a month for 1 workspace and 1 tracked domain, and Growth costs $299 a year for up to 10 workspaces. We built the 2 paid plans so neither caps commission tracked.

The free plan covers 50 links and 1,000 tracked events a month.