Why are purchases visible in Stripe but missing in GA4?
Stripe records a payment; GA4 records a browser session that survived long enough to send an event. Those diverge whenever the customer pays through Stripe Checkout on Stripe's own domain and doesn't return, when an ad blocker removes the GA4 request, when consent is denied, or when the purchase event fires on a confirmation page that some buyers never see. Stripe is the source of truth for money — the fix is to send GA4 the purchase from the Stripe webhook rather than hoping the browser does it.
Free30 minutesNo obligation
Stripe purchases missing in GA4 · what breaks
What this looks like when it's happening to you — Stripe purchases missing in GA4
- 01
Stripe shows payments GA4 has no record of
A gap larger than consent denial alone explains.
- 02
The gap concentrated in one payment flow
Usually the hosted Checkout redirect.
- 03
GA4 revenue consistently below Stripe
By a stable margin.
Stripe purchases missing in GA4 · the fix
What changes once it's fixed — Stripe purchases missing in GA4
GA4 reflecting real payments
Sent from the webhook rather than the browser.
A gap you can explain
Consent denial and blocking, quantified.
Stripe agreed as the source of truth
With GA4 measured against it.
Stripe purchases missing in GA4 · architecture
Why your conversion data was wrong in the first place — Stripe purchases missing in GA4
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to stripe purchases missing in ga4, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
Stripe purchases missing in GA4 · normal or broken
Some of this is supposed to happen — Stripe purchases missing in GA4
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
GA4 slightly below Stripe
Consent denial and blocking. A small stable gap is correct.
Stripe including payments with no web session
Invoices and manual charges were never going to appear in GA4.
Actually broken
Customer never returns from Stripe Checkout
Hosted on Stripe's domain and abandonable after payment.
GA4 request blocked
By an extension or network-level filter.
Consent denied
Correct behaviour, and part of the expected gap.
Session identity lost across the redirect
The event arrives unattached to the original session.
Stripe purchases missing in GA4 · diagnose
How we find out why are purchases visible in stripe but missing in ga4
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Reconcile Stripe payments against GA4 purchases
One closed week, matched on payment or order ID.
- 02
Segment the gap by payment flow
Hosted Checkout versus embedded elements behave differently.
- 03
Complete a payment and close the tab immediately
Does GA4 record it?
- 04
Check whether session identity survives the redirect
The client ID needs carrying through.
- 05
Check consent-denied share
That part of the gap is expected.
Stripe purchases missing in GA4 · prove
How we prove it's actually fixed — Stripe purchases missing in GA4
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Stripe payment records
- GA4 purchase count within a few percent of Stripe payments for a closed week, matched on ID.
- A payment confirmed recorded in GA4 where the customer never returned to the site.
- No payment ID appearing twice.
- Consent-denied share identified so the residual gap is explained.
- Reconciled against stripe payment records for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
Stripe purchases missing in GA4 · free audit
What we check in the free audit
- Reconcile Stripe payments against GA4 purchases
- Segment the gap by payment flow
- Complete a payment and close the tab immediately
- Check whether session identity survives the redirect
- Check consent-denied share
Checked against
Stripe payment records
Free30 minutesNo obligation
Stripe purchases missing in GA4 · when not to buy
When you don't need us for this — Stripe purchases missing in GA4
Most of these you can do yourself, and we would rather you did.
- You use embedded Stripe elements with no redirect and your gap is small.
- You report revenue from Stripe and use GA4 only for behaviour.
- Your volume is low enough to check payments by hand.
Stripe purchases missing in GA4 · what we deliver
What we do about it — Stripe purchases missing in GA4
Purchase sent from the Stripe webhook
Via the Measurement Protocol, keyed on the payment ID.
Session identity carried through Checkout
So the webhook event joins the right session.
Deduplicated against any browser event
So both paths can run without doubling.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
Stripe purchases missing in GA4 questions, answered
Stripe. It's the system that took the money. GA4 answers behavioural questions and will always read slightly under.
GA4's Measurement Protocol accepts server-side events. It needs the client ID to attach the event to the right session, which is why carrying identity through Checkout matters.
Not if the events share a transaction ID. GA4 deduplicates on it within its window.
Those have no web session and shouldn't appear in GA4. Exclude them before comparing, or the gap will never close.
Free · 30 min
Get stripe purchases missing in ga4 diagnosed properly
Free30 minutesNo obligation
