GA4 Cross-Domain Tracking: Payment Providers and the Checkout Gap

A customer arrives from a paid search ad, adds a product, and clicks through to pay. The payment provider takes over the next few screens. The purchase completes and the customer lands back on your confirmation page. In GA4 the campaign that paid for the visit gets nothing, and the revenue is attributed somewhere else or to nothing at all.

The cause is usually the same. Cross-domain measurement is built for two or more domains you control and can tag. A hosted checkout on a payment provider's domain is not one of them. No setting in GA4 will make it follow a customer onto a domain where your measurement tag is not running, and teams burn weeks trying when the answer sits somewhere else entirely.

How the linker carries a user across domains

GA4 sets first-party cookies for each user and each session. Those cookies can only be read by pages on the domain that set them, which is why a visitor moving from one root domain to another normally arrives as a new user with a new session.

Cross-domain measurement closes that gap with a URL parameter. When a visitor clicks a link or submits a form that points at a destination domain on your list, GA4 decorates the URL with a linker parameter under the key _gl. On arrival, the Google tag on the destination domain reads that parameter and restores the same cookie values, so Analytics reports one user and one session instead of two.

Three details matter in practice. The linker reacts to a click or a form submit, so it works for navigation a person triggers and not for navigation JavaScript triggers on its own. The parameter expires after two minutes, which means it is added at the moment of the click rather than when the page loads. And the whole mechanism depends on the parameter surviving the trip.

What cross-domain measurement can and cannot follow

Cross-domain measurement works for domains where you can place the same tag. Google's setup requires the same Google tag ID, the same G- identifier from the same web data stream, on every page of every domain in the list. If you own the marketing site, the store and the support portal, that is fine. You tag all three and linking works.

Stripe Checkout, PayPal and other provider-hosted payment pages sit outside that boundary. You cannot install your Google tag on a provider's checkout domain, so there is no second tag to read the linker parameter and no way to continue the session through the payment step. The visitor leaves your measurement surface for the duration of the checkout.

Google names this exact case in its referrals documentation, where a third-party payment processor is listed as a common reason an ecommerce site would want to suppress a domain from its referral reports. That listing is the tell. The payment domain is handled as a referring source to be ignored, not as a domain to be linked.

Two settings that get confused

GA4 has two controls and they do different jobs. Configure your domains, sometimes called cross-domain measurement, tells Analytics which domains belong to the same user journey. List unwanted referrals, sometimes called referral exclusion, tells Analytics which domains should not be reported as a traffic source.

Using the wrong one produces a specific failure. Add a payment provider to Configure your domains and nothing changes, because there is no tag on that domain to accept the link. Add your own subdomain to unwanted referrals when you should have linked it, and you stop the site reporting self-referrals while the session still splits at the boundary. The two lists are not interchangeable. Decide which side of the boundary each domain sits on before you touch either one.

Setting up Configure your domains

The cross-domain list lives under Admin, then Data collection and modification, then Data streams. Open the web data stream, scroll to Configure tag settings at the bottom, then open Configure your domains.

Two rules get missed. You need Editor or above at the account level, and GA4 allows up to 100 conditions on the list. If the same Google tag already runs across the domains you want to link, they are detected automatically and appear as recommendations you can accept in one click. Anything else is added by hand, by choosing a match type, entering the domain, and repeating for each one. The conditions combine with OR logic.

The most common error is the match itself. If you entered www.example.com and your links point at example.com, Google treats those as different hosts and the linker never fires. Entering the root domain with a contains match covers the subdomains underneath it. Check the host in the URL of the page you are leaving, not the brand name you assume you use.

Setting up unwanted referrals

The referral list sits one level deeper: the same web data stream, Configure tag settings, then Show all, then List unwanted referrals. A data stream allows up to 50 unwanted referrals, and those conditions also combine with OR logic.

What the setting actually does is worth stating plainly. When an event matches a condition, Analytics appends a parameter called ignore_referrer with a value of true. That parameter tells Analytics to drop the referrer as a traffic source. It does not remove the sessions from your reports, and it does not work backwards, so the domain can still appear in historical data for the period before you added it.

Permission differs between the two lists. Cross-domain measurement needs Editor or above at the account level. Unwanted referrals need Editor or above at the property level. In a large organisation where those grants are held by different people, that difference decides who can make the change.

Why the checkout still loses the source

Even with the referral exclusion in place, the campaign data does not always survive the round trip. What saves it is attribution rather than tracking. When the customer returns from the payment provider, Analytics sees a new session referred by that provider. Because the provider is on the exclusion list, the referrer is ignored, no new traffic source is recorded, and the original source is retained under the last non-direct-click model.

Three things break that chain. If the customer spends longer at the payment step than the session timeout allows, the session has already ended and the returning visit starts fresh, which no exclusion can repair. If the purchase event does not fire on a tagged page after the return, the revenue never lands in the property at all. And if the provider posts the purchase back to your server rather than sending the customer to a confirmation page, there is no browser session to attach it to, so the transaction has to be joined to a client identifier another way.

Google's documentation flags a further wrinkle on excluded referrers. A returning visitor can still be attributed to the excluded domain if their first session arrived from it before you added the exclusion. Google's own example walks through it. A user arrives from domain B, the first session is attributed to domain B, domain B is then excluded, and the same user returns directly from a bookmark. Under last non-direct-click that second session is attributed to domain B as well. The exclusion governs new referrers, not every session that follows.

The traps that strip the linker parameter

When cross-domain measurement is configured correctly and still fails, the parameter is usually being lost in transit. Google names two causes.

The first is redirects. If the destination page redirects, or does not accept arbitrary query parameters, the _gl value can be dropped from the URL before the tag reads it. This happens too fast to catch by eye. A login wall that bounces a visitor through an authentication host is the classic case. The fix is to configure the site to preserve the parameter across the redirect.

The second is competing scripts. The linker works by listening for clicks on the document node. If another script stops the event before it reaches that node, commonly by calling Event.stopPropagation(), the linker never sees the click. Navigation triggered by JavaScript rather than by a person clicking a link fails for the same reason.

Forms are a separate case. The linker decorates form submissions only when form decoration is switched on, so a checkout that submits a form rather than following a link needs that setting left enabled.

What to check before blaming GA4

Open the page that holds the outgoing link, click it, and look at the address bar on arrival. A working setup shows _gl in the URL, in the form ?_gl=1*abcde5*. If the parameter is present, the linking is working and the problem is downstream, in the referral list or in the purchase event. If it is absent, the problem sits on the source page, in the domain match, or in one of the traps above.

Three other checks catch most of the rest. Confirm every domain in the list carries the same G- tag ID, because a single stream is what makes the shared identity meaningful. Confirm consent was granted on the arrival page, because Analytics only sets and reads the measurement cookies when it has consent. And confirm the timing, since a checkout that regularly runs past the 30 minute session window will produce a new session no matter how clean the linking is.

A short routine for a checkout that spans domains

List every domain a buyer touches between the landing page and the confirmation page. For each one, decide whether you can place your tag on it. Domains you can tag belong in Configure your domains, with the root domain entered correctly and one shared G- ID. Domains you cannot tag, which usually means the payment provider, belong in List unwanted referrals. Then confirm the purchase event fires on a page you control, check that _gl survives the trip, and test the whole path in a browser with a clean profile rather than trusting the settings page.

The UK compliance angle

Cross-domain measurement moves identification between domains, and it does so by placing cookie values into a URL. That mechanism is a storage and access technology like any other, so the rules you apply to the rest of your measurement apply here. The ICO guidance on storage and access technologies, finalised in April 2026, is the document to read. Analytics used to improve your own service can sit inside the statistical purposes exception, provided you give clear information and a simple means of objecting free of charge. Advertising measurement does not qualify for that exception and stays behind consent.

The practical consequence is that linker behaviour is only as good as your consent handling. If a visitor arrives at the destination domain without consent, there is no cookie to restore, and the shared identity the linker was meant to carry does not exist. A consent setup that differs between your two domains produces a measurement setup that differs between them too.