Consent on Checkout Pages: What a Banner Must Never Block
Checkout is the worst page on a site for a consent banner to misbehave, and banners misbehave there constantly: the accept button covers the pay button on a small phone, the banner reappears because the consent cookie was set on a different subdomain, or the reject path reloads the page and empties a cart the shopper spent twenty minutes building.
The legal duties do not shrink at checkout. Consent still has to be freely given, trackers still wait, and the record still matters. What changes is the cost of clumsiness, measured in abandoned orders instead of annoyed pageviews, which means checkout deserves its own consent test pass, not a assumption that the homepage test covered it.
Nothing essential under the banner
The rule is simple to state: the banner must not block the ability to complete a purchase, read the total, or reach legally required information, for any visitor, including one who never interacts with the banner. On mobile this is a geometry problem. A bottom banner of careless height covers the sticky pay bar exactly, and the overlap is invisible in desktop testing, which is how it ships.
Test on a small viewport with the banner present and scrolled, not just on load. Test with the device keyboard open too, because the shopper who goes to enter a discount code with the banner up is living in a layout nobody designed. If dismissing or deciding is the only way to reach the pay button, the consent is not freely given in any meaningful sense, it is a toll.
Subdomains and the reappearing banner
The classic checkout failure is consent amnesia: the main site sets consent on the root domain, the checkout runs on a subdomain or a separate checkout domain, and the banner asks again at the worst moment, sometimes losing the cart's marketing tags, sometimes losing the cart. The fix is configuration, sharing consent state correctly across the domains the journey uses, and it has to be tested as a journey: arrive, consent, add, check out, in that order, on the real domains.
Our audit log export work in Your Consent Audit Log Is Only Useful If Someone Else Can Read It is relevant here because a journey across domains produces records in two places if the setup is wrong, and reconciling them during an inquiry is nobody's idea of fun. One journey, one record, one banner appearance: that is the acceptance test.
What may load, what must wait, at checkout
Checkout pages attract their own trackers: fraud tools, payment analytics, session replay, support chat. Session replay on a payment page deserves its own hard look regardless of consent, because of what it can capture, and consent tooling that treats it as ordinary analytics is making a decision you should make consciously instead. Sort the checkout tag list separately from the site tag list; it is shorter, more sensitive, and more stable, which makes it the easiest list on the site to keep exactly right.
When the vendor list changes, the notice discipline in You Added a Vendor on Tuesday. Your Consent Text Still Describes Last Month. applies with checkout stakes: a new tag on the payment page is a material change, and quiet additions there are how a well run consent setup rots. Keep the checkout tag inventory under change control and the banner will keep deserving the trust the pay button needs.
Frequently asked questions
Can a consent banner block the checkout button?
It should not block completing a purchase, reading the total, or reaching required information, whether or not the visitor interacts with it. On mobile especially, test with the banner visible and scrolled: overlap between a bottom banner and a sticky pay bar is a common shipped bug and it undermines freely given consent.
Why does the consent banner reappear at checkout?
Usually because consent state is not shared correctly between the main domain and the checkout subdomain or checkout domain. The consent cookie or storage must be scoped so the whole journey shares it. Test the full journey on the real domains: arrive, consent, add to cart, check out.
Should session replay run on checkout pages?
Treat it as a separate, conscious decision. Replay tools on payment pages raise capture risks beyond ordinary analytics, and consent categories should reflect that sensitivity. Audit the checkout tag list separately from the rest of the site; it is shorter and more sensitive.
Do consent rules change on checkout pages?
The legal duties are the same: consent must be informed and freely given, non essential trackers wait, and records must be kept. What changes is the cost of implementation errors, which is measured in abandoned orders and payment page risk rather than ordinary page friction.