Open your GA4 traffic sources report. If PayPal, Stripe, or Klarna is sitting near the top, your instinct might be to dismiss it as a quirk. It is not a quirk. It is GA4 telling you that every ad-driven sale routing through that payment gateway has lost its original campaign attribution — and your ROAS figures are wrong because of it.
GA4 is not broken. It is working exactly as configured. The problem is that the configuration has a gap, and payment gateway redirects fall straight through it.
That Means Every Ad You Ran Is Mislabelled
Here is what happens in sequence. A customer clicks your Google Shopping ad. They browse, add to cart, reach checkout. They choose PayPal. Your store redirects them to paypal.com to complete payment. PayPal redirects them back to your thank-you page.
That return redirect is the problem. When the customer lands back on your site from paypal.com, GA4 reads an incoming visit from an external domain. Without a referral exclusion telling GA4 to ignore paypal.com, it does what it always does with external domains: it starts a new session. The original session — the one that carried the Google Ads click ID, the UTM parameters, the campaign source — is abandoned. The conversion is attributed to PayPal.
The ad that drove the sale gets no credit. PayPal gets all of it. Your Google Ads ROAS looks lower than it is. Smart Bidding receives an incomplete conversion signal and adjusts bidding downward for a campaign that is actually working. You may have already cut budgets based on this data.
PayPal processes 25+ billion transactions annually. Every WooCommerce store accepting PayPal without a referral exclusion is exposed to this misattribution on every single transaction (PayPal Annual Report / Seresa tracking analysis, 2024).
You may be interested in: Payment Gateway Redirects Are Killing Your Conversion Tracking
Why the Standard Fix Is Only Half the Answer
The textbook response to payment gateway referral inflation is two steps: add the payment domain to your GA4 Referral Exclusion List, and configure GTM cross-domain auto-link to pass session data across the redirect.
Step 1: Referral Exclusion List
In GA4: Admin → Data Streams → Configure Tag Settings → List Unwanted Referrals. Add paypal.com, stripe.com, and any BNPL domains your store accepts (klarna.com, afterpay.com, affirm.com). This tells GA4 not to start a new session when customers return from those domains — the original session and its attribution are preserved.
BNPL usage has grown 400% since 2020 (Industry reports, 2024). If your store added Klarna or Afterpay in the last two years and never updated your exclusion list, you have been mis-attributing an increasing share of conversions for that entire period.
Step 2: GTM Cross-Domain Auto-Link
GTM can be configured to append a _gl parameter to links pointing to other domains you own. This passes the visitor session ID across domains so GA4 recognises the returning customer as the same user, not a new referral.
Here is the gap: GA4 cross-domain tracking only works via URL links. Form submissions and server-side redirects cannot carry the _gl parameter (Google Analytics 4 documentation / Analytics Mania, 2025). PayPal and Stripe return customers to your store via server-side redirects — not standard links. So the session identifier is never passed regardless of GTM configuration.
The referral exclusion prevents the session restart. The cross-domain auto-link helps when customers move between owned subdomains. But for the PayPal and Stripe redirect — the most common path — cross-domain linking cannot do what you need it to do. The structural gap remains open.
What the Corrupted Signal Actually Costs
Attribution loss at the payment gateway does not stay in GA4. It flows directly into every ad platform using your conversion data.
Google Smart Bidding and Performance Max infer campaign value from the conversion signals they receive. When ad-driven purchases are attributed to paypal.com, those signals either arrive stripped of campaign data or don’t arrive at all. 68% of multi-touch attribution models over-credit channels when conversion data is incomplete — mislabelled gateway traffic directly inflates apparent ROAS for channels that did not drive the sale (MarTech Series, 2025).
Meta Advantage+ operates on the same principle. Engagement and purchase signals shape audience targeting and delivery optimisation. When your purchase events lose their campaign source at the payment redirect, Advantage+ optimises on incomplete data — the audience model it builds does not fully reflect the customers who are actually buying.
You may be interested in: Meta Advantage+ Is Running on 40% of Your Data
Why This Gets Worse on Subdomains
If your WooCommerce store uses a subdomain for checkout — shop.yourdomain.com, checkout.yourdomain.com — the problem compounds. The redirect chain becomes: yourdomain.com (ad landing) → shop.yourdomain.com (checkout) → paypal.com (payment) → shop.yourdomain.com (thank you).
UTM parameters that survived the first subdomain hop often fail to survive the payment gateway return. GA4 may attribute the conversion to the checkout subdomain rather than the original campaign — even if the referral exclusion is correctly set. The original campaign source disappears at the subdomain boundary before it ever reaches the payment gateway (WP Fusion documentation / Seresa, 2025).
The fix here requires consistent UTM persistence across subdomain hops before the payment gateway, not just an exclusion list on the return. Most stores that have implemented the standard two-step fix still have this gap open.
The Architecture That Makes This Disappear
Every fix described above is client-side. Referral exclusions, cross-domain auto-link, UTM persistence scripts — all of them run in the browser, depend on JavaScript executing correctly, and operate on the session data GA4 has already fragmented by the time the customer returns from the payment gateway.
Server-side tracking captures the purchase event from the WooCommerce order record — not from the browser session after the redirect. When a WooCommerce order is created, inPIPE captures the order data including the original session attributes stored server-side, and sends it via API to the Transmute Engine™. The Transmute Engine routes a complete, attribution-intact purchase event to GA4, Google Ads Enhanced Conversions, Facebook CAPI, and any other configured destination.
The payment gateway redirect never touches the event pipeline. PayPal returns the customer to your thank-you page. The browser session may be fragmented. It does not matter — the purchase event was already captured and routed from the order, not from the browser. PayPal disappears from your traffic source report because there is no longer a browser-side event waiting to be mislabelled when the redirect completes.
Key Takeaways
- PayPal in your GA4 traffic report is a configuration signal, not a data glitch. GA4 is correctly recording that a redirect from an external domain happened — the problem is the redirect is losing session data that GTM never recovered.
- The two-part fix (referral exclusion + cross-domain auto-link) closes most of the gap but cannot solve the server-side redirect problem that PayPal and Stripe use by default.
- Every mislabelled conversion corrupts Smart Bidding and Advantage+ — the ad platforms optimise on what they receive, and what they receive is incomplete.
- Subdomain checkout flows extend the problem beyond the payment gateway, breaking attribution before the customer even reaches PayPal.
- Server-side purchase capture removes the redirect from the event pipeline entirely — the conversion is recorded from the order, not the browser session.
When a customer completes a PayPal payment and returns to your WooCommerce thank-you page, the redirect from paypal.com looks like a new referral visit to GA4. Without a referral exclusion for paypal.com, GA4 starts a new session attributed to PayPal — erasing the original ad source and recording the conversion against the payment gateway domain instead.
There are two required steps. First, add paypal.com, stripe.com, and any other payment domains to your GA4 Referral Exclusion List under Admin > Data Streams > Configure Tag Settings > List Unwanted Referrals. Second, configure GTM cross-domain auto-link domains to include any subdomains used in your checkout flow. Both steps are needed — exclusion prevents the session restart; auto-link preserves the original attribution across the redirect.
Yes. When purchases are attributed to paypal.com instead of the Google Ads campaign that drove the original visit, GA4 records those conversions without campaign data. Smart Bidding and Performance Max receive incomplete conversion signals and adjust bids based on apparent campaign performance — which may be significantly understated for campaigns whose conversions are being lost to gateway misattribution.
A GA4 referral exclusion list prevents specified domains from being counted as traffic sources. It is configured under Admin > Data Streams > Configure Tag Settings > List Unwanted Referrals. Adding paypal.com, stripe.com, and klarna.com means GA4 does not start a new session when customers return from those domains — the original session and its attribution are preserved.
GTM cross-domain auto-link appends a _gl parameter to links between owned domains. But PayPal and Stripe use form submissions and server-side redirects — not standard links — to return customers to your store. The _gl parameter can only be appended to URL links, so the session identifier is never passed through the payment gateway redirect, and GA4 treats the return as a new referral visit regardless of GTM configuration.
If PayPal is in your GA4 top-five, run the referral exclusion fix today — it takes ten minutes and stops the bleeding. Then check your subdomain chain and your BNPL list. And if you want the redirect to stop mattering entirely, that is what server-side order capture is for. Talk to the team at seresa.io.