Quick answer: When a checkout flow takes a user off your domain (to PayPal, Stripe Checkout, Authorize.net) and back, GA4 starts a fresh session attributed to the gateway as the "source." Your real source (Google Ads, organic, email) gets credit for landing the user but loses credit for the conversion. Fixing this requires: (1) adding payment gateways to your unwanted referrals list, (2) ensuring the _gl parameter survives the redirect, (3) enabling cross-domain tracking if you control both domains, and (4) auditing your Custom Pixel or app-embed code on Shopify-like platforms.
The symptom
You open GA4 → Acquisition → Traffic Acquisition and see one of these in your top 5 sources:
paypal.com / referralcheckout.stripe.com / referralsecure.paywithpaypal.com / referralauthorize.net / referral
If you're seeing dozens or hundreds of sessions per day from a payment processor, your checkout flow is leaking attribution. The user clicked your Google ad, navigated to checkout, got redirected to PayPal to pay, came back to your thank-you page — and GA4 split that into two sessions with the wrong source on the conversion.
The 4 gateway patterns that cause it
Pattern 1: PayPal Standard Checkout (redirect-based)
User clicks "Pay with PayPal" → redirected to paypal.com → completes payment → redirected back to your thank-you page. The session that started on your domain ends when they leave; a new session starts on return with PayPal as the referrer.
Fix: Add paypal.com to GA4 Admin → Data Streams → Configure tag settings → List unwanted referrals. This tells GA4 to ignore PayPal as a session-restarting referrer.
Pattern 2: Stripe Checkout (redirect to checkout.stripe.com)
Identical pattern with checkout.stripe.com. Same fix — add to unwanted referrals list. Note: this is different from Stripe Elements (embedded), which doesn't have this problem because the user never leaves your domain.
Pattern 3: 3D Secure / strong authentication redirect
Even with embedded Stripe Elements, a 3D Secure challenge can redirect the user to their bank's authentication page. The bank's domain becomes a referrer. Fix: add common 3DS hostnames (verify.3dsecure.com, secure.banking.example.com patterns) — though this is a long-tail problem.
Pattern 4: Custom payment pages on subdomains
Many SaaS companies host checkout on checkout.yoursite.com or billing.yoursite.com as separate apps. Even though it's your domain, GA4 treats it as separate unless cross-domain tracking is configured. Fix: add the subdomain to Admin → Data Streams → Configure tag settings → Configure your domains.
The deeper fix: _gl parameter preservation
The "unwanted referrals" list is necessary but not sufficient. Even after adding PayPal to the list, you need GA4 to recognize the returning user as the same session. That requires the _gl parameter (Google's cross-domain linker) to survive the redirect.
How _gl works
When a user clicks a link that goes to a domain in your cross-domain config, GA4 appends ?_gl=... to the URL. The destination domain reads this parameter and continues the session.
Why it gets stripped
- Server-side redirects: If your checkout flow does a 302 redirect that doesn't preserve query strings,
_gldies - URL whitelisting: Some payment processors strip "unknown" query params for security
- iOS 17+ Link Tracking Protection: Strips known tracking parameters including
_glwhen shared from Mail or Messages - WAF rules: Some Cloudflare WAF rules strip URL parameters to prevent XSS
How to verify _gl survives
- Open your checkout flow in Chrome incognito
- Open DevTools → Network tab → preserve log
- Click "Pay" → land on payment processor → complete with test card → return to thank-you page
- Inspect the final URL when you land back. Does it contain
?_gl=...? If yes, cross-domain is working. If no,_glgot stripped somewhere. - Trace the redirect chain in DevTools to find where it was lost
Pattern-specific advanced fixes
For Shopify stores
Shopify's native Custom Pixel system doesn't always preserve _gl through the checkout flow, especially with native gateways like Shop Pay. Use a Custom Pixel sandbox that reads and re-appends the parameter, or migrate to server-side GTM where you have full control.
For WooCommerce
The PayPal Standard plugin sometimes strips query params during the redirect. Use the PayPal Payments plugin (newer) or PayPal Smart Buttons (embedded) instead. Both preserve attribution natively.
For BigCommerce / Magento
Check the "Return URL" configuration in your gateway settings. Some platforms hardcode the return URL and don't pass through the _gl parameter from the originating session. Custom development is required to fix.
How to audit retroactive damage
Even after fixing the leak going forward, your historical data is corrupted — purchases attributed to PayPal that should have been credited to Google Ads or organic. To assess:
- GA4 → Reports → Monetization → Ecommerce purchases
- Add dimension: Session source/medium
- Filter where source contains "paypal" or "stripe"
- Look at the revenue attributed to these "sources." That's revenue you misattributed.
You can't reattribute historical data — but you can use a BigQuery export (if you have one) to model what the correct attribution should have been and adjust your ROAS calculations.
Why this matters for ad spend decisions
If 30% of your Google Ads-driven revenue is misattributed to PayPal/Stripe, your reported Google Ads ROAS is artificially low. You may be cutting profitable campaigns based on bad data. This is one of the most expensive single bugs we see in audits — easily costing six figures in misallocated ad spend per year for mid-sized ecommerce.
Audit your checkout and attribution end-to-end
Payment gateway attribution is one of dozens of subtle revenue-attribution issues in GA4. Run a free Snifflytics audit to identify which payment processors are leaking attribution, whether _gl is preserved through your checkout, and the rest of your cross-domain and ecommerce tracking setup.