Tracking problems · Marketers, founders and developers
How to Track Campaign Revenue Through Stripe Checkout
Stripe Checkout attribution needs a recorded campaign visit, a visitor reference carried into the server-created Checkout Session, and a supported paid record that can be matched back to that visit. Verify those steps separately before reading campaign revenue. A UTM label, a completed redirect or a connected Stripe account alone does not establish the payment-to-visit match.
1. Identify the Checkout Flow You Actually Use
Start with one website and one purchase path. This guide focuses on a server-created, one-time Stripe Checkout Session with a positive paid result. Your developer creates that Session on your server and sends the customer to its checkout. Hosted Payment Links, subscriptions and standalone PaymentIntents need different checks.
| Payment path | Where to begin |
|---|---|
| Server-created one-time Checkout | Inspect the browser reference, Session fields, paid result and matching payment. |
| Hosted Stripe Payment Link | Check the published link and its supported reference decoration. |
| Checkout subscription / Billing | Inspect the paid invoice and customer linkage, not only the initial Session. |
| Standalone PaymentIntent outside Checkout or Billing | The current native connection does not ingest this route as a supported Checkout payment. |
If your buy button opens a Payment Link rather than calling your checkout endpoint, use the Payment Links workflow. If your question is whether a trial became paid, keep that trial-to-paid review separate from this one-time handoff.
Record the website, Stripe account, test or live mode, currency, dates and timezone. Website tracking and payment access are separate connections. An installation confirmation establishes that the script loaded; it is not proof that this visitor was measured or that a later payment matched.
2. Verify the Campaign Visit Before Opening Checkout
Open the actual campaign URL on the website that starts checkout. Confirm the intended source, medium and campaign survive redirects, then check the recorded visit in Attriboo. Use one consistent campaign label rather than trying to infer a campaign from a payment amount later.
Your developer can read window.attriboo?.getVisitorId?.() in the browser checkout handler and include that value in the request to your existing checkout endpoint. Use the actual reference returned by the standard tracker on this website. It is not a Stripe Customer ID, a Checkout Session ID or your application’s account ID.
The getter can return no reference when measurement is unavailable or tracking choices hold it back. Keep ordinary checkout working in that case. Do not invent a visitor ID, substitute a campaign name or bypass a person’s settings just to make a payment look attributed. A payment without a known visit should remain a matching question.
The reference is also not authentication. Your server must continue checking the customer, authorized product, price, quantity and redirect destinations using the application’s existing rules. Keep private Stripe and Attriboo credentials on the server. The marketing reference only carries a possible join to an already recorded visit.
3. Inspect the Reference on the Created Checkout Session
When client_reference_id is available for this purpose, set it to the actual Attriboo visitor reference in the server-created Session. Inspect the resulting Session record, not just the browser request or the intended server options. Stripe describes client_reference_id as a reference for reconciling a Session with your internal systems.
| Handoff | Evidence to inspect |
|---|---|
| Browser to your server | The actual website visitor reference arrives at the existing checkout endpoint, or is explicitly unavailable. |
| Your server to Stripe | The created Session carries the intended reference without replacing an unrelated business identifier. |
| Stripe to the payment connection | The relevant event reaches the correct account and website connection. |
| Payment to recorded visit | Attriboo’s recorded payment is linked to the expected known visitor. |
Check field priority when your application already uses client_reference_id. The current Attriboo Session reader selects that populated field before Session metadata. A business ID in it can therefore prevent metadata.attriboo_visitor_id from being selected, even when the metadata contains a valid visitor reference. Do not overwrite your business ID or assume adding a second field guarantees a match.
With client_reference_id empty, the reader can select Session metadata.attriboo_visitor_id and verify that reference against this website’s recorded visitors. If the first field must retain a different identifier, have your developer inspect the actual matching result and resolve the integration design before relying on metadata as a workaround. The worksheet below flags this condition explicitly.
Metadata belongs to a particular Stripe object. Session metadata, PaymentIntent metadata and subscription metadata are not interchangeable fields. Stripe documents that metadata generally does not copy automatically to related objects, with specific exceptions and nested creation parameters. Inspect the object and event your integration actually reads.
4. Check the Stripe Connection and Paid Record
In your own workspace, choose the website, open Setup and expand Connect your payment provider. Open Stripe and follow the connection instructions available to your owner or admin account. Connect Stripe sign-in is offered when enabled; the restricted-key option remains available. Confirm the correct account and mode before comparing records.
Where to find itDashboard → Setup → Connect your payment provider → Stripe
The overview retains the website and Setup tabs above the expanded payment step. The Stripe button from the same capture is enlarged below.
Select the overview to open the full screenshot.
Enlarged detail of the outlined area
- Open the website’s Stripe connection
Check the intended Stripe account, mode and connection result. Website tracking is a separate setup step.
Use an existing authorized completed payment or a provider-supported test flow where your connection supports it. Check its Session, amount, currency and paid state. Do not create a live charge merely to follow an article. For this one-time path, the current reader requires mode=payment, payment_status=paid, a positive amount_total and no invoice attached to that Session; invoiced payments follow the invoice path.
A success-page visit is useful context, but it is not a reliable payment notification. Stripe’s fulfillment guide explains that a customer may pay and never reach the return page. It also distinguishes immediate payments from delayed methods that need a later success event. For attribution, inspect actual delivery and supported event coverage rather than assuming every completed Session is already paid.
The current Attriboo handler recognizes the asynchronous success event, but the configured connection’s event selection must also deliver it. Do not assume delayed-method coverage from a successful immediate-payment check. Subscriptions similarly need the paid-invoice and customer-linkage review.
For missing records, check recent event delivery and the connection result before repeatedly importing. The Stripe import covers the last 90 days of supported Checkout and Billing records, up to 1,000 Sessions and 1,000 invoices per run. It does not recreate earlier website visits or import historical refunds.
5. Confirm the Payment Match Before Reading Campaign Credit
Open Dashboard for the same website and dates. Under the summary cards, select Payment Match to inspect linked and unlinked payments. Find the known payment in your authorized payment records and confirm the expected recorded visitor. A payment can exist in revenue without a matching visit; renaming its source is not a repair.
Then open Where customers come from → Revenue sources → View all. Use Sources for a service-level check. For a campaign question, select Ad ROAS, which is the current full campaign view, and search the campaign label. Record the Credit rule and look-back window with your export.
Where to find itDashboard → Revenue sources → View all → Ad ROAS → Search
The overview preserves the website, dates, Credit rule, campaign search and affected report. Order credit and Net revenue from that same capture are enlarged below.
Select the overview to open the full screenshot.
Enlarged detail of the outlined area
- Read allocated order credit
Order credit follows the selected attribution rule. A split-credit rule can produce fractional values; this is not a count of newly acquired customers.
- Keep the revenue definition
Net revenue credit includes the report’s recorded refund deductions. Check dates, currency and payment coverage before comparing campaign rows.
Campaign credit comes from recorded website activity and supported payment matching. It is not Stripe deciding which ad caused the purchase. Ad spend in this view is saved or imported separately; connecting Stripe does not import advertising costs or turn a revenue-to-spend ratio into profit.
Keep the credit rule fixed for the first comparison. First-Touch and Last-Touch can assign the same payment differently, while a refund changes recorded net value. Neither a different rule nor a cleaner campaign label recovers a visit that was never recorded.
6. Find the First Handoff That Still Needs Evidence
Use the checklist to record what you observed at each boundary. It chooses the next check from your answers, flags a populated business reference ahead of metadata, and keeps unknown values separate from measured zero amounts. It does not inspect your account or create a payment.
One visit, one Session, one payment
Review the Checkout Reference Handoff
Choose what you actually observed. Leave unavailable amounts blank and keep one currency and date basis. Do not enter keys, emails or customer identifiers. Starting amounts form an example. Entries stay in this browser; no account is connected.
The amount example expects USD 149 and observes USD 149, giving a zero difference. That checks arithmetic only. It does not establish a matching visitor, delivered event or campaign source. Leaving an amount blank withholds the comparison; entering zero records an actual zero-amount observation.
If the payment is present but unmatched, work backward from the created Session to your server request and recorded visit. If the payment itself is missing, check supported route, state, account, event delivery and dates first. Keep those two investigations separate so your developer has one concrete boundary to inspect.
Save a short review note in your authorized records: website, campaign label, checkout route, account mode, dates, amount basis, which boundary was verified, what remains unknown and who owns the next fix. For a broader payment reconciliation, review provider history and possible duplicate records before discussing campaign performance.
Common questions
Do UTM parameters on my website automatically match a Stripe payment?
No. UTMs label the incoming website visit. A server-created Checkout still needs the relevant visitor handoff and a supported payment match. A campaign name copied into a payment field is not a substitute for the actual recorded visitor reference.
Can I use my own user ID as the Attriboo visitor reference?
Do not assume they are the same. Attriboo checks whether the selected visitor reference is already known on that website. The current Session reader prioritizes a populated client_reference_id before Session metadata, so an unrelated business ID can prevent the metadata reference from being selected.
Does a successful return page prove attribution worked?
No. A customer can pay without reaching the return page, and a return page can load without establishing the final payment-to-visit match. Inspect the relevant paid record, delivered event and matching visit separately.
Will importing older Stripe payments restore their original campaigns?
An import cannot recreate visits that were never recorded. Existing recorded history and a supported later match may help, but importing payments alone does not recover missing referrers, cross-device history or campaign labels.
Does this workflow cover standalone Stripe Elements PaymentIntents?
No. This guide covers supported Checkout Sessions, with Billing invoices requiring their own review. Standalone PaymentIntents outside Checkout or Billing are outside the current native connection. Identify the payment route before diagnosing it as a lost Checkout reference.
Ten years in SEO, building products and helping clients connect marketing work to business results. Founder of Attriboo.
Get to know Jay · Follow on LinkedIn
