Payment Redirects Broke GA4 Tracking

A customer clicks a paid ad, lands on a WooCommerce store, adds a product to cart, and pays successfully. The order goes through, but the marketing system can forget where that customer came from before the sale was recorded. That is the problem behind a new technical write-up from Seresa, which argues that several WooCommerce payment flows are dropping Google Analytics 4 tracking parameters during redirects. The gateways named in the post are PayPal, Klarna, and Stripe, and the claim is that this can break acquisition attribution at the exact moment a purchase is completed. (seresa.io) To understand why this matters, start with how Google Analytics 4 tracks a person across domains. When a shopper moves from one site to another during checkout, Google passes identity information through a special URL parameter called `_gl`, so the second site can keep the same user and session instead of creating a new one. (support.google.com) (developers.google.com) Google’s own documentation is explicit about the mechanism. Cross-domain measurement adds the `_gl` linker parameter to links or forms that send a user to another domain, and the destination domain reads that parameter and restores the same first-party measurement cookies. (developers.google.com) (support.google.com) If that parameter survives the trip, Google Analytics 4 sees one shopper, one session, and one path to purchase. If the parameter is stripped during a redirect, the return visit can look like a fresh session, which opens the door to self-referrals, direct traffic inflation, and broken channel attribution. (support.google.com) (developers.google.com) WooCommerce stores are especially exposed because many payment methods do not keep the buyer on the merchant’s domain from start to finish. Stripe’s own documentation for hosted Checkout shows a server creating a Checkout Session and then redirecting the browser to a Stripe-hosted URL, while WooCommerce’s Stripe extension also supports off-site and alternative payment methods including Klarna. (docs.stripe.com) (woocommerce.com) Klarna’s WooCommerce documentation makes the same structural point from another angle. It warns that callbacks from Klarna back to the store must work correctly for orders to update properly, which confirms that the payment flow involves a handoff away from the store and then a return path back into WooCommerce. (woocommerce.com) That handoff is where attribution can break. Seresa’s write-up says some payment redirects remove the Google Analytics 4 linker parameter before the shopper lands back on the merchant site, so the purchase event fires without the original campaign context attached. (seresa.io) The practical effect is not just a few messy reports. If paid search, paid social, affiliates, or email are under-credited while “direct” traffic is over-credited, a company can end up cutting channels that are actually working and defending channels that only look efficient because the redirect erased the evidence. (support.google.com) (seresa.io) This also creates structural bias in customer acquisition cost reporting. Customer acquisition cost depends on matching ad spend to the right conversions, and when the final purchase is reassigned to direct or a self-referral, the bias is systematic rather than random because it happens most often in the same payment flows. (seresa.io) (support.google.com) There is another layer to the problem inside WooCommerce itself. Some tracking setups rely on the user returning to the WooCommerce “order received” or thank-you page for the purchase event to fire, and plugin documentation in the WordPress ecosystem warns that orders can complete successfully but never be reported if the buyer does not return to that page. (wordpress.org) (wordpress.com) That means merchants can face two separate failures at once. One failure is that the shopper never returns to the confirmation page, so no purchase event is sent; the other is that the shopper does return, but the cross-domain parameter was removed on the way back, so the event is sent with the wrong source attached. (wordpress.org) (support.google.com) (seresa.io) Stripe itself recommends using Google Analytics 4 to analyze the Checkout funnel, which underlines how central correct session continuity is for merchants using hosted payments. But that recommendation assumes the redirect chain preserves the information Google Analytics needs to join the visit before payment with the purchase after payment. (docs.stripe.com) (developers.google.com) The larger lesson is that ecommerce measurement can fail in infrastructure, not just in dashboards. A store can have valid ad campaigns, a working checkout, and a correctly configured analytics property, and still get distorted channel reporting because a payment redirect quietly dropped one parameter in transit. (support.google.com) (seresa.io) For merchants running WooCommerce, this story is a reminder to audit the full checkout journey rather than only the landing page tags. The critical questions are whether the payment method sends customers off-domain, whether the return URL preserves the Google Analytics 4 linker parameter, and whether the final purchase event fires on a page the customer actually reaches. (developers.google.com) (woocommerce.com 1) (woocommerce.com 2)