Some flows have nowhere to put metadata: a link you share by e-mail, a checkout opened by a third-party tool, a reseller. The payment still reaches your dashboard — it simply arrives with no visitor attached.
There are two routes back, and the first is better.
The buyer comes back with a checkout id
Polar can send the customer to your own page after they pay, with the checkout session's id on the URL. Our script reads it when they land and joins the payment to that visit.
Set the success URL with Polar's placeholder:
https://yoursite.com/thank-you?checkout_id={CHECKOUT_ID}Polar replaces {CHECKOUT_ID} with the real id. The braces are literal — type
them exactly as written.
Replacing the braces with an id of your own attributes every payment to the same visit. The placeholder is substituted by Polar at redirect time; it is not a value you fill in.
Nothing else is needed. The script is already on your thank-you page, and the reference rides the pageview it was going to send anyway.
What this cannot do
It attributes the first payment only. The redirect happens once, when the customer buys. Renewals are charged without anyone visiting your site, so those payments arrive unattributed.
It needs the customer to come back. A visitor who closes the tab on Polar's confirmation page never reaches your success URL, and that payment stays unattributed even though it succeeded.
Or match on the e-mail address
When there is no success URL to configure at all, tell us the address the customer paid with:
window.truestat("payment", { email: "customer@example.com" });Fire this on your own success page, with the address used at checkout.
Why this is weaker
The match needs the address to be identical. A customer who pays with a work address and signed up with a personal one stays unattributed, and there is no way for us to know the two are the same person.
It also cannot tell one visit from another. Metadata carries a session id as well as a visitor id, so it can say which visit produced the sale; e-mail matching can only say which person did.
Firing it twice is safe. Only a payment that is still unattributed is ever filled in, so a success page the customer reloads changes nothing after the first time.
Prefer metadata wherever you can
Both routes here are recoveries. The Checkout API and checkout links attach the ids at the moment of purchase, and those carry onto every renewal for the life of the subscription without the customer having to do anything.
With Polar there is a second reason: metadata is the only route that reaches your history. Polar returns it on listed orders, so payments made before you connected arrive already attributed — which neither of the routes on this page can do.