Some flows have nowhere to put custom data: a product 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 an order id
LemonSqueezy can send the customer to your own page after they pay, with the order's id on the URL. Our script reads it when they land and joins the payment to that visit.
In LemonSqueezy, open the product and set a redirect URL with a placeholder:
https://yoursite.com/thank-you?order_id=[order_id][order_id] is replaced with the real id. The square brackets are literal —
type them exactly as written.
order_identifier works too, and is a UUID rather than a number:
https://yoursite.com/thank-you?order_identifier=[order_identifier]Either one is enough; there is no reason to send both.
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. LemonSqueezy's own documentation warns that the confirmation modal's button is something a customer may simply not click. When they do not, the payment is still recorded — only its source is missing.
Or match on the e-mail address
When there is no redirect 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. Custom data 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 custom data wherever you can
Both routes here are recoveries. The Checkout API and the overlay 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.