Consent on the Checkout Page: The Tracking That Starts Before the Order Exists
A shopper fills a cart, reaches checkout, and types in an email address. The site has a consent banner, and the shopper rejected marketing cookies on the homepage ten minutes ago. None of that matters on the checkout page. The checkout loads analytics, a payment fraud score, and a session recording script, and none of them check the consent state first. The order does not exist yet. The tracking already does.
Checkout is the login page problem with money attached. It sits outside the marketing site, often on a subdomain or a separate application, and it is built by a different team with a different stack. The banner lives on the main site. The checkout loads its own tags, its own way, and the consent state from the homepage does not follow. A shopper who rejected tracking on the homepage gets tracked on the checkout, and the record says nothing about it.
Why the checkout escapes the banner
Three things usually go wrong. First, the checkout is a separate application, so the consent platform script is not installed there at all. The banner never renders, and no choice is ever asked. Second, the page is on a subdomain, and the consent cookie is scoped to the main domain, so even a working banner on the homepage cannot read the choice. Third, the checkout loads tools the team treats as essential, a bot check, a fraud score, a session recording, and nobody asks whether those tools need consent, because they are framed as security rather than tracking.
The security framing is where the argument gets sloppy. A fraud score that builds a profile across sessions is profiling, and it needs a legal basis. A session recording that captures keystrokes on a payment form is processing personal data, whatever the team calls it. The question is not whether the tool is useful. The question is whether the shopper was told and whether they had a choice. On most checkouts, the answer to both is no.
What the tag order actually looks like
Open the checkout in a fresh browser with the network tab open and reject everything on the homepage first. Then click through to checkout and watch what fires. The usual picture is an analytics request in the first second, a fraud scoring script loading its own cookies, and a session recording script starting before any field is filled in. The consent management platform, if it loads at all, arrives after those requests have already gone out.
The order matters because consent mode works on defaults. Google consent mode expects a default state to be set before any tag fires, and the consent platform is supposed to set that default. When the platform loads late, or not at all, the tags run on their own defaults, which is to say they run. The CookieYes troubleshooting guide puts it plainly: the consent platform tag has to fire first, through the consent initialization trigger, and any tag that fires before the default state is set is a defect, not a timing quirk. The Biscotti consent mode guide adds the consequence: since March 6, 2024, consent mode v2 has been mandatory for EEA and UK traffic, and the four signals, ad_storage, analytics_storage, ad_user_data, and ad_personalization, have to be set before the tags that depend on them.
What to check this week
Start with the subdomain question. Check whether the consent cookie is set on the parent domain so subdomains can read it, and whether the checkout actually loads the consent platform script. If either answer is no, the checkout is running without a consent record, and every choice a shopper made on the homepage is being ignored the moment they click buy.
Then list what the checkout loads and classify each item honestly. Analytics, chat, session recording, and fraud scoring each need a stated basis, and the ones that rely on consent need to wait for it. A fraud tool that is genuinely necessary for security can rely on legitimate interest, but that interest has to be documented, limited, and balanced against the shopper, not assumed. The record should show the reasoning, not just the decision.
Finally, test the withdrawal path from the checkout. A shopper who withdraws consent on the homepage and then checks out should stay withdrawn. If the checkout resets the state, or loads a fresh banner that defaults to accept, the withdrawal never happened in practice. The record will say the shopper withdrew at 2:14 pm. The network log will say the tracking continued at 2:15. The network log is the one a regulator reads.
Keep reading: what post-purchase pages track, where server-side tracking slips past consent, and the consent default that fires before the banner cover the nearby cases in this series.
Frequently asked questions
Does consent from the homepage carry over to the checkout page?
Only if the consent cookie is scoped to the parent domain and the checkout loads the same consent platform. Most checkouts sit on a subdomain or a separate application, and in that setup the choice made on the homepage is invisible. Check the cookie scope and the script, and test it by rejecting on the homepage and watching the network on the checkout.
Do fraud and security tools on a checkout need consent?
It depends on what they do. A fraud score that builds a profile across sessions is profiling, so it needs a legal basis. Security can be a legitimate interest, but the interest has to be documented and limited, and it does not cover analytics, chat, or session recording running on the same page.
How do I test whether my checkout respects a rejection?
Reject everything on the homepage in a fresh browser, then click through to checkout with the network tab open. Any request carrying an identifier, a fingerprint, or a tracking parameter before the order is placed is a failure. Run the same test on mobile, where banners load later and the gap is usually wider.
What if the checkout is a separate application we do not control?
That is the common case, and it does not remove the obligation. The consent platform has to be installed on the checkout application, or the checkout has to read the consent state from the main site. If the vendor will not support either, the tracking on that page has to be limited to what is strictly necessary until the vendor does.