How attribution works

A referral link supplies an attribution candidate. It does not authorize a merchant account, prove payment, or guarantee commission.

From referral to commission

1. Capture: a visitor arrives with the affiliate’s public token in the via query parameter.
2. Handoff: your website carries that original token into checkout. For Stripe Checkout, the destination is the Session’s client_reference_id.
3. Payment evidence: LiftVector reads authorized provider records and verifies the relationships between checkout, payment, customer, invoice, and subscription where applicable.
4. Attribution and commission: LiftVector resolves eligible affiliate evidence, retains the resulting association, and applies the campaign’s terms to eligible sales.

The integration guide explains the required handoff. A provider connection alone does not identify the visitor, and a browser script cannot intercept arbitrary server-side Session creation.

The public token stays unchanged

Use the affiliate’s current public link token, not an internal affiliate ID or a newly generated visitor identifier. Valid tokens contain 4–64 lowercase ASCII letters, digits, underscores, or hyphens. Values are not trimmed, case-converted, or decoded into an identity.

Only current tokens resolve. If an affiliate changes their tag, old links no longer establish new attribution to that affiliate. Old tags are not reserved or redirected and may later belong to someone else. Existing financial associations and history are not rewritten by a tag change. Update published referral links after a change.

Browser retention

The hosted script uses first-party localStorage, scoped to the merchant:

• The last valid via arrival wins over the previous browser candidate, including when a URL contains multiple via values.
• A candidate expires 30 days after capture. Invalid arrivals do not replace a valid retained candidate.
• Navigation without a referral does not extend expiry. Reloading a URL that still contains a valid via counts as a new arrival; reinitializing the same document does not renew it.
• Storage is local to the website origin and browser. It does not follow a visitor across subdomains, unrelated domains, devices, or browsers.
• Clearing or blocking storage removes reliable retention. A valid current-page candidate can still be used without persistence, and browser privacy settings may shorten retention.

This is a browser candidate window, not a promise that the latest link will replace an established financial association. Server-only capture uses the merchant’s own finite retention policy rather than this hosted-script storage.

Which evidence wins?

For eligible evidence in the relevant merchant and attribution scope:

1. An existing retained financial association wins. A later referral link does not reassign it.
2. For a new association, an applied, recognized affiliate promotion wins over a known direct-link candidate. An unrelated discount code does not erase valid link evidence.
3. A valid direct-link candidate can establish attribution when higher-priority evidence does not apply.

Unknown candidates, incomplete evidence, and conflicting candidates can require review rather than selecting an affiliate arbitrarily. Malformed, foreign-merchant, or ineligible candidates cannot establish attribution. Campaign and affiliate enrollment timing still apply; see campaigns and commissions.

There is also a separate transport rule: merchant-supplied via, client_reference_id, or client-reference-id values are preserved by the relevant browser handoff, even when empty or equal to the captured token. Only script-owned values are refreshed or removed. Resolve reference conflicts in your integration rather than expecting browser capture to overwrite them.

Returning customers and renewals

The connection’s attribution mode determines the association’s scope. Check Settings → Connection → Connection details → How affiliates are matched:

• Customer continuity retains the association for the customer scope.
• Subscription continuity retains it within that subscription, not a different subscription.
• Payment-only attribution requires referral evidence for each sale.

Subscription renewals use the established association without a new referral token or Checkout Session. Direct PaymentIntent and standalone Invoice sales can use retained associations or independent promotion evidence, but do not acquire new direct-link candidates from metadata. LiftVector does not use email matching as financial attribution proof.

What is not payment proof

None of these alone proves an eligible sale:

• Opening a referral link or seeing a stored browser token.
• Reaching a success page or completing an unpaid Checkout Session.
• Installing the script or confirming Website integration.
• Copying referral values into lv_affiliate_token, affiliate_id, or affiliate_link_token metadata.

Missing tracking must not stop a normal purchase. A purchase may remain unattributed rather than inventing an affiliate. Missing or incomplete provider evidence must not be treated as a confirmed zero or a successful commission calculation.

Use troubleshooting to check browser capture, provider handoff, and financial evidence separately.