GA4 Referral Exclusion: Stop PayPal Taking the Credit

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

Sales credited to paypal.com, a card processor or your own website are one of the faults we find most often when we fix ecommerce tracking for agencies and in-house teams. The symptom is always the same: a referral you never paid for sits near the top of GA4, carrying revenue that belongs to your ads, email or organic search. Channel reports stop making sense, and teams end up pulling their hair out with data challenges that start at the checkout. Below is the walkthrough we give clients: how to prove what the referral is, how to set up GA4 referral exclusion, and how to test it.

Why is PayPal or Stripe showing as a referral in GA4?

PayPal, Stripe or another payment processor shows as a GA4 referral because the customer leaves your site to pay on the processor’s domain, then lands back on your confirmation page from it. Google’s own help page on unwanted referrals names this exact case: an ecommerce site whose users “return to your site after checking out on the third-party domain” (Identify unwanted referrals).

Stripe’s documentation describes the same hop from the other side: with its full-page Checkout, customers can pay “via a redirect to a Stripe-hosted page” (Stripe Checkout). The return trip carries the processor as the referrer. GA4’s unwanted referrals setting exists to mark that referrer as one that “should not be displayed as a traffic source” (Identify unwanted referrals). Without it, the payment page can take credit for the sale.

Slow payments make it worse. By default, a GA4 session ends after 30 minutes of user inactivity (About Analytics sessions). A customer who spends longer than that in a bank app or a 3-D Secure check comes back after the old session has ended, so the purchase lands in a fresh session with the payment domain as the most recent referrer.

Why does your own domain show up as a referral?

Your own domain shows as a GA4 referral when a visitor moves between pages or domains that GA4 does not treat as one journey. Google’s cross-domain documentation lists the usual ways to stop self-referrals: make sure every page carries the Analytics code, configure cross-domain measurement correctly, and check your cookie domain settings. It recommends the cross-domain setup for subdomains too (Set up cross-domain measurement).

In practice the culprit is a checkout, booking or account area on a separate subdomain or domain, or a template that lost its tag in a redesign. The exclusion list can hide the symptom, but the fix is to tag the missing pages and add the domains under Configure your domains. Our cross-domain tracking guide covers that setup and the _gl linker parameter in detail.

How do you prove the referral is a checkout return, not real traffic?

Prove it before you exclude anything, because a real referrer on the list loses you real data. A payment gateway referral has a tell: it brings almost no new visitors, yet it carries purchases. Two checks in GA4 show it.

1. Find it in the acquisition report. Open Reports, then Acquisition, then Traffic acquisition, and switch the table’s primary dimension to Session source / medium (Traffic acquisition report). Look for rows such as paypal.com / referral, your processor’s domain or your own domain, and compare their sessions with their purchases and revenue.
2. Read the referrer on the purchase journey. In Explore, start a Free form exploration, add the Page referrer dimension and the Event count metric, and filter Event name to purchase (Free-form exploration). Google defines Page referrer as “the user’s previous URL”, which “can be your website’s domain or other domains” (Dimensions and metrics). A payment domain sitting in front of your purchases confirms the hop.

Then place one test order through each payment method you offer and note every domain the browser passes through before the confirmation page. That list, not a generic one copied from a blog, is what goes into the setting.

How do you set up GA4 referral exclusion?

GA4 referral exclusion lives in the web data stream’s tag settings under the name List unwanted referrals. Each condition names one referring domain, and GA4 applies the conditions on every page that carries the Google tag. The path and limits below come from Google’s unwanted referrals help page.

1. Go to Admin, then Data collection and modification, then Data streams, and select your Web stream.
2. Click Configure tag settings, then Show all, then List unwanted referrals.
3. Under “Include referrals that match ANY of the following conditions”, choose a match type and type the domain under Domain, for example paypal.com.
4. Click Add condition for each extra domain from your test orders, such as your card processor’s hosted payment domain.
5. Click Save.

The conditions work as OR logic, so a referral matching any one of them is excluded. Google caps the list at 50 unwanted referrals per data stream, and it only works where the Google tag is on the page (Identify unwanted referrals). Developers can also send an ignore_referrer parameter set to true on individual events, but Google warns against setting it on every page because “you may lose valuable information regarding your traffic sources” (same page).

How do you test that the exclusion worked?

Test with new sessions, not old reports. Place a fresh test order through each payment method, ideally from a tagged link with UTM parameters so you know what the source should be. Then check the purchase in the Free form exploration from the proof step: the session source should read as your test link’s source, not the payment domain.

Give live orders a few days, then compare the Traffic acquisition report with the period before the change. The payment domain’s share of purchases should fall away, and the channels that really drove those sales should pick them up. If a new unknown referral appears instead, run a test order again: some processors add a second domain for card checks or wallet payments.

Why is the payment referral still showing after you excluded it?

The unwanted referrals setting is not retroactive. Google’s help page explains that a user who arrived through a domain before it went on the list can keep being credited to that domain on later visits, because GA4 applies last non-direct click attribution to their earlier sessions (Identify unwanted referrals). Returning customers who first came back from PayPal last month can still show PayPal as their source.

Historical reports stay as they are, too. When we fix this for clients, we annotate the change date in the reporting and read channel revenue before and after it separately, rather than blending the two periods. If the referral keeps appearing on brand-new test sessions, the setting is not the problem: look for an untagged confirmation page or a domain you did not add.

What should stay off the unwanted referrals list?

Keep the list to domains that sit inside your own checkout or login journey. Google’s examples are third-party payment processors and interactions your site manages itself, such as links in password-recovery emails (Identify unwanted referrals). Partner sites, affiliates, review sites and press coverage are real referrers, and excluding them hides where customers actually came from.

When we audit ecommerce accounts, an overgrown list is almost as common as a missing one. We see affiliate networks, marketplaces and whole social platforms excluded because someone once saw them next to revenue. The purchases then drift into Direct or Unassigned instead of the source that earned them. If that is where your revenue has gone, our guide to GA4 unassigned traffic walks through the next checks.

How we handle payment gateway referrals for clients

We fix referral and attribution faults like this for agencies and in-house ecommerce teams, and we always start from the checkout journey, not the settings page. A payment referral is rarely alone: the same audit usually turns up an untagged subdomain, a missing cross-domain rule or revenue that disagrees with another tool, which our Klaviyo and GA4 revenue mismatch guide covers. Here is what fixing attribution end to end looked like for one ecommerce client.

For a children's subscription brand we took attribution confidence from zero to 100%, cut customer acquisition cost by 20%, recovered 30% of the Facebook conversions iOS privacy changes had hidden, and automated 10+ hours a week of reporting.

When to call someone

Call someone when the referral survives a clean exclusion and fresh test orders, or when the proof steps point at more than one cause. The thresholds we use: your own domain still appears after every page is tagged, purchases land on a confirmation page that sits on another domain, the checkout runs through more than one processor or an app you cannot tag, or GA4 revenue by channel still disagrees with your order system after the change. Any one of those means the list alone will not settle it.

If you want a quick outside view first, Sonar checks which tags load on your pages the way a visitor’s browser sees them, which is a fast way to spot an untagged checkout page. Tell us what’s broken, or book a call. If you already know you need someone inside the account, our paid GA4 audit reviews your GA4 and GTM setup and ends in a written findings report.