A buyer clicks through to checkout, pays, and returns to the store. The order is real. The measured journey may still look like a new visitor arriving from a payment company, or like a visit that never purchased at all.
Cross-domain checkout problems are easier to solve when the team separates three questions: Did analytics recognize continuity across the domains it can measure? Did it attribute the return sensibly? Was the purchase recorded against the correct order?
Those questions overlap, but changing one setting does not answer all three. Begin with the actual route the buyer takes, including every intermediate redirect.
Draw the boundary you control
List each domain in the journey and who controls its pages, analytics configuration and redirects. Distinguish a checkout hosted on another merchant-controlled domain from a payment processor’s page where you cannot install your own tag.
For participating domains, Google’s cross-domain documentation requires the same tag ID from the same web data stream. Its linker passes identifiers using the _gl URL parameter. A matching property name in two settings screens is not enough to establish that configuration.
Do not assume a third-party processor can join that setup. Confirm what the provider supports, then design the measurable boundary around those capabilities. The store’s outgoing step, supported checkout integration, return page and authoritative order record may be the practical points available to you.
Also record consent and browser conditions for the check. A journey observed under one condition does not establish behavior for every visitor.
Trace one journey as a sequence
Consider a fictional store on shop.example and a separate merchant-controlled checkout on pay.example. These are reserved example domains, not a live integration.
The expected sequence is:
- A visitor arrives at the store with a known acquisition source.
- The checkout link is followed and the destination carries the linker parameter.
- Any checkout redirect preserves that parameter until the receiving page can use it.
- The checkout uses the intended analytics configuration and records the relevant activity.
- A confirmed order receives its purchase measurement with the correct transaction identity.
In a simple illustrative redirect fixture, the initial destination is pay.example/start?_gl=synthetic-linker. One redirect preserves the parameter at /checkout; another redirects to /checkout without it. Parsing those URLs shows the parameter present in both steps of the first path and absent at the final step of the second.
That demonstration only checks query-string preservation. The token is deliberately fictional. Its presence cannot prove that real analytics identifiers were valid, consumed or associated with the same journey.
This distinction helps scope the investigation. A URL check can expose an obvious break quickly. It cannot replace inspecting the receiving page’s measurement behavior.
Look at redirects in the network record
An intermediate URL may appear too briefly to see in the address bar. Preserve the browser’s network log while following the real checkout path and inspect each navigation response and destination.
Google specifically notes that redirects can remove _gl, and advises preserving it through the redirect. Its documentation also describes script-driven navigation and interrupted click propagation as possible obstacles to linker behavior. See the cross-domain troubleshooting guidance.
For your own pages, compare the configured domain with the actual destination. A campaign may lead to a different checkout hostname, or a regional route may add a redirect that the main flow never uses. Record the full chain rather than testing only a manually pasted final URL.
Make the smallest supported repair at the point where the information is lost. Then repeat the normal click path. A successful direct visit to the checkout page does not demonstrate that the store-to-checkout handoff works.
Referral handling is a separate check
A payment processor may appear as the referring source when a buyer returns. Google’s unwanted-referral guidance identifies this as a use case for referral exclusion. Matching events receive ignore_referrer=true, indicating that the referrer should not be presented as a traffic source.
That setting governs referral treatment. It does not establish that a lost linker was restored, an anonymous identity was joined correctly or a missing order event was delivered. If the source label looks better after a change, still check the journey and purchase independently.
Use a small set of known test journeys with distinct entry conditions. Record the original source, handoff route, return route and observed reporting behavior. Explain any remaining attribution uncertainty rather than forcing every discrepancy into the payment-referral category.
A return page is not the order system
Some buyers pay successfully without reaching the merchant’s return page. Stripe’s hosted Checkout fulfillment guidance explicitly warns against relying only on that landing page and requires webhooks for reliable automatic fulfillment.
The measurement implication is straightforward: a missing return-page view is not sufficient evidence of an abandoned payment. Reconcile the purchase measurement against the supported payment and order records, using the transaction definition appropriate to the integration.
Keep fulfillment and analytics responsibilities clear. A payment notification may establish an order state without automatically establishing the visitor’s analytics identity or acquisition source. Likewise, a browser purchase message does not independently prove that the order reached the required payment state.
For an implementation review, ask which system decides that a purchase occurred, which component emits the measurement and how it obtains the order identifier. Document how retries and repeat visits are handled so a repair to continuity does not introduce duplicate purchase messages.
Verify the boundaries that matter to the business
A compact check should cover the normal purchase route, an intermediate redirect, a canceled or failed payment, a successful return, and a successful payment where the return page does not load. Use the provider’s supported test facilities and avoid treating these as interchangeable outcomes.
For each path, keep three results: continuity of the measured visit, treatment of the referral, and reconciliation of the order event. Add the browser, device and consent condition so the finding has a defined scope.
If one path remains unobservable because the provider does not expose the required measurement, state that limit. Do not install unsupported tags or invent a complete funnel from partial signals. A useful report can distinguish known orders from the portion of their journey analytics can reliably describe.
The next conversion analysis should use that distinction. Once the handoff is understood, a fall in reported purchases can be investigated as buyer behavior, collection loss or an attribution change with much less guesswork.