← Back to blog

Polar Affiliate Tracking: How Attribution Actually Works

7 min readGraham Caldwell
Polar Affiliate Tracking: How Attribution Actually Works

When you search for Polar affiliate tracking, you get a strange mix: a sports watch brand, a Shopify analytics tool, and a handful of affiliate software homepages that all say “works with Polar” without explaining how. So let’s answer the actual question. Polar.sh has no built-in affiliate feature, and affiliate tracking on Polar works by carrying a referral ID through checkout metadata and reading it back out of Polar’s webhooks when money moves. That’s the whole trick, and this article walks the entire chain: what fires on the click, how the referral survives to checkout, and which webhook events turn a sale into a commission.

I should say where my incentives point: I’ve spent the last couple of years building Rekomi, which is one of the tools that does this tracking on Polar, so I know these webhooks the way you know your own commute. Everything below names the exact fields and events, on purpose – it means you can verify every claim against Polar’s own docs, and I’d honestly encourage you to.

The chain at a glance:

The click: a tracking script stores the affiliate’s referral ID in the visitor’s browser for 90 days and logs the click server-side.

The checkout: the referral rides into Polar as metadata.rekomi_ref (API checkouts) or the reference_id query param (checkout links).

The commission: Polar’s order.paid webhook carries that metadata on every paid order, first purchases and renewals alike, so the sale credits the right affiliate automatically.

Does Polar have built-in affiliate tracking?

No. Polar.sh sells checkout, billing, and merchant-of-record tax handling, and it deliberately stops there: no referral links, no commission engine, no affiliate dashboard. What Polar gives you instead is the two ingredients any tracking tool needs: metadata fields that persist from checkout to order to subscription, and a webhook system that reports every payment. That’s actually a great foundation, because it means attribution can be exact instead of inferred.

If you’re still choosing a tool, I keep an honest comparison of every option in best affiliate software for Polar.sh. This article is about what happens under the hood once any of them is running.

How a click becomes a tracked referral

Here’s the play-by-play: your affiliate shares a link like yoursite.com?via=alex. A small script on your marketing site (Rekomi’s is literally one line in your <head>) does two things the moment that page loads:

  • It stores the referral in the browser. The slug alex gets written to local storage with a 90-day expiry, plus a first-party cookie when you’ve set up a custom tracking domain. Rekomi’s script recognizes 19 attribution params out of the box (?via=, ?ref=, ?fpr=, and the rest of the industry’s dialects), so links from a previous tool keep working after a migration.
  • It logs the click server-side. The click record carries the referrer, UTM params, and an optional sub-ID, which is what makes an affiliate’s “which of my posts actually converts?” question answerable later.

Notice what didn’t happen yet: nothing touched Polar. The click lives entirely on your site, waiting. The interesting part is the handoff.

Getting the referral into Polar’s checkout

Polar checkouts come in two flavors, and each has its own carrying mechanism.

Polar’s shareable checkout links accept exactly one per-visitor query parameter: reference_id. Whatever you append there lands in the generated checkout session’s metadata. So a buy button that points to buy.polar.sh/your-product?reference_id=alex quietly carries the referral, and Rekomi’s script appends it to Polar checkout links on your page automatically. One script tag and your no-code checkout is attributable!

API checkouts: stamp the metadata yourself

If you create checkouts server-side with POST /v1/checkouts, you add one field to the request:

metadata: { rekomi_ref: window.Rekomi?.getReferral?.() }

The frontend reads the stored referral, your backend passes it through, done. And here’s the part I find genuinely elegant about Polar’s design: checkout metadata is copied onto the resulting order and the subscription, and renewal orders inherit the subscription’s metadata. Stamp the referral once at checkout and it shows up on every payment that subscription ever makes (month 1, month 14, doesn’t matter).

The webhooks that actually move money

The one money event: order.paid. It fires once for every order that becomes paid, and its billing_reason field tells you why: purchase (one-time sale), subscription_create (first charge), subscription_cycle (renewal), or subscription_update (plan change). A tracking tool that listens to this single event catches every dollar.

The trap to avoid: order.created. It looks tempting, but it fires with status pending on renewal orders before payment succeeds. Credit commissions off order.created and you’re paying affiliates for renewals that may never collect. This is the kind of subtle difference that separates tracking tools on Polar, and it’s very much worth asking any vendor which event they key on.

The supporting cast: subscription.created, canceled, uncanceled, and revoked track the subscription’s lifecycle (they move no money, but they’re how a dashboard knows a customer churned), and refund.created / refund.updated drive clawbacks. Polar reports each refund as its own object with its own amount, so partial refunds reverse commission proportionally. A $12 refund on a $30 order at a 25% commission claws back exactly $3, and the affiliate’s ledger shows why.

One more detail worth knowing: refund amounts on Polar are pre-tax, and commissions are calculated on the pre-tax net too. Polar is the merchant of record, so your affiliates earn on the sale, never on someone’s VAT.

Who gets the credit: the attribution ladder

When order.paid arrives, the tool resolves the affiliate in a strict order. Rekomi’s ladder on Polar looks like this:

  1. metadata.rekomi_ref: the explicit stamp wins every time.
  2. reference_id: the checkout-link fallback. If a brand already uses reference_id for its own order IDs, a value that matches no affiliate just falls through harmlessly.
  3. Customer history: if this Polar customer has a prior attributed purchase, the new order credits the same affiliate. This is the net that catches renewals, upgrades, and repeat purchases where no metadata made the trip.
  4. Nobody: the sale records as unattributed, and it sits in a review queue where you can credit it manually if an affiliate raises a hand.

What happens when two affiliates both touched the same visitor? Last click wins: if someone clicks Alex’s link on Monday and Blair’s link on Thursday, Thursday’s referral overwrites Monday’s in the browser. It’s the standard convention across the industry, and it keeps the rules simple enough that affiliates trust them.

Polar affiliate tracking flow from click to rekomi_ref metadata to order.paid webhook to commission

What Polar affiliate tracking honestly can’t do

Every platform has edges, and I’d rather you hear them from me than discover them in month three.

No dispute webhook exists. Polar sends webhooks for refunds but has no event at all for chargebacks or disputes. That means a lost dispute is invisible to every tracking tool on the platform – not a Rekomi limitation, a Polar one. If a chargeback lands, you invalidate the conversion manually and the commission reverses through the same audit trail. In practice disputes are rare for the developer-tool products Polar hosts, but “rare” isn’t “never,” so it belongs on this page.

Coupon codes don’t attribute on Polar. On some platforms a discount code can act as the referral itself (an influencer says “use code ALEX10” and the sale credits Alex with no click at all). Polar’s order events don’t make that reliable, so on Polar a code-only promotion attributes through customer history at best. If code-based attribution is central to your program, that’s a real consideration when picking a checkout platform.

Cross-device has the usual physics. The referral lives in the browser that clicked. If someone clicks on their phone and buys on their laptop, the metadata never makes the trip, and only customer history (or the affiliate asking you to credit it) recovers the sale. No tool on any platform truly solves this without doing creepy things, and I’d be suspicious of one that claims to.

What your affiliates see

The affiliate’s side of all this plumbing is a dashboard: clicks, referrals, conversions, and a running commission balance. The mechanics above are what make the recurring math work, and I love how much work that one metadata field ends up doing. A $30/mo product at 25% pays the affiliate $7.50 every month the customer stays, because every subscription_cycle order inherits the original referral. Twelve months of retention turns one referred signup into $90, and your affiliate never had to do anything twice!

The affiliate dashboard in Rekomi showing earnings, pending payouts, and a campaign link with a coupon code (demo data)
The affiliate dashboard view in Rekomi (demo data)

When commissions become payouts, Rekomi handles the money movement itself in 165+ countries (Stripe Express in 42, bank deposits in 60 more, PayPal in 66 more), tax forms included. That part’s beyond this article’s scope, but it’s covered in the Polar affiliate program setup guide.

Polar affiliate tracking FAQ

Does Polar.sh have a native affiliate program feature?

No. Polar provides checkout metadata and webhooks, and third-party tools build the tracking, commissions, and payouts on top of them.

How long does the tracking window last?

With Rekomi, 90 days from the click. The referral is stored in the visitor’s browser and any purchase inside that window attributes to the affiliate.

Do subscription renewals keep paying the affiliate?

Yes. Polar copies checkout metadata to the subscription, renewal orders inherit it, and every order.paid with billing_reason: subscription_cycle credits the original affiliate. Customer history backs this up even if metadata is missing.

What happens to the commission when a customer refunds?

The commission reverses automatically. Polar’s refund webhooks report each refund with its own amount, so full refunds claw back everything and partial refunds claw back proportionally.

Not reliably. Polar has no dependable code-to-affiliate signal in its order events, so code-only sales attribute through customer history at best. Use links as the primary mechanism on Polar.

See the chain run once

The fastest way to trust a tracking system is to watch it catch one sale. Connect your Polar organization (the Polar integration takes one access token), click your own test link, run a sandbox checkout, and watch the conversion land with your test affiliate’s name on it. Ten minutes, and you’ll never have to take my word, or anyone’s, for how Polar affiliate tracking works: you’ll have seen it.

Try Rekomi

Run an affiliate program that compounds revenue.

Native attribution for Stripe, Paddle, Braintree, and more (any other gateway with a small code snippet), refund-aware payouts, a built-in creator network. 14-day free trial. No card needed.

Ready to start your campaign?

Ten minutes to first click.

14-day free trial. Native Stripe, Paddle, Braintree, and more. No card. Live this afternoon.

  • 14-day free trial
  • Cancel anytime, $0 charged