Check your GA4 acquisition report. If PayPal, Klarna, or Stripe is showing up as one of your top traffic sources, your WooCommerce tracking has a structural break. 62% of WooCommerce stores run GTM (SimilarTech, 2025), and the majority are using payment gateways that silently destroy GA4’s cross-domain linker on every checkout redirect. The problem isn’t your configuration. It’s the architecture.
Here’s what’s happening: GA4 uses a URL parameter called _gl to stitch sessions together across domains. GTM appends this parameter to links via JavaScript. Payment gateways like PayPal, Stripe Checkout, and Klarna redirect customers through their own external domains — and that HTTP redirect strips the _gl parameter before GA4 can read it. Every sale processed through an off-site gateway appears in GA4 as a brand-new session arriving from paypal.com or klarna.com. Your actual acquisition source — paid search, email, social — gets erased.
Why the _gl Parameter Dies on Payment Redirects
GA4’s cross-domain tracking depends on a JavaScript mechanism. When a user clicks a link, GTM’s cross-domain linker appends a _gl parameter containing an encoded session fingerprint. GA4 reads this parameter on the destination page and reconnects the session.
JavaScript cannot intercept an HTTP server redirect. That’s the fatal gap.
When a customer clicks “Pay with PayPal,” WooCommerce sends an HTTP redirect to PayPal’s servers. The customer’s browser follows this redirect automatically — no JavaScript fires, no link is clicked, no _gl parameter is appended. The customer lands on PayPal’s domain as an entirely new, unlinked session. When they return to your thank-you page after completing payment, GA4 records a referral visit from paypal.com, overwriting whatever channel actually drove that customer to your store.
According to Kissmetrics (2026), the _gl linker parameter breaks on redirects, consent banners, and device switches — all three of which are common in modern WooCommerce checkout flows. The cross-domain tracking guide from Conversios (2025) confirms that payment gateways like PayPal, Stripe, and Klarna redirect through external domains, breaking attribution unless referral exclusion lists are properly configured — but even that fix is a patch, not a solution.
You may be interested in: Why AI Cannot Fix Your GTM Server-Side Setup
The Three Payment Gateway Patterns That Break GA4
1. Full External Redirect (PayPal Standard, Klarna, Afterpay)
The customer leaves your domain entirely. Your URL bar shows paypal.com, klarna.com, or afterpay.com. Every session-level attribute — source, medium, campaign, landing page — is severed at this point. When they return, GA4 creates a new session attributed to the payment provider as referrer.
2. Hosted Payment Pages (Stripe Checkout)
Stripe’s hosted checkout page runs on checkout.stripe.com. Even though it looks like a seamless overlay to the user, the browser URL has changed to an external domain. The _gl parameter problem applies here exactly as it does with PayPal. Stripe Elements (the embedded card form) avoids this because it doesn’t redirect — but Stripe Checkout does.
3. BNPL Verification Flows (Klarna, Zip, Sezzle)
Buy-now-pay-later services often route the customer through a multi-step verification flow on their own domain before returning to your thank-you page. The return trip from the BNPL domain counts as a referral visit in GA4. Demandbase (2024) found that 73% of B2B SaaS companies operate at least two distinct web domains that customers touch during a buying process — and WooCommerce stores face the same fragmentation, with payment gateways adding domains they don’t control.
The result is consistent: your best-performing paid campaign shows 40 conversions in Google Ads and 23 in GA4. The gap is your payment gateway eating the attribution data.
Why GTM Configuration Fixes Don’t Hold
The standard advice is to configure GA4’s referral exclusion list — add paypal.com, stripe.com, klarna.com, and your other gateway domains. This stops GA4 from counting the return visit as a new session attributed to the payment provider. It’s a necessary step.
But it doesn’t restore the original attribution. The cross-domain linker was already stripped when the redirect happened. GA4 knows the visit didn’t come from Klarna — but it doesn’t know it came from your Google Ads campaign either. The session origin is gone.
Kissmetrics (2026) notes that cross-domain tracking is not set-and-forget: site updates, redirect rules, consent changes, and CDN configurations can all silently break the cross-domain connection after it’s been configured. The problem is structural — GTM’s linker is a browser-side mechanism, and payment gateways route transactions at the server level. Browser-side fixes cannot reliably intercept server-level redirects.
You may be interested in: Your GA4 Reports Are Empty: The Gap Between Testing and Production Tracking
The Architecture That Makes This Problem Impossible
The reason payment gateway redirects destroy cross-domain tracking is that GTM’s fix depends on browser-side execution. Server-side tracking at the PHP layer eliminates this dependency entirely.
WooCommerce has a hook called woocommerce_payment_complete. This PHP action fires server-side the moment a payment is confirmed — before WooCommerce redirects the customer to the thank-you page, and certainly before any return redirect from PayPal or Klarna. A server-side tracking call at this hook captures the purchase event with full order data — order ID, revenue, products, customer identifiers — without relying on the browser, the _gl parameter, or the customer’s return journey at all.
The customer can stay on PayPal’s domain forever and the conversion is already recorded. The redirect is irrelevant.
Transmute Engine™ by Seresa is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures events from WooCommerce server hooks — including woocommerce_payment_complete — and sends them via API to your Transmute Engine server, which routes the purchase event simultaneously to GA4, Google Ads Enhanced Conversions, Facebook CAPI, and BigQuery. Because the tracking call never crosses a domain boundary in the browser, PayPal and Stripe can redirect freely — the conversion is already secured.
Key Takeaways
- GA4’s _gl linker parameter is a browser-side cookie that cannot survive HTTP redirects through external payment gateway domains.
- 62% of WooCommerce stores run GTM (SimilarTech, 2025) — and every store using PayPal Standard, Stripe Checkout, Klarna, or similar redirect-based gateways is structurally exposed to this attribution failure.
- Referral exclusion lists stop misattribution but don’t restore the original traffic source. The session-origin data is already gone when the
_glparameter is stripped. - GTM cross-domain tracking cannot intercept server-level redirects — the mechanism is JavaScript, and redirect-based gateways bypass JavaScript entirely.
- Server-side tracking at the WooCommerce order hook captures the purchase event before any redirect occurs, making cross-domain linker failure structurally irrelevant.
When a customer clicks Pay with PayPal, GA4’s _gl linker parameter is stripped by the HTTP redirect to PayPal’s external domain. GA4 sees the customer returning from paypal.com as a new session, counting PayPal as the traffic source rather than your original marketing channel. Adding paypal.com to GA4’s referral exclusion list prevents this misattribution, but it doesn’t restore the original source — it just stops PayPal from being counted as a referrer.
No. GTM’s cross-domain fix appends a _gl parameter to links using JavaScript. HTTP redirects through payment gateways (PayPal, Stripe Checkout, Klarna) bypass this JavaScript entirely — the redirect happens at the server level before GTM can append the linker. The fix works for user-clicked links within your own domain, not for gateway-initiated redirects.
Klarna’s BNPL flow redirects customers through klarna.com for verification, then returns them to your thank-you page. GA4 reads this return as a referral visit from klarna.com. Without proper referral exclusion configuration, every Klarna transaction inflates Klarna as a top traffic source and destroys the original attribution — usually paid search or social — that drove the sale.
Short term: add your payment gateways (paypal.com, stripe.com, klarna.com) to GA4’s referral exclusion list in Admin > Data Streams > Configure Tag Settings. This prevents misattribution but doesn’t fully restore original session data. Long term: server-side tracking at the WooCommerce order hook fires the purchase event before any redirect occurs, making cross-domain linker failure structurally impossible.
Any gateway that redirects through an external domain: PayPal Standard, Stripe Checkout (hosted page), Klarna, Afterpay, Zip, and most bank transfer gateways. Stripe Elements (inline card form without redirect) is typically safe. The rule is simple — if the customer’s browser URL changes to a domain you don’t own during checkout, your GA4 attribution is at risk.
If your GA4 attribution is fragmented across payment provider referrals, the browser-side fix only goes so far. See how server-side WooCommerce tracking works at seresa.io.
