rytisbalys.com / troubleshooting

Fix GA4 Purchases Showing as stripe.com, paypal.com or (direct)

You connected Stripe, PayPal or Klarna, or your bank switched on 3D Secure. Since that day GA4 reports purchases with session source stripe.com, paypal.com or (direct) / (none), and your ad campaigns look like they stopped selling. They did not. The buyer leaves your site to pay, returns with the gateway as the browser referrer, and GA4 overwrites the session source with the last domain the visitor came from.

The gateway-referral flavor takes one setting in GA4 Admin called List unwanted referrals. The (direct) / (none) flavor has different causes - session timeout at the gateway, blocked cookies - and different fixes, covered further down. Below: the mechanism, the setting, when cross-domain linking is the right tool instead, and how to verify the fix with real traffic.

Why GA4 credits purchases to the payment gateway

First, what does not happen: GA4 does not restart the session. Sessions only end on inactivity past the session timeout, 30 minutes by default - Google documents that new campaign parameters or a new referrer never restart a session. What actually happens is quieter. The return page fires a hit whose document referrer is the gateway domain. GA4 reads that as new traffic-source information for the ongoing session, and under its last-non-direct-click session attribution the gateway overwrites the source that brought the buyer. Same session, new owner. The purchase then reports under stripe.com instead of the Google Ads click or the email that did the work.

The symptom comes in two flavors, and they have different causes:

Source = stripe.com / paypal.com / klarna referral - the gateway passed a normal referrer on the redirect back and it overwrote the session source. This is the flavor List unwanted referrals fixes.
Source = (direct) / (none) - this one is not a referrer problem. It shows up when the session times out while the buyer sits at the bank, when consent-blocked or lost cookies make the return look like a brand-new user, or when there was no non-direct source inside the attribution lookback. Many gateways return via an HTTPS POST or meta refresh that strips the referrer entirely, so a referral exclusion has nothing to match. The fixes for this flavor are in the last section.

Either way the money consequence is the same: your paid campaigns under-report revenue, ROAS looks worse than it is, and budget gets cut from ads that were converting.

The fix: List unwanted referrals

In GA4: Admin > Data collection and modification > Data streams, open your web data stream, click Configure tag settings, expand the settings list with Show all, then open List unwanted referrals.

Add one condition per domain, match type Referral domain contains:

stripe.com
paypal.com
klarna.com
any 3DS or bank verification domain you see in your reports

To find the offenders, open Reports > Acquisition > Traffic acquisition, set the dimension to session source, and look for payment or bank domains that carry revenue. Those are the ones to list. Do not add domains that send you real customers.

Two things to know. The setting is per data stream, so repeat it if you run more than one. And it applies from the moment you save it forward - GA4 never reprocesses historical data, so past purchases stay misattributed.

When cross-domain linking applies instead

Cross-domain measurement is for a second domain you own and can tag: a separate checkout domain, an SSO portal, a landing-page domain on a different TLD. It lives on the same screen: Configure tag settings > Configure your domains. Add both domains and the Google tag decorates links between them with the _gl linker parameter, which carries the client ID across so the visitor stays one user in one session.

It does not apply to payment gateways, because you cannot run your Google tag on stripe.com. For gateways, unwanted referrals is the whole fix.

Here is why that is enough. The _ga cookie is set on your domain and never leaves it. When the buyer goes yoursite.com > gateway > yoursite.com, the cookie is still sitting there on return, so GA4 already knows it is the same person. The only thing the round trip breaks is the session source, and unwanted referrals repairs that. Subdomains share the _ga cookie too, so shop.example.com and www.example.com need no cross-domain setup.

Verify the fix

Do not trust the setting, watch the hits. Run a test order in the gateway's test mode and check each layer:

Browser network tab. DevTools > Network, filter collect. On the return page, inspect the request to google-analytics.com/g/collect. Before the fix, the dr parameter carries the gateway URL. After the fix, the same hit carries ir=1 (ignore referrer), which means the tag matched your unwanted referrals list. Test in a fresh incognito window and allow a few minutes for the tag configuration to update.
GA4 DebugView. Enable it through Tag Assistant, or set debug_mode: true in your Google tag configuration - a bare URL parameter does not switch it on. Do not use session_start as proof the referral fix worked: a return within the session timeout never fires one, with or without the setting. Use DebugView for the timeout case instead - if a slow test payment produces a fresh session_start on return, the session expired at the gateway and you need a longer session timeout, not the referral list.
Tag Assistant. Connect your domain at tagassistant.google.com and walk the full flow; you can inspect every hit and its referrer as it fires.
Realtime. Reports > Realtime confirms your test purchase event arrived at all.
Session source, next day. Build an Exploration with dimension Session source / medium and metric key events or purchases. From the change date forward, the gateway domains should stop accruing purchases and your real channels should recover their share.

What this setting will not fix

Three cases survive the exclusion list:

Sessions that expire at the gateway. GA4's default session timeout is 30 minutes. A slow bank transfer or a stalled 3DS challenge can pass that, and the return starts a genuinely new session with no source. You can raise the timeout under the same Configure tag settings screen (Adjust session timeout, up to 7 hours 55 minutes).
Consent-blocked cookies. If the visitor denied analytics cookies, there is no _ga cookie to survive the round trip, and every return looks like a new direct user. That is a consent mode problem, not a referral problem.
Historical data. The reports before your change stay wrong. Annotate the date and compare forward only.

FAQ

Why does GA4 show my purchases as (direct) / (none) after checkout?

(direct) / (none) means GA4 had no traffic source to credit, and List unwanted referrals cannot fix it - when the gateway strips the referrer, the exclusion has nothing to match. The usual causes: the payment took longer than your session timeout, so the return started a genuinely new session with no source; analytics cookies were blocked or lost, so the buyer looks like a new direct user; or there was no non-direct source inside the attribution lookback. Start by raising the session timeout and checking your consent setup.

Does the unwanted referrals list fix historical GA4 data?

No. GA4 applies the setting from the moment you save it and never reprocesses old data. Past purchases stay attributed to the gateway or to direct, so judge campaign performance from the change date forward.

Which domains should I add to the GA4 unwanted referrals list?

Start with stripe.com, paypal.com and klarna.com, then check Traffic acquisition for any other payment, bank or 3DS domains that appear as a session source with revenue attached. Only list domains that are part of your checkout flow, never domains that send you actual customers.

Do I need cross-domain tracking for Stripe or PayPal?

No. Cross-domain measurement requires your Google tag to run on both domains, and you cannot tag stripe.com or paypal.com. It is the right tool only for a second domain you own, such as a separate checkout or SSO domain. For gateways, List unwanted referrals is the correct fix.

I fix attribution problems like this for stores and agencies, usually server-side and always verified against real transactions. If you would rather have someone check your setup and confirm the numbers, email me at work@rytisbalys.com.

work@rytisbalys.com