How to attribute Stripe revenue to marketing channels

Stripe attribution means attaching the marketing source of a visit to the Stripe payment it produced, so revenue can be totaled by channel.

A Checkout Session has no UTM field, and the Payment Links tracking guide describes UTM codes coming back on the redirect URL.

Your side has to carry the source from the browser to the charge, which takes a first-party cookie and a few server lines, then a report that groups paid invoices by what you stored.

In the illustrative numbers below, paid social brings 57.1% of the trials on a $39 plan and 19.1% of the net revenue, so ranking by signups would misplace budget.

What Stripe stores about a sale

A sale spreads across a Customer, a Checkout Session, a PaymentIntent, a Charge and, for subscriptions, an Invoice each billing period. Each has a metadata field, and the metadata guide says it copies between objects only in the cases below.

Only secret-key requests return it, so your server does the writing.

Metadata set on a Customer does not copy to its Charges. Write the source onto the object whose events you will read, when you create it.

Four ways to join a payment to a source

The first and third routes need no checkout code, but the second is the one I would build, because only it stores a journey you own.

Google's Measurement Protocol guide asks for server events within 48 hours of the browser event, so renewals strain the fourth route. The Google Analytics guide has the build.

How Stripe attribution works, step by step

The visitor ID route has 6 links, and a break in any one sends revenue to an unattributed row.

Step 1: Tag the link and save the source on your own domain

Give each placement its own lowercase UTM values: Google's Analytics Help page says parameter values are case sensitive, so Newsletter and newsletter count as 2 sources. Have your server set the cookie.

WebKit's cookie rules say Intelligent Tracking Prevention deletes JavaScript-created cookies after 7 days without interaction, and caps cookies set in an HTTP response at 7 days only when it detects third-party CNAME or IP address cloaking.

Step 2: Tie the visitor to an account at signup

Store the visitor ID, first-touch source and email on the user record. A buyer who clicks on a phone and pays on a laptop holds 2 cookies, and the email links them.

Step 3: Write the visitor ID into Stripe when checkout starts

Create the Stripe Checkout Session when the buyer clicks Buy, because it stays open for 30 minutes to 24 hours and one built at page load carries whatever the cookie held then.

Put the ID in client_reference_id and in metadata, with subscription_data.metadata for subscriptions and payment_intent_data.metadata for one-time payments. The Checkout attribution guide has the route and the metadata setup guide has key names.

A Payment Link skips your server, so append client_reference_id to its URL. Stripe accepts letters, digits, dashes and the _ character up to 200 characters, which fits a 36-character UUID. The Payment Links attribution guide covers the rest.

Step 4: Read the money from webhooks

Stripe's subscription webhook guide says invoice.paid is sent when an invoice is successfully paid. Each new invoice gets a copy of the subscription's metadata under parent.subscription_details.metadata, so payment 12 of a $39 plan carries the source written for payment 1.

Live mode retries a failed delivery for up to 3 days, so store each event ID under a unique index.

Step 5: Group paid invoices by source, net of refunds

Credit one amount and write the rule down. A Checkout Session reports amount_subtotal, amount_total and total_details.amount_tax, so the pre-tax figure is easy to isolate.

Stripe's refund guide says a charge can take several refunds and the original processing fee is not returned, so keep gross and net in separate columns.

1-- payments: one row per paid invoice or one-time charge, filled from the webhook2-- refunds: one row per charge.refunded amount, linked to the payment3with refunded as (4  select payment_id, sum(amount_cents) as cents5  from refunds6  group by payment_id7)8select9  coalesce(p.source, 'unattributed')                   as channel,10  count(distinct p.customer_id)                        as customers,11  sum(p.amount_cents) / 100.0                          as gross,12  sum(coalesce(r.cents, 0)) / 100.0                    as refunded,13  sum(p.amount_cents - coalesce(r.cents, 0)) / 100.0   as net14from payments p15left join refunded r on r.payment_id = p.id16where p.livemode17  and p.paid_at >= date '2026-07-01'18group by 119order by net desc;

Step 6: Test the chain in a sandbox

Click a tagged link in a private window, sign up and pay with Stripe's test card 4242 4242 4242 4242 and a future expiry such as 12/34. Then refund it: the channel should gain the amount and lose it again.

What the numbers look like after the join

Take a $39 monthly plan and 90 days of sales from 3 channels. The figures are invented to show the arithmetic, so replace them with your own.

Paid social leads on trials, with 400 of 700. It earns $1,170 of the $6,123, while the newsletter's 120 trials return $2,964. Per trial, that is $24.70 for the newsletter, $11.05 for search ads and under $3 for paid social.

Paid social also refunded 4 of 34 invoices, or 11.8%, against 2.6% for the newsletter, so gross revenue would have flattered it by $156.

Renewals shift the picture again. If a report credits only each customer's first payment, the newsletter's share falls from 48.4% to 39.0%, because its customers paid 2.6 invoices each against 1.7 for paid social.

The subscription LTV guide covers 3 ways to credit renewals.

Choosing a window and a credit rule

TrackRev's attribution benchmarks put the median time from first click to first paid charge at 6.3 days and the 90th percentile at 48.2 days. Those counts include only conversions inside each workspace's window, so the true tail runs longer.

Pull the click-to-payment gap for your last 100 customers and set the window just past the 90th percentile.

Last touch gives the closing click all the credit, first touch gives it to the introducer, and linear splits it evenly, so a sale touched by 2 channels counts 0.5 on each.

In the Q2 2026 data, 64% of TrackRev workspaces default to last touch, 22% to linear and 14% to first touch. The attribution models comparison matches each rule to a funnel.

Stripe attribution tools compared

The Sigma guide says Stripe Dashboard financial reports can include metadata and Sigma's templates leave it out, with a Metadata to column template to add it.

Sigma runs ANSI SQL, shows up to 1,000 rows, exports all of them to CSV and costs nothing in a sandbox.

Where the chain breaks

What TrackRev does with a Stripe charge

TrackRev Revenue Attribution reads Stripe with a restricted key, so checkout code can stay as it is.

The first sync reads the previous 30 days of charges, a scheduled job picks up new ones, and a webhook that TrackRev registers when the key allows it starts a sync on a successful charge, a refund or a completed Session.

For each charge it checks a vid key in the charge metadata, then the Session's client_reference_id or metadata, then the buyer's email, which the pixel binds to the visitor at signup or checkout.

A renewal inherits the first order's credit, and a charge with any refund is marked refunded on the next sync, so even a partial refund removes the whole charge.

Credit defaults to last touch, with first touch and linear available, and the window runs from 1 to 365 days, 30 by default.

Revenue figures need a paid plan, from Starter at $39 a month. The free plan is link tracking only, with 50 links and 1,000 tracked events a month. The Stripe integration page covers the pixel and the key permissions.

Pick something else when your payments run through none of Stripe, Paddle, Polar or Lemon Squeezy, or when you close a handful of sales a month. A metadata write and a spreadsheet will answer the question.