Why does my payment gateway break attribution?
An external payment page is a different domain, so returning from it starts what looks like a brand-new visit: the referrer is now the gateway, the session breaks, and the sale is attributed to PayPal or Stripe rather than the campaign that earned it. Referral exclusions stop the gateway being credited as a source, but they don't restore the original campaign — for that the click ID has to be persisted first-party before the redirect and the purchase fired from the order record rather than the returning page.
Free30 minutesNo obligation
Payment gateway breaks attribution · what breaks
What this looks like when it's happening to you — Payment gateway breaks attribution
- 01
PayPal, Stripe or Klarna appearing as a traffic source
Sometimes as one of your largest 'campaigns'.
- 02
Paid conversions attributed to direct
The original campaign loses its credit entirely.
- 03
Purchases missing for one payment method only
Where customers can abandon after paying.
Payment gateway breaks attribution · the fix
What changes once it's fixed — Payment gateway breaks attribution
The campaign keeps its credit
Through the redirect and back.
Gateways stop appearing as sources
Referral exclusions doing their job.
Purchases arrive regardless of the return
Because the order record, not the browser, is the trigger.
Payment gateway breaks attribution · architecture
Why your conversion data was wrong in the first place — Payment gateway breaks attribution
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 payment gateway breaks attribution, 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.
Payment gateway breaks attribution · normal or broken
Some of this is supposed to happen — Payment gateway breaks attribution
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
A brief session break at the redirect
Expected. What matters is whether attribution survives it.
Gateway domains in raw referrer data
Normal — exclusions stop them being counted as sources, not from being seen.
Actually broken
Gateway domain not in referral exclusions
It registers as the referrer and takes the credit.
Click ID lost across the redirect
Stored only in session, or never persisted first-party.
Purchase tied to the return page
Customers who close the tab after paying are never counted.
Cross-domain linking not configured
The session splits into two.
Payment gateway breaks attribution · diagnose
How we find out why does my payment gateway break attribution
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Check your referral report for gateway domains
Their presence confirms the diagnosis in one look.
- 02
Complete a live order through each payment method
Watching the click ID before, during and after the redirect.
- 03
Confirm the click ID is readable on return
First-party cookie, not session storage.
- 04
Check whether purchase fires when you close the tab after paying
This is the case that loses real revenue.
- 05
Reconcile by payment method
One method producing most of the shortfall names the cause.
Payment gateway breaks attribution · prove
How we prove it's actually fixed — Payment gateway breaks attribution
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your store or payment processor order records, segmented by payment method
- Payment domains absent from the source report over a closed window.
- Click IDs confirmed present on the order record after a real redirect.
- Purchase confirmed firing on an order where the customer never returned to the site.
- Reconciled against your store or payment processor order records, segmented by payment method 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.
Payment gateway breaks attribution · free audit
What we check in the free audit
- Check your referral report for gateway domains
- Complete a live order through each payment method
- Confirm the click ID is readable on return
- Check whether purchase fires when you close the tab after paying
- Reconcile by payment method
Checked against
Your store or payment processor order records, segmented by payment method
Free30 minutesNo obligation
Payment gateway breaks attribution · when not to buy
When you don't need us for this — Payment gateway breaks attribution
Most of these you can do yourself, and we would rather you did.
- You can add referral exclusions yourself — that alone stops the gateway being credited.
- Your checkout is fully on-site with no external redirect, so this doesn't apply.
- One payment method, low volume, and you can verify it by hand.
Payment gateway breaks attribution · what we deliver
What we do about it — Payment gateway breaks attribution
Click IDs persisted before the redirect
Written first-party so they survive the hop and are still there on return.
Referral exclusions configured
Every payment domain you use, so none can start a new session as itself.
Purchase fired from the order webhook
So the conversion doesn't depend on the customer coming back at all.
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
Payment gateway breaks attribution questions, answered
Partly. They stop the gateway being credited as a source, but they don't restore the original campaign. That needs the click ID persisted before the redirect.
Any that leave your domain — PayPal, Klarna, iDEAL, and most bank redirect flows. Embedded card fields usually don't.
It fixes the missing-purchase part, because the order record fires regardless of the browser. Attribution still needs the click ID persisted.
Because only some customers close the tab after paying. The rate varies by method and device.
More on Payment gateway breaks attribution
Free · 30 min
Get payment gateway breaks attribution diagnosed properly
Free30 minutesNo obligation
