Your Checkout Is on a Different Domain. Your Consent Record Did Not Follow It.

One funnel to the customer, two websites to the browser

Here is an architecture we run into constantly. The marketing site lives on the company's own domain, call it brand.com. The part that actually takes money, the ordering flow or the booking engine or the ticketing checkout, runs on a hosted platform. The vendor gives the brand its own space, and that space is a subdomain of the vendor's domain: brand.vendor.com.

To the customer this is invisible. The header is the same. The colors are the same. The logo is the same. They clicked "Order Now" and kept going. Nobody reads the address bar.

The browser is not fooled, and the browser is the thing enforcing your consent. The moment that click happens, the customer is on a different website as far as every cookie, every storage API, and every consent platform is concerned. Your banner is behind them. So is the answer they gave it.

The mechanic, stated plainly

A consent decision has to be stored somewhere so the next page knows about it. In practice that means a cookie or a browser storage entry, and both are scoped to a domain. A cookie set by brand.com can be shared down to order.brand.com or shop.brand.com, because those are the same registrable domain. It cannot be read by brand.vendor.com, because that is somebody else's domain entirely.

This is worth being precise about, because teams keep trying to solve it in the consent platform's settings. It is not a configuration mistake. There is no toggle. It is the same browser rule that stops any website from reading any other website's cookies, which is a rule you very much want to exist. No CMP can opt out of it, and any vendor telling you otherwise is describing something else, usually a redirect-based handoff that has to be built deliberately on both sides.

That leaves you in one of two states, and both are bad

There is no third option here. Either the transaction domain has a consent layer of its own or it does not, and each branch has a real cost.

State one: no consent layer on the transaction domain

This is the common one, because nothing about it looks broken. The marketing site has a banner, the banner works, and the compliance conversation ended there. Meanwhile every marketing tag on the checkout pages fires the moment the page loads, for everyone, with no consent state to check and nothing to gate against.

Consider which pages those are. Not the blog. Not the homepage. The pages where a person types their name, their email, their phone number, their shipping address, what they are buying and how much they are paying. The highest-sensitivity moment in the entire customer journey is the one page in the funnel running without a consent layer.

It usually comes with company. No opt-out link in that footer, because the footer belongs to the vendor's template. Nothing reading a browser-level opt-out signal, because there is nothing there to read it. If a visitor arrived with an opt-out already expressed, it stops mattering at the exact moment they hand over their payment details.

State two: a second banner, mid-purchase

The other branch is that somebody notices the gap and puts a consent layer on the transaction domain. Correct instinct, and now the customer gets a cookie banner on top of the payment form. They already answered this. They answered it four minutes ago. From their side it reads as either a bug or a dark pattern, and it lands at the single worst point in the funnel to introduce doubt.

So the honest summary is this: the architecture forces a choice between an unconsented checkout and an interrupted one. That is the actual problem, and it cannot be fixed with better banner copy.

"It's not our domain, so it's not our problem"

This is the first thing we hear, and it is worth taking seriously rather than waving away, because it feels right. You do not control that server. You cannot deploy to it. Somebody else's name is on the certificate.

The problem is that it applies the wrong test. None of the major privacy frameworks allocate responsibility by DNS. Under California's regime the obligated party is the "business," defined by who determines the purposes and means of the processing. The GDPR's controller definition has the same shape: whoever decides why and how the data gets processed. Both tests point at the party who made the decisions, not the party who happens to own the hostname.

In this setup, that is the brand. The brand chose the platform, configured the flow, and is the reason the customer's data exists at all. The vendor is processing on the brand's behalf, which is exactly what a service provider or processor is.

Then there is the part that ends the argument. Go and look at what is actually firing on those checkout pages. In nearly every case we audit, the marketing tags on the vendor's pages are the brand's own. The brand's advertising pixels, the brand's analytics property, the brand's conversion tags, added at the brand's request by the brand's team so that purchases show up in the brand's ad accounts. The vendor did not put them there and receives nothing from them.

Whatever the vendor's service-provider agreement covers, it does not cover those. You cannot point at a contract about the vendor's processing to explain your own tags collecting your own data for your own campaigns. We are describing how the definitions are structured, not giving legal advice, and your counsel should confirm how they apply to you. But "different domain" is not the shield teams assume it is, and it is better to find that out during an audit than during a records request.

If the gap between having a banner and actually enforcing consent is new territory, Cookie Banner vs. Consent Tool covers the distinction, and the enforcement pattern piece covers why the opt-out is the control that gets tested.

The version that works, and why some brands got it by accident

The setup that avoids all of this is simple to describe. The transaction flow runs on a subdomain of the brand's own domain, order.brand.com rather than brand.vendor.com. The consent cookie is set at the parent scope so every subdomain can read it. One banner, one answer, one record that covers the whole funnel including the payment page. GPC is honored everywhere. The opt-out link is in every footer because it is your footer.

Many platforms support this. It is usually a CNAME and a certificate, and on some plans it costs extra. Which brings up the part worth sitting with.

Almost nobody who has this arrangement chose it for privacy reasons. They set it up that way because they wanted the URL to look right, or because a developer four years ago preferred it, or because the plan they bought happened to include a custom domain. Their consent architecture is sound because of a branding preference. Meanwhile the brand next to them, running the identical platform on the vendor's default hostname, has a genuine compliance gap and an identical-looking website.

Nothing in either team's compliance review would surface the difference. It is not visible in the CMP dashboard, it is not visible in the tag manager, and it is not visible in the privacy policy. It is visible in the address bar, which is the one place nobody looks.

The two-minute check

You can settle this today without involving anyone.

1. Read the address bar during checkout. Open a fresh private window, walk your own funnel from the homepage to the payment step, and watch the hostname. If the registrable domain changes at any point, everything above applies to you. If it stays the same and only the subdomain changes, you are in better shape, but confirm the consent cookie is actually scoped to the parent domain rather than to one subdomain.
2. Watch what fires before you touch anything. On the transaction domain, open the network tab in a clean session and load the page without interacting. Filter for your advertising and analytics endpoints. Anything that fires before you have given consent has fired without it, and on this page in particular that matters.
3. Look for the opt-out link in that footer. Not on the marketing site, on the checkout page. A visitor who wants to exercise a right while they are standing on that page needs a way to do it from that page.
4. Send a GPC signal and see whether anything changes. Brave has it built in and there are extensions for other browsers. Turn it on, reload the transaction page, and compare the network requests to what you saw in step two. If they are identical, the signal is being received and disregarded.

Four steps, one browser, no access to anything internal. Which is precisely why this is worth checking: anyone outside your company can run the same test.

If the vendor will not allow a consent layer

Sometimes the answer from the platform is no. No custom scripts, no custom domain on your plan, no consent tooling on their pages. That is a real constraint and we do not pretend otherwise.

What it is not is a resolution. The obligation does not transfer to the vendor because the vendor's product cannot accommodate it. It becomes a contract question and a procurement question: what does the agreement say about tags on those pages, what does the platform commit to supporting, what does a custom domain cost, and what does the roadmap say. Those are answerable questions with owners attached. "The vendor does not support it" is a status, not an answer.

In the meantime the cheapest real mitigation is to reduce what fires there. If you cannot gate the tags on the transaction domain, take a hard look at which ones need to be there at all. A conversion tag firing on the confirmation page is a different risk profile from a full advertising stack running across every step of a form that collects names and payment details.

A record that cannot be read is not a record

It is easy to think of consent as a banner, because the banner is the part you can see and the part that got designed and approved. But the banner is just the interface. The thing that matters is the record it produces and whether the code that needs to honor it can actually read that record at the moment it needs to.

Across a domain boundary, it cannot. The customer gave you an answer, and the page where their data is most exposed has never heard it. Go check your address bar.