Attribution when payment domains steal the credit
Open your GA4 acquisition report and look for "paypal.com" or "checkout.shopify.com" sitting in your top referrers with a suspiciously high conversion rate. That's not a channel. That's your actual marketing spend getting robbed by a payment redirect, and if you're making budget decisions off that report, you're funding the wrong channels.
How payment domains hijack credit
Here's the mechanic. A customer clicks your Facebook ad, lands on your product page, adds to cart, and hits checkout. If they choose PayPal, Shop Pay, Klarna, or Afterpay, their browser gets redirected off your domain to authorize payment, then bounced back to your confirmation page. That round trip breaks the referrer chain.
Most analytics tools use the last non-direct referrer to attribute a session. When the browser returns from paypal.com or checkout.shopify.com, that domain often gets recorded as the new referring source, especially if the redirect doesn't preserve UTM parameters or if a new session starts on return. The ad that actually drove the visit disappears from the report entirely. It gets replaced by a payment processor.
Why this quietly wrecks your reporting
This isn't a rounding error. Payment redirects happen on a meaningful share of mobile checkouts, and mobile is where Shop Pay, PayPal Express, and BNPL options get used most. That means the bias isn't random, it's concentrated on your highest-intent, closest-to-purchase sessions, which are exactly the conversions everyone wants credit for.
The downstream effect: paid social and paid search look like they underperform on last-touch and even data-driven models, because a chunk of their converting sessions get reassigned to "referral: paypal.com" or worse, "direct." Email looks weaker for the same reason. Meanwhile the payment domain shows a conversion rate that makes it look like your best channel, which it obviously isn't, because it's not a channel. It's a checkout step.
If you're calculating true ROAS off this data, you're overstating cost per acquisition for the channels actually filling your funnel, and you're making cut decisions on ad sets that are working fine.
Fixing it in GA4 and your tags
Start with the free fix: referrer exclusion lists. In GA4, go to Admin > Data Streams > your web stream > Configure tag settings > List unwanted referrals, and add your payment domains: checkout.shopify.com, paypal.com, stripe.com, klarna.com, afterpay.com, whatever your checkout stack actually uses. This stops those domains from starting a new session and keeps the original session (and its source) intact when the browser returns.
Also check your self-referral exclusion list under Admin > Data Streams > Configure tag settings > List unwanted referrals for your own domain and any subdomains involved in checkout (checkout.yourbrand.com counts). If your checkout runs on a different subdomain than your storefront, cross-domain measurement needs to be configured correctly or you'll get the same session-splitting problem from your own infrastructure.
None of this is retroactive. Fixing the exclusion list stops future misattribution, it doesn't repair the history already sitting in your reports. If you're pulling trend data for planning, flag the period before the fix as unreliable for channel-level comparisons.
The real fix lives in your pipeline
Referrer exclusions patch the symptom. The actual fix is to stop relying on browser referrer data at the moment of conversion and instead attribute based on the session that started the customer's journey, captured and stored before checkout ever begins.
The pattern that works: capture UTM parameters and click IDs (gclid, fbclid, ttclid) on landing, write them to a first-party cookie or local storage with a reasonable lookback window, and carry them through as custom cart or order attributes. Shopify supports custom attributes on the cart and order object for exactly this reason. When the order lands in your warehouse, you join it to the original session data you captured at landing, not whatever referrer the payment processor's redirect happened to leave behind.
This also fixes a second problem: platform-reported conversions and your GA4 numbers disagreeing with each other. When attribution is stitched at the warehouse level from first-party session data, you get one source of truth that doesn't move every time a customer picks a different payment method at checkout.
Server-side tracking helps too. If your tag manager runs server-side, you control what happens to session data during redirects instead of hoping the browser's referrer header cooperates. Combined with a server-side container that stamps click IDs onto a first-party identifier early, you eliminate most of the checkout-redirect noise before it ever reaches your reports.
What to actually do this week
Add your payment and checkout domains to the GA4 unwanted referrals list today, that's a five-minute fix with immediate payoff. Then check whether your checkout captures UTMs as cart attributes, most Shopify themes don't do this by default and it has to be added. Finally, pull your last quarter of channel performance and mentally discount any channel comparison that relied on last-touch attribution during that period, because payment domains have likely been quietly padding your "referral" and "direct" buckets the whole time.
Attribution built on browser referrer headers was never going to survive contact with modern checkout flows. Fix the capture point, not just the report.