Server-to-Server (Postback) Affiliate Tracking

In affiliate marketing, server-to-server tracking, or postback tracking, records affiliate conversions through a request from one server to another. A referral identifier captured earlier connects the conversion to the affiliate. It reduces dependence on a browser firing a conversion pixel, but still depends on reliable identifiers, integration, and applicable privacy requirements.

What connects the click to the conversion?

The referral identifier is captured before the conversion and stored where the order or customer process can retrieve it. The postback then sends the required identifier and event details to the tracking system. An authenticated server request is useful only if the business event and attribution data are correct.

Postback versus browser pixel

Server delivery avoids depending on a browser loading the conversion page. It does not make the earlier identification stage immune to browser restrictions or lost data.

A hypothetical postback journey

An affiliate referral creates click ID click-42. The merchant stores it with order order-1042. After a qualifying payment, the server sends an event with those identifiers and the eligible amount. The tracker applies attribution and commission rules and returns the integration’s supported response.

If the request times out, a retry may be needed. The repeated event must reference the same action so conversion deduplication can prevent another sale commission. A later refund should be an adjustment to the original sale.

What should an integration test cover?

• Identifier capture through redirects and checkout.
• Required fields, currency, amount, and event type.
• Authentication and permitted sender behavior.
• Successful, rejected, and timed-out requests.
• Duplicate deliveries and delayed conversions.
• Refunds, cancellations, and recurring billing events.

Reconcile the source transactions against the tracker. A delivery log confirms a request’s outcome, but it does not establish that all eligible referrals were captured.

How do postback parameters and retries work?

Map the fields explicitly

The sender and receiver must agree on field names, HTTP method, value format, and event type. A click identifier called click_id in one system will not automatically populate a different receiver field. Preserve its exact value through redirects and checkout, then test the receiver’s recorded result.

Do not put production secrets into example links. Use the authentication mechanism supported by the integration and keep sensitive values in appropriate server configuration. Post Affiliate Pro’s sale tracking protection guidance is a product-specific reference, not a universal postback protocol.

An error-handling checklist

1. Record the source transaction before attempting delivery.
2. Validate required fields and the supported event type.
3. Record whether the receiver accepted or rejected the request.
4. Retry eligible temporary failures without changing event identity.
5. Route persistent errors to an operator for investigation.
6. Reconcile source conversions with accepted tracking records.

Stripe’s webhook guidance provides examples of duplicate and delayed event handling. Use the affiliate receiver’s actual protocol for success responses and retry behavior.

What does a successful postback prove?

It proves only what the response and receiver record establish. The request may have reached the endpoint yet failed validation, lacked an eligible affiliate, or created a pending rather than approved commission. Inspect the recorded event and amount. Technical delivery, attribution, business eligibility, and payout are separate stages that need separate checks.

A reliable postback needs more than a URL

Capture the click or referral identifier at the landing stage and carry it into the customer or order record. When an eligible conversion occurs, the commerce system sends that identifier with a stable transaction ID and the required event details to the tracker.

Authenticate requests using the integration’s supported mechanism and keep credentials out of public URLs and client code. Define what a successful response means, queue failures for retry, and record delivery results. Retrying a request must not create a second commission for the same eligible conversion.

Test lost identifiers, delayed events, duplicate deliveries, refunds, and subscription renewals. Server-side delivery solves one part of the journey; it does not recover referral data that was never captured or authorize processing that lacks the necessary permission.

For the corresponding Post Affiliate Pro settings, consult the s2s tracking documentation . Confirm the configuration and integration requirements against your program’s rules.

Process at a glance