Stripe Payment Links Attribution: How to Track Revenue From No-Code Checkouts

About 68% of revenue that flows through Stripe Payment Links lands in your reporting as "direct" or "unattributed" — a channel that does not exist in any budget line you actually spend against.

The reason is structural, not a tagging mistake you can fix with one more UTM.

A Stripe Payment Link is a page hosted on Stripe's own domain, and the moment a visitor clicks through from your site, ad, email, or Discord message, the browser crosses an origin boundary that quietly drops the referrer and severs the session your analytics was counting on.

For no-code teams this is the whole appeal and the whole problem at once. You paste a buy.stripe.com link into a landing page or a newsletter and start collecting money in minutes with zero engineering.

But that same convenience means there is no checkout SDK on your domain, no data layer, and no obvious place to record which campaign produced the sale.

The charge shows up in your Stripe dashboard with a customer email and an amount, and nothing else.

Attribution for Stripe Payment Links is the practice of tying revenue collected through Stripe's no-code hosted checkout pages back to the specific marketing click, campaign, or partner that caused it — despite the cross-domain hop that strips the original session.

Why This Matters for Your Revenue

When two-thirds of your Payment Link revenue is unattributed, every channel decision downstream is a guess.

You cannot calculate the true return on a newsletter sponsorship, a Reddit ad, or an affiliate push if the money those channels drove is pooled into an anonymous "direct" bucket.

Founders routinely cut the exact channel that was quietly funding the business because its conversions were invisible, then watch revenue soften a month later without understanding why.

Misattribution does not just distort a dashboard; it moves real budget to the wrong place.

The stakes compound with subscriptions. A Payment Link that starts a $49/month plan is not a $49 event — it is the first payment of a customer whose lifetime value might be $900.

If you never learned which channel opened that relationship, you cannot compute channel-level LTV, you cannot bid correctly on ads, and you cannot pay affiliates on recurring revenue with any confidence.

The cost of unattributed Payment Link revenue is not a reporting gap. It is systematically underfunding your best acquisition source and overfunding your worst, month after month, until the growth curve flattens and no single report tells you the cause.

Why Payment Links Break Standard Attribution

To fix Payment Link attribution you have to understand exactly where the trail goes cold. Three separate mechanisms conspire, and most tools fail at all three at once.

The cross-domain hop strips your session

Your marketing site runs on yoursaas.com. A Payment Link runs on buy.stripe.com or checkout.stripe.com. These are different origins, which means any cookie your analytics set is same-origin to your site and invisible on Stripe's page.

On top of that, the browser withholds your full URL as a referrer in most modern configurations, and Safari's Intelligent Tracking Prevention actively caps the lifetime of the client-side cookies you were relying on.

The session that knew the visitor came from a Google ad simply does not exist by the time Stripe records the charge.

This is the same cross-domain failure that breaks tracking between www and app subdomains, except worse: you do not control Stripe's domain at all, so you cannot drop a script or a first-party cookie on the checkout page to bridge the gap.

There is no data layer on a no-code checkout

Tools built for e-commerce assume a JavaScript checkout you own — a Shopify theme, a custom Stripe Elements form — where a pixel can fire a purchase event with campaign data attached. A Payment Link gives you none of that.

There is no window.dataLayer, no place to inject a conversion script, and no on-page event you can hook. The purchase happens entirely inside Stripe's UI.

Any attribution model that depends on a client-side purchase event is structurally blind to Payment Links.

This is why teams that migrate a working GA4 e-commerce setup to Payment Links watch their conversion tracking collapse overnight. The pixel never fires because there is no page it can fire on.

UTMs on the link do not reach the charge

A common instinct is to append ?utm_source=newsletter to the Payment Link URL. Stripe will happily accept the URL, but by default it does nothing with those parameters — they are not written to the resulting charge, the customer, or the subscription.

The UTM lives for exactly one page view and then evaporates. Unless you explicitly configure the Payment Link to capture that data into metadata, the campaign string never touches your revenue records.

This is a specific instance of the broader problem we cover in the complete UTM-and-Stripe attribution guide: UTMs are a client-side convention, and revenue lives server-side, so something has to deliberately carry the value from one world to the other.

The Two Mechanisms That Actually Survive

Everything reliable about Payment Link attribution comes down to getting a stable identifier from the click into a field that Stripe persists on the charge. There are exactly two such fields, and both are worth using together.

Client reference ID: the built-in carrier

Stripe Payment Links accept a client_reference_id query parameter. When you append ?client_reference_id=CLICK_abc123 to the link, Stripe stores that string and echoes it back on the checkout.session.completed webhook event.

This is the single most important field for no-code attribution because it is designed to survive the exact hop that destroys everything else — the value you set on your side reappears, unchanged, on Stripe's side after payment.

The catch is that client_reference_id holds one value. You cannot pack a full campaign object into it.

The correct pattern is to store an opaque first-party click ID there — an identifier your own system generated when the visitor first landed — and keep the rich campaign data (source, medium, referrer, landing page, timestamp) in your own store keyed by that ID.

Metadata: the durable record on every charge

The second mechanism is Stripe metadata. You can configure a Payment Link to write key-value pairs — utm_source, utm_campaign, affiliate_id — onto the resulting PaymentIntent, customer, or subscription.

Unlike a URL parameter, metadata is permanent: it lives on the object forever, survives refunds and upgrades, and is queryable through the Stripe API.

This is the field we recommend as the backbone of any durable setup, and it is covered in depth in our guide to storing the marketing source on every charge.

The reconciliation is server-side by design, which is why it does not care about ad blockers or Safari ITP.

As Stripe's own webhook documentation notes, the completed-session event is delivered from Stripe's servers to yours, well outside the browser where client-side tracking dies.

• client_reference_id — one opaque click ID, echoed back on the completed session. Best for linking to your own campaign store.
• metadata.utm_source / utm_campaign — human-readable campaign fields that persist on the charge and subscription forever.
• metadata.affiliate_id — the partner identifier, if a referral drove the sale, so you can pay recurring commissions correctly.

Prefill the identifier before the click, not after

The identifier has to exist before the visitor clicks the Payment Link. That means your landing page generates or reads a first-party click ID on arrival, then rewrites every Payment Link button on the page to append client_reference_id dynamically.

If you wait until checkout to think about attribution, the data is already gone — the campaign context lived in the URL of the page they just left.

Reconcile on the webhook, never in the browser

The join happens when checkout.session.completed arrives at your endpoint. You read the client_reference_id off the event, look up the campaign data you stored under that key, and write the resolved channel back to your attribution system or to Stripe metadata.

Because this is a server-to-server exchange, it is immune to the ad-blocker attribution loss that silently erases client-side conversions.

A Concrete Setup You Can Ship Today

Here is the minimum viable pipeline for a no-code team. It requires one small script on your marketing site and one webhook handler — the only two pieces of code in the entire flow.

Step 1 — Stamp the click ID onto the link

On page load, generate a UUID if one does not already exist, persist it in first-party storage, capture the current UTMs and referrer, and rewrite your Payment Link href to carry the click ID.

1// Runs on your marketing site, before the click2const clickId = localStorage.getItem('cid') || crypto.randomUUID();3localStorage.setItem('cid', clickId);4 5// Record the campaign context under this click ID6const params = new URLSearchParams(location.search);7fetch('/api/track', { method: 'POST', body: JSON.stringify({8  clickId,9  source: params.get('utm_source') || document.referrer,10  campaign: params.get('utm_campaign'),11  landing: location.pathname12})});13 14// Rewrite every Payment Link button to carry the ID15document.querySelectorAll('a[href*="buy.stripe.com"]').forEach(a => {16  const u = new URL(a.href);17  u.searchParams.set('client_reference_id', clickId);18  a.href = u.toString();19});

Step 2 — Resolve the channel on the webhook

When Stripe reports the completed session, join the click ID back to the campaign context you stored and persist the resolved channel on the charge.

1// checkout.session.completed handler2const session = event.data.object;3const clickId = session.client_reference_id;4 5const ctx = await db.clicks.findByClickId(clickId); // your stored context6 7await stripe.paymentIntents.update(session.payment_intent, {8  metadata: {9    utm_source: ctx?.source ?? 'direct',10    utm_campaign: ctx?.campaign ?? '',11    landing_page: ctx?.landing ?? ''12  }13});

Step 3 — Credit the channel, not just the first charge

For subscriptions, write the same metadata to the Customer and Subscription objects, not only the first PaymentIntent.

That way every renewal, upgrade, and expansion inherits the original source, and you can credit lifetime revenue rather than the first payment to the channel that opened the account.

Without this, month two of a subscription looks like anonymous recurring revenue and your best channels appear to stop performing after the first invoice.

Handle refunds so channel revenue stays honest

Attribution is not only about crediting revenue — it is about un-crediting it when money goes back.

Because the source lives in metadata on the charge, a charge.refunded webhook lets you subtract the refunded amount from the exact channel that was credited, so a newsletter that drove ten sales and four refunds shows its true net contribution.

If you skip this, refunded revenue inflates your best-looking channel and quietly distorts every ROI comparison you make.

Where Existing Tools Fall Short

The reason this problem persists is that the popular attribution tools were built for a different checkout shape. They fail on Payment Links in specific, diagnosable ways.

GA4 never sees the purchase

GA4 attribution depends on a client-side event firing on a page you control, tied to a session it can stitch.

A Payment Link fires no such event — the purchase completes on Stripe's domain, GA4's session cookie is same-origin to your site, and the conversion simply never registers.

Even the cross-domain linker in GA4 requires you to inject the Google tag on both domains, which is impossible on buy.stripe.com.

The result is the familiar symptom we document in GA4 not showing revenue by channel: traffic reports look full, revenue reports look empty.

Triple Whale and Northbeam assume e-commerce

Triple Whale and Northbeam are excellent at what they were built for — Shopify and DTC e-commerce with a fixed order schema, a pixel on the storefront, and an ad-spend minimum that makes their pricing rational.

Point them at a SaaS Payment Link and the assumptions collapse: there is no storefront pixel to place, no order object in their expected shape, and no product feed.

They model blended paid performance across ad platforms, not the specific click-to-subscription path a $19/month SaaS actually runs. The tool is not broken; it is simply solving e-commerce, and a no-code SaaS checkout is not e-commerce.

HYROS and ClickMagick rely on their own redirect layer

HYROS and ClickMagick attribute by routing clicks through their tracking domain and firing a pixel at conversion.

On a Payment Link there is no conversion page to host their pixel, so the completing sale is invisible unless you also build the exact server-side webhook join described above — at which point you are doing the hard part yourself and paying their premium for the part that no longer matters.

PixelMe has the same structural gap: it shortens and tags the inbound link but has nowhere to observe the Stripe-side completion.

How TrackRev Handles This

TrackRev was built for exactly this checkout shape — no-code, hosted, server-recorded — rather than retrofitted from an e-commerce pixel.

It connects to your billing provider directly and reads the identifiers you stamp on each Payment Link, so the reconciliation that would otherwise be your webhook handler becomes a connection you configure once.

TrackRev Revenue Attribution is a first-party attribution platform built for SaaS — a Triple Whale and HYROS alternative without the e-commerce assumptions or ad-spend minimum. Connects Stripe, Paddle, Polar, and Lemon Squeezy. $19/month.

In practice that means the click ID you set in client_reference_id and the campaign metadata you write on the charge are ingested straight from Stripe, joined to the first-party click that started the journey, and rolled up into channel-level revenue and LTV.

Because the join is server-side, it survives Safari ITP, ad blockers, and the cross-domain hop that defeats client-side tools.

If you are wiring this into an app, the same pipeline is covered end to end in our walkthrough on attributing Stripe revenue to marketing channels, and the model choice — whether you credit first touch, last touch, or a blend — is laid out in last-touch vs first-touch vs linear attribution.

For teams standardizing on other billing providers, the same approach extends to Paddle revenue attribution without changing the underlying method.

When NOT to use TrackRev for this

If your entire business is a Shopify storefront selling physical products, TrackRev is the wrong tool and Triple Whale or Northbeam will serve you better — they model blended ad performance across a DTC catalog in ways a SaaS attribution platform deliberately does not.

Likewise, if you are a pure e-commerce shop spending six figures a month across Meta and Google and you need media-mix modeling with an ad-spend engine, a purpose-built e-commerce platform is a better fit than first-party SaaS attribution.

And if you genuinely take payments only through a single Payment Link with no marketing behind it — one link, one channel, no ads, no affiliates, no email — then you do not have an attribution problem to solve, and any tool at all is overkill.

TrackRev earns its place when you run more than one channel into no-code checkouts and need to know, honestly, which one is funding the company.