Engineering · By GetBonus · October 18, 2026

Affiliate postback tracking: from click ID to confirmed conversion

A practical server-to-server conversion design covering click IDs, callback verification, duplicate events, status changes and reconciliation.

What a postback does

A postback is a server-to-server notification that reports an event to another system. In affiliate reporting, it can connect a later conversion to an earlier click. Admitad describes publisher postbacks as a way to deliver conversion data directly to a publisher’s system.

A postback is a delivery method, not a guarantee of commission approval. The event might describe a pending action, a confirmation or a later change. Your integration must interpret the provider’s status and event model rather than treating every request as new revenue.

Persist the click before sending the visitor away

Create an opaque click ID and store its partner, offer, placement and timestamp. Pass that ID through a supported provider tracking field. When a callback arrives, resolve the original click from storage. Do not trust a callback’s partner label as a replacement for that relationship.

If the network cannot return your click ID, establish another documented reconciliation key before launching. A report that contains only aggregate campaign totals cannot reliably assign individual outcomes to multiple partners.

Verify and process callbacks safely

Use the authentication or signature mechanism supported by the provider, keep secrets server-side and reject invalid requests. Validate allowed statuses, amount format, currency and transaction identifiers. Do not fetch arbitrary URLs from incoming fields or reflect callback secrets into logs.

Persist a durable event before acknowledging it as accepted. Process events transactionally or through a retryable queue. If your service fails after receipt but before updating totals, replay should complete the update without duplicating it. Keep failed events available for investigation.

Make duplicate delivery harmless

Use a provider-scoped transaction identifier, plus an event or version identifier when available. A duplicate notification should not add a second commission. A later status update for the same transaction should update its state while retaining the event history.

Consider a transaction first received as pending, then approved, then corrected. The approved amount must not be counted once for every notification. When events arrive out of order, use documented provider sequence or update timestamps; otherwise flag the ambiguity rather than inventing an ordering rule.

Reconcile even when callbacks work

Compare stored transactions with periodic provider reports. Missing callbacks, unmatched click IDs and changed amounts should appear in an exceptions list. Track the last successful reconciliation separately from the most recent callback.

• Replay the same event twice and verify unchanged totals.
• Test invalid authentication and unknown click IDs.
• Send status updates in reverse order.
• Interrupt processing and retry the event.
• Compare final partner totals with the source report.

These are implementation recommendations, not a claim that every network supports the same payload. See conversion status reporting for how to present delayed and adjusted results to partners.