Getting started

Click ID & attribution

The click id is the thread that connects an affiliate’s link to a real order. Carry it from the redirect, through checkout, and back on the conversion — and the right affiliate gets paid.

How attribution flows end to end

Every commission depends on one value travelling cleanly from the click to the sale. The platform generates it; your store carries it; you return it. Nothing else is required for high-confidence attribution.

1. Share. An affiliate shares their tracking link for one of your products.
2. Click. A buyer clicks it and lands on the platform’s tracking endpoint.
3. Redirect. The platform issues a 302 to your store, appending affiliate_click_id and aff_id to the destination URL.
4. Persist. Your store reads affiliate_click_id and keeps it (cookie and/or cart metadata) all the way through checkout.
5. Return. When the order is placed, your server sends that value back as the clickId field on the Conversion API (and on any later Order-status updates).
6. Earn. The platform matches clickId to the original click, and once the order is verified the affiliate earns commission.

The redirect we send to your store

When a buyer clicks a tracking link, the platform redirects them to your destination URL with two query params appended — the click id and the affiliate id:

Example 302 destination

https://merchant-store.com/product/example?affiliate_click_id=CLK_example123&aff_id=AFF_example123

Only affiliate_click_id is needed for attribution. aff_id is informational — handy for your own analytics or for showing an affiliate-specific landing experience — but you never send it back; the click id alone resolves the affiliate.

Capture & persist the click id

Read affiliate_click_id from the URL on the landing page and store it before the visitor navigates away. Persist it for at least the length of your attribution window so a buyer who returns days later still attributes correctly:

Capture on the store front-end (JavaScript)

// 1. On any merchant-store landing page, read the click id from the URL
//    and persist it before the visitor browses away or starts checkout.
function captureAffiliateClick() {
  const params = new URLSearchParams(window.location.search);
  const clickId = params.get('affiliate_click_id'); // "affiliate_click_id"
  const affId = params.get('aff_id');   // "aff_id"
  if (!clickId) return; // direct / organic visit — nothing to attribute

  // Persist for the whole attribution window (cookie + cart metadata are both
  // good — cookies survive page reloads, cart metadata survives cookie loss).
  const maxAge = 30 * 24 * 60 * 60; // seconds; match your attribution window
  document.cookie =
    `aff_click_id=${encodeURIComponent(clickId)}; Max-Age=${maxAge}; Path=/; SameSite=Lax`;
  if (affId) {
    document.cookie =
      `aff_id=${encodeURIComponent(affId)}; Max-Age=${maxAge}; Path=/; SameSite=Lax`;
  }
}
captureAffiliateClick();

// 2. At order completion, read it back and attach it to the order so your
//    server can include it on the conversion call.
function readAffiliateClick() {
  const m = document.cookie.match(/(?:^|; )aff_click_id=([^;]+)/);
  return m ? decodeURIComponent(m[1]) : null;
}

Store the click id in more than one place when you can — a cookie survives reloads, while writing it onto the cart/order record survives cookie loss (private windows, cleared cookies, cross-device checkout). The goal is that the value still exists at order completion.

Send it back on the conversion

At order completion, your server includes the captured value as the clickId field on POST /api/v1/conversions. Send the same clickId again on every POST /api/v1/order-status update for that order so status changes stay tied to the original click:

Conversion payload

// POST /api/v1/conversions  (server-to-server, HMAC-signed)
{
  "externalOrderId": "ORD-1001",
  "orderAmount": "2999.00",
  "currency": "NPR",
  "clickId": "CLK_example123"   // <- the captured affiliate_click_id
}

Order-status payload

// POST /api/v1/order-status  (later status updates for the same order)
{
  "externalOrderId": "ORD-1001",
  "status": "delivered",
  "clickId": "CLK_example123"   // <- same click id ties the update back
}

Full field references and signing details live on the Conversions and Order-status guides.

Tracking confidence: HIGH vs LOW

Every conversion is scored by how reliably it can be tied to a click. The presence of a matching clickId is what separates the two outcomes:

• HIGH confidence — you sent a clickId and it matches a real, in-window click. Attribution is deterministic, and the order proceeds toward commission automatically once verified.
• LOW confidence — the clickId is missing, malformed, or doesn’t match any known click. The platform falls back to weaker signals, does not auto-approve commission, and the conversion may be held for admin review.

A missing clickId is the single most common reason commissions don’t post. If you see conversions landing as LOW confidence, audit step 4 — the value is usually being lost somewhere between the redirect and checkout (a cleared cookie, a re-rendered cart, or a checkout flow that drops query params).

Why a verified click doesn’t pay instantly

Matching the click id is necessary but not sufficient. Two time-based rules decide when a commission actually becomes payable:

• Attribution / cookie window — the click must fall inside the configured window for the order to attribute. A click id sent back after the window has elapsed no longer resolves to that click, and the conversion drops to LOW confidence.
• Return / refund hold — even a HIGH-confidence, attributed order is held for the return/refund period before its commission is approved and released. Order-status updates such as a cancellation or refund inside that hold can reverse or void the commission, which is exactly why you keep sending the same clickId on status changes.

In short: the click id earns the commission, the attribution window decides whether the click still counts, and the return/refund hold decides when the money is safe to pay out.

Next steps: wire up the Conversions API to report new orders, then the Order-status API to keep their lifecycle (delivered, returned, refunded) in sync.