Admitad Affiliate Tracking on InSales: Last Paid Click, Done Server-Side

Affiliate networks only pay out correctly if the store reports the truth: which paid click led to which order, and whether that order later cancelled. InSales has no native affiliate attribution, so a store running Admitad traffic was flying blind — paying commissions it couldn't verify and never clawing back cancelled ones. We built a custom InSales ↔ Admitad integration on Admitad's Last Paid Click model that keeps the affiliate stats clean.

The problem: attribution InSales doesn't do

Admitad uses Last Paid Click attribution — the affiliate who delivered the most recent paid click before purchase gets the commission. To honor that, the store must (1) capture the affiliate click identifier when the visitor arrives, (2) persist it through the whole shopping session, (3) report it to Admitad at purchase, and (4) reverse it if the order is later cancelled or refunded. InSales tracks none of this natively, so every step is custom.

Step 1 — capture the click, survive the session

Admitad tracking links carry the affiliate and click identifiers as parameters. We land them and immediately persist the click id so it isn't lost across page views or a delayed purchase:

# Admitad tracking link parameters we parse on landing:
?utm_source=admitad&utm_medium=cpa&utm_campaign=#wm_id#&click_id=#click_id#

// On arrival, persist the click id for the attribution window:
const p = new URLSearchParams(location.search);
const clickId = p.get("click_id");
if (clickId) {
  document.cookie =
    `admitad_uid=${clickId}; max-age=${30 * 24 * 60 * 60}; path=/; samesite=lax`;
}

The 30-day cookie is the attribution window — long enough to cover a normal consider-then-buy cycle. "Last paid click" means a fresh Admitad click overwrites the cookie, so the most recent affiliate always wins, exactly as the model requires.

Step 2 — report the sale server-side, not from the browser

The critical design choice: the conversion is reported to Admitad by a server-side postback, not a browser pixel. A pixel that fires on the thank-you page is lost to ad blockers, missed page loads, and can be spoofed. Instead, on a confirmed order we read the stored click id and send Admitad a postback with the order id and amount from the server:

// On order paid (InSales order webhook → our service):
// send Admitad the click id + a UNIQUE order id + status "confirmed".
// The order id is the idempotency key — resending never double-counts.
POST https://ad.admitad.com/action/  (server-to-server postback)
  uid       = <stored click_id>
  order_id  = <insales order id>      // unique, dedups retries
  amount    = <order total>
  status    = confirmed

Because InSales doesn't expose affiliate data, we bridge it through the InSales API: our service subscribes to order events, joins the order to the visitor's stored click id, and owns the postback. The order id doubles as the idempotency key so a retried webhook never reports the same sale twice.

Step 3 — reverse cancellations automatically

This is where most affiliate setups leak money. When an order is cancelled or refunded in InSales, we catch the status change and send Admitad a reversal for that same order id. The commission that was provisionally approved is clawed back before payout. Without this, cancelled orders quietly inflate affiliate invoices — the single most common source of wrong payouts.

Affiliate tracking isn't the click pixel — it's the full lifecycle: capture the last paid click, confirm the sale server-side, and reverse it when the order dies. Skip the reversal and you pay commission on refunds forever.WS24 — how we build affiliate integrations

The result is an InSales store whose Admitad stats match reality: every paid order attributed to the right affiliate, every cancellation reversed, and no commission paid on sales that didn't stick. Clean affiliate accounting is a plumbing problem, and this is the plumbing.