Why your data breaks when checkout lives on another domain

Rhobin

July 31, 2026

7 min read

Cross-domain tracking is not a setting somebody forgot to switch on, it is the browser rule that a cookie belongs to one domain, worked around by passing an identifier in the URL, and payment redirects routinely break that workaround. What fixes it depends on whether the second domain is a subdomain, a separate domain your client controls, or a hosted checkout nobody can tag.

The symptom

Pull up the traffic report for a client whose checkout sits on a payment provider's domain, and the provider is one of the top sources. Nobody discovered the client through it, nobody bought anything on it, and it collects credit anyway.

Everything around it bends to match. More sessions than there were visits, because the same person is counted twice on the way through. More users than there are people. A cliff in the funnel where the customer leaves for checkout, purchases that arrive from nowhere, and Google Ads reporting fewer conversions than the client's order table.

Then the client asks which number is right, and none of them describe one journey, because the browser never treated it as one.

Why it happens

A cookie belongs to one domain

The identifier that ties a visit to a purchase lives in a cookie, and a cookie is scoped to the domain that set it. That is not a recent browser policy, it is the cookie specification. RFC 6265 says the browser "will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server", and ignores entirely a cookie whose domain does not match the host.

So when the customer crosses to a checkout on a different registrable domain, the identifier does not travel. The second domain reads no cookie and writes a new one. Google is blunt about the result: one person visiting two root domains "will be identified separately (two users and two sessions instead of one user and one session)".

The standard fix is a parameter in a link, and it has conditions

Cross-domain measurement moves the identifier out of the cookie and into the URL. GA4 passes it "from one domain to another via a URL parameter (_gl)", per Google's cross-domain measurement documentation. Google Ads does the mirror image: the conversion linker reads the ad click identifier from the landing page URL and stores it "in new cookies on your domain". Your domain. Not the checkout's.

The same documentation lists what that needs. Navigation has to be a real user action on a link or a form, and it "cannot work properly" when "navigation is triggered by JavaScript as opposed to a direct response to a user action", or when another script stops the click before the tag sees it. Even once it is on the URL the parameter can be lost, because after a redirect "the parameter _gl may end up being removed from the URL even if it was appended".

Now look at what a payment hand-off is: a script that builds a session, then a redirect, often several, sometimes a return trip through a bank or an authentication app. Each of those is one of the conditions above, and none of it applies when the customer finishes from the confirmation email on another device.

Safari puts a clock on the workaround

The workaround also expires faster than most people plan for. WebKit capped "all persistent client-side cookies, i.e. persistent cookies created through document.cookie" at a seven day expiry, and caps the same cookies at one day when two conditions are both met: a domain "classified with cross-site tracking capabilities" sent the user to the page, and the destination URL "has a query string and/or a fragment identifier".

A decorated link is a query string. The mechanism carrying identity across the boundary has the same shape as the thing that shortens its life, and the first condition depends on a classification you cannot inspect. That is much of why two clients on an identical setup report different Safari and iOS numbers and neither is misconfigured.

An embedded checkout fails differently

If the booking engine is embedded in the page instead of navigated to, there is no navigation to decorate. The frame is a cross-site context, and Safari blocks cookies there: "Cookies for cross-site resources are now blocked by default across the board." Firefox gives an embedded third party its own storage bucket per top level site, on by default since Firefox 103. Chrome kept its existing third-party cookie choice in April 2025. Three browsers, three behaviours, one dashboard averaging them.

Even a working setup gets the credit wrong

Suppose the stitching holds. The customer still arrives back from the payment domain, and that reads as a referral: "Because of the last-non-direct-click attribution model, this second session is also attributed to Domain B". The unwanted referrals setting suppresses it, capped at 50 domains per data stream. Worth doing, and it is a reporting correction, not a merge of two visits into one journey.

Consent does not cross the boundary either

Consent is stored the same way, on the domain that collected it, so the second domain does not know what the customer chose on the first. Vendors sell a feature for this and its preconditions are the tell: Cookiebot's cross-domain consent sharing documentation lists allowing third-party cookies among the requirements, which Safari does not do. On that traffic the second domain either asks again or runs without a recorded choice.

What good looks like

The first question is not technical. Whose domain is the second one?

If the checkout sits on a subdomain of the same registrable domain, this is not your problem. A cookie can be scoped to the parent and read on both hosts, which the domain matching rules in RFC 6265 allow. Confirm that before spending anything.

If it is a separate domain the client controls, stop leaning on a cookie the browser wrote as the only carrier of identity. A tagging setup on the client's own infrastructure can set its identifier in the server's response rather than from the page, and WebKit is specific that the seven day cap covers only cookies "created through document.cookie". Not a loophole, and it has a condition: cookies from a CNAME cloaked HTTP response are capped at seven days as well, so how the subdomain resolves decides whether the durability is real. Cookie lifetime measured in 400 days rather than days holds only when it is built that way.

If the checkout is hosted by a provider the client cannot tag, accept it. Nothing in the browser will carry that journey. What works is joining the two halves afterwards on the order identifier the platform already hands you, and sending the conversion from where the transaction is confirmed rather than from a thank-you page the customer may never load.

Archon Signal is the service we run for this: work out which case a client is in, rebuild the measurement so the conversion is sent from where it is confirmed, and keep referral and consent handling consistent on both sides. Typical recovery is 15-40% more conversions than the previous setup measured. The ceiling is roughly 95% of events and never all of them, because refused consent, blocked requests and network failure remove a share no architecture wins back. A broken hand-off is one contributor to the 15-30% of conversions that go consistently uncaptured, and how large a contributor depends on the case and the browser mix.

FAQ

Can we add the payment domain to the unwanted referrals list and be done?

Do it, because it stops the provider taking credit in the source report. It does not join the two sessions, so user counts and funnels stay wrong, and the list is capped at 50 domains per data stream. Treat it as tidying the reporting, not as the fix.

Does moving to server-side tracking fix cross-domain by itself?

No, and anyone saying otherwise is skipping a step. A server setup gives you an identifier written in a server response rather than by a script in the page, which is what makes it durable, and a place to send the conversion from once the order is confirmed. Two domains are still two domains, so the join has to be designed.

How do we tell how bad it is for one client?

Three checks, in order. Look for the checkout domain in the source report and see how many conversions it claims. Compare the client's order count with the platform's for the same period. Then split that by browser: a shortfall concentrated in Safari and iOS points at the cookie clock, a shortfall spread evenly points at the hand-off itself.

If a client's checkout lives somewhere else and the numbers have stopped agreeing, a free tracking audit will tell you which case you are in, and what it is costing, before anyone touches a tag.