5 min read
Stripe Payment Links Attribution: Use UTMs and a Customer Reference for Different Jobs
Keep campaign labels separate from the evidence connecting a visit to a paid order.
· Grometrics Team
The short version
A campaign can send people straight to a Stripe Payment Link, or send them to your website first. Those are different measurement paths. Before counting a sale against a source, establish which path the buyer followed and what information survived checkout. The Grometrics approach starts with the confirmed payment, then asks which saved visit or customer can actually be connected to it. A label on a URL helps describe acquisition. It does not establish who paid or whether a payment succeeded.
- Use campaign tags to describe acquisition and a customer reference to connect saved records.
- Keep payment confirmation separate from the browser returning to your website.
- Leave the source unknown when the available records cannot establish the connection.
Separate the campaign from the customer
Imagine you share one payment link in a newsletter and another in a community. The product and price are identical, but the campaign labels differ. Those tags can distinguish the two promotions. They cannot identify every person who used a copied link, or prove that the person who clicked is the customer attached to a later transaction. Treat the campaign as context attached to the checkout path, rather than a substitute for customer identity.
Stripe documents five UTM parameters for Payment Links. It also supports client_reference_id as a way to associate a Checkout Session with an internal record. These fields serve different purposes. The reference should point to a saved customer, cart, or checkout record that your system understands. It should not contain a password, a secret, or private personal information. Do not give every buyer the same reference if your aim is to match individual orders.
Decide what can be measured before sharing the link
In a website first journey, save the acquisition context while the visitor is still on your site. When that person starts checkout, preserve an appropriate reference to the saved record. In a link sent directly to hosted checkout, there may be no preceding visit on your website. That difference matters. A successful payment from the second path must not create an invented website session just to make the acquisition report look complete.
Write down the expected evidence for each distribution channel. For a newsletter link, you might know the campaign, the checkout reference, and the eventual payment. For an untagged link copied into a chat, you might know only the checkout and payment. These are legitimate differences in coverage. Comparing them honestly is more useful than assigning the same confidence to every source because all the transactions appear in one table.
Follow one illustrative order through the handoff
Consider a fictional sale of a USD 60 template. A visitor arrives from your newsletter, opens the template page, and starts checkout. Your saved checkout record connects that visit to a reference sent to Stripe. The completed payment can then be reconciled with that record. The USD 60 belongs in the payment total once. Its newsletter attribution depends on that saved connection, not on whether the buyer later reloads a thank you page.
Now change the example. The buyer receives the payment link from a friend and pays without visiting your site. If the link retained a newsletter campaign tag, that label describes the shared link. It is not proof that the newsletter directly reached this buyer. Keep the distinction visible when interpreting the result. Campaign revenue is an attribution statement with assumptions, rather than a complete account of how every customer discovered the product.
Check confirmation and reuse separately
Stripe documents that Payment Links can pass UTM parameters to a configured redirect and include the client reference in a checkout completion event. Review the current Stripe documentation before choosing the handoff. A redirect is part of the user journey. Your revenue record should rely on the confirmed payment state and retain the transaction identifier needed to recognize repeated delivery. A missing browser return must not erase a real payment.
Review three practical cases before trusting a campaign total: a buyer completes checkout and returns, a buyer pays but closes the browser, and the same payment notification arrives again. The expected business result is one payment in all three situations, with attribution only where the saved context establishes it. This is an acceptance rule for your implementation, not a claim that every Payment Link integration already follows it.
Choose a useful reporting rule
For each source, show confirmed payments alongside the number that could be connected to a saved acquisition record. Separate refunds and keep the original payment reference available for reconciliation. If one channel has USD 600 of payments but only USD 360 with a supported source connection, describe both numbers. Do not quietly turn the remaining USD 240 into newsletter revenue because that would make the campaign look more successful.
Start with a small inventory of the links you actually distribute. Record their campaign conventions, whether a website visit comes first, which reference crosses checkout, and how the final payment is matched. That gives you a concrete place to investigate gaps. The goal is a source to payment explanation that survives copied links, missed redirects, and repeated notifications, while leaving genuinely missing evidence visible.
Sources and further reading
READY TO SEE YOUR REAL NUMBERS?
Connect your payment provider and see which channels actually drive revenue.
Start tracking for free →RELATED POSTS