The Banner Cannot Block the Purchase: Consent at Checkout

The shopper is at checkout with a card in hand. The consent banner covers the pay button. The banner has no reject option visible, or it has one buried two clicks deep, and the shopper cannot pay until they answer a question they did not come to answer. Some of them accept, because they have to. Some of them leave, because they will not be held hostage by a popup. Either way the banner has done the opposite of its job: it has turned a privacy control into a barrier to the purchase.

The conflict

Consent banners and checkout want opposite things. The banner wants an answer before anything else happens. Checkout wants the shopper to finish as fast as possible, with as little friction as possible. When the banner wins, the shopper pays a privacy tax to complete a purchase, and the consent that results is not freely given, which is the standard the GDPR sets. Consent must be freely given, specific, informed, and unambiguous, and a shopper who accepts because the pay button is covered has not freely given anything. They have paid a toll.

The second conflict is technical. A banner that loads late, or that blocks the page until it is answered, delays the checkout scripts behind it, and a delayed checkout is a lost sale. The banner that appears after the tags already fired is the same failure from the other side: the shopper's data left before the question was asked. Both failures come from treating the banner as a gate on the whole page, instead of a control on the tags.

What the regulators actually require

The requirement is narrower than most teams think. Consent is required before setting non-essential cookies and before sharing data for advertising and analytics, not before the shopper can buy something. The banner must not block access to the service, and the reject path must be as easy as the accept path: one click to accept means one click to reject, with no extra steps, no buried link, no dark pattern. The CNIL and the EDPB have both fined for exactly this layout, a bright Accept button and a grey Reject link hidden in a submenu, and the fines are the reason the reject button is the whole banner.

The banner also has to respect the choice it records. A shopper who rejects must not be asked again on every page, and must not find the tags firing anyway because the banner never told the tag manager. A banner that records a rejection and then fires the tags is worse than no banner, because it creates a record of a choice the site ignored.

The checkout pattern that works

Keep the banner out of the checkout flow entirely. Show it on entry, record the choice, and let checkout run on the choice already made. If the shopper has not chosen yet, default to denied and let the purchase proceed: the tags stay restricted, the cookieless pings still flow for modeling, and the shopper pays without answering a question they did not come to answer. The banner reappears on the next non-checkout page, where the shopper has time to read it. A banner that blocks the pay button is not a privacy control. It is a dark pattern with a compliance excuse. For the reject button itself, see the reject button is the whole banner, and for the toggles that make the choice real, why granular consent beats Accept All.

Frequently asked questions

Can a consent banner block the checkout button?

No. Consent must be freely given, and a shopper who accepts because the pay button is covered has not freely given anything. The banner must not block access to the service, and the reject path must be as easy as the accept path.

What if the shopper has not chosen yet at checkout?

Default to denied and let the purchase proceed. The tags stay restricted, cookieless pings still flow for modeling, and the banner reappears on the next non-checkout page. The purchase does not wait for a consent answer.

Does the banner have to appear on every page?

No. Show it on entry, record the choice, and respect it everywhere. A shopper who already chose must not be asked again on every page, and a shopper who rejected must not find the tags firing anyway.

Is a banner that delays checkout a compliance problem or a conversion problem?

Both. A delayed checkout loses sales, and a banner that forces acceptance to complete a purchase produces consent that is not freely given, which fails the GDPR standard. The fix serves both goals at once.