Payment Gateways Drop Cookies on Your Domain
Every time a visitor reaches your checkout page, third-party scripts from Stripe, PayPal, or Klarna load alongside your own code. Those scripts place cookies on your visitors' devices - some to prevent fraud, others to track behaviour across sessions.
The distinction matters. Under Article 5(3) of the ePrivacy Directive, storing information on a user's device requires consent unless the cookie is strictly necessary to provide a service the user explicitly requested. A cookie that detects card-testing bots fits that exemption. A cookie that profiles browsing habits for credit risk scoring may not.
Your responsibility as a site owner does not end because the cookie belongs to a payment provider. Data protection authorities hold you accountable for every cookie set on your domain, regardless of who placed it.
What Stripe Sets on Your Site
Stripe's JavaScript library (stripe.js) is loaded on any page where you collect card details. It sets two primary cookies on your domain.
__stripe_mid is a persistent cookie with a one-year lifespan. It assigns a unique device identifier used by Stripe Radar to build a fraud risk profile. __stripe_sid is a session cookie that expires after 30 minutes and tracks the browsing session during the payment flow. Both cookies transmit data to m.stripe.com, where Stripe's fraud detection models analyse device characteristics, mouse movements, and input patterns to distinguish legitimate buyers from bots.
Stripe states that this data is never used for advertising.
From a compliance standpoint, __stripe_sid is straightforward to classify as strictly necessary - it exists only for the duration of a payment session. __stripe_mid is more complicated. Its one-year duration and cross-session tracking extend well beyond a single transaction, which makes its classification as "strictly necessary" debatable under GDPR cookie consent rules.
What PayPal Sets on Your Site
PayPal's checkout SDK loads an iframe or redirect flow that introduces several cookies. The exact cookies depend on whether you use PayPal Checkout, Pay Later, or PayPal Express Checkout.
Session cookies such as ts and tsrce manage the checkout session and track the traffic source. x-pp-s stores encrypted session data. These expire when the browser closes or shortly after and are tied directly to completing the payment.
PayPal also sets longer-lived cookies. enforce_policy and cookie_check persist beyond the session. Some PayPal integrations - particularly Express Checkout embedded on product pages - set cookies before the visitor has expressed any intent to pay. That pre-emptive cookie placement is difficult to justify under the strictly necessary exemption in Article 5(3).
CNIL and other European data protection authorities have taken the position that cookies loaded before a user action cannot rely on the strictly necessary exemption. If PayPal's SDK fires on every product page rather than only at checkout, those cookies likely require opt-in consent.
What Klarna Sets on Your Site
Klarna's on-site messaging widget ("Pay in 3", "Pay later" badges) loads JavaScript that sets cookies for session management and fraud detection.
Klarna uses cookies to identify devices across sessions, monitor for fraudulent transactions, and personalise the payment options shown to returning visitors. The personalisation element is worth noting: tailoring available credit options based on prior browsing history goes beyond pure transaction processing.
Under GDPR and the ePrivacy Directive, personalisation cookies are classified as non-essential. If Klarna's script sets cookies that influence which payment options appear based on behavioural data, those cookies need consent before they fire.
Essential vs Non-Essential: How to Classify Payment Cookies
The classification depends on what the cookie does, not who sets it. A cookie that enables a payment transaction the user initiated is strictly necessary. A cookie that tracks the user for fraud modelling across multiple visits sits in a grey area.
| Cookie Purpose | Example | Classification | Consent Required? |
|---|---|---|---|
| Session management during checkout | __stripe_sid, ts | Strictly necessary | No |
| Cart persistence / order state | x-pp-s | Strictly necessary | No |
| Fraud detection (single session) | Short-lived device fingerprint | Strictly necessary | No |
| Fraud detection (cross-session, persistent) | __stripe_mid (1 year) | Debatable - lean non-essential | Likely yes |
| Personalisation of payment options | Klarna behavioural cookies | Non-essential | Yes |
| Analytics and conversion tracking | PayPal tsrce | Non-essential | Yes |
| Pre-checkout SDK loading on product pages | PayPal Express cookies | Non-essential | Yes |
The EDPB's guidelines on consent under the GDPR clarify that the strictly necessary exemption is narrow. The cookie must be essential to provide the specific service requested by the user. Fraud prevention supports the transaction, but persistent cross-session tracking extends beyond what the user explicitly asked for.
Where Payment Cookies Load Matters
Stripe's documentation recommends loading stripe.js on every page of your site for optimal fraud detection. More data points mean better fraud scoring. But loading a payment script - and its cookies - on your homepage, blog, or about page creates a compliance problem.
If a visitor has not navigated to your checkout, they have not requested a payment service. Cookies set on non-checkout pages cannot rely on the strictly necessary exemption. This same issue applies to Klarna's on-site messaging widgets and PayPal's Express Checkout buttons placed on product listing pages.
Two approaches reduce this risk. You can defer loading the payment script until the visitor reaches the checkout page. Alternatively, you can load the script everywhere but use your consent management platform to block it until the visitor either grants consent or initiates a payment action.
How to Handle Payment Gateway Cookies in Your Cookie Banner
Your cookie banner and cookie policy must account for every cookie on your domain, including those from payment providers. Ignoring them because "the payment gateway handles compliance" is not a valid position. Under GDPR, you are the data controller for cookies placed through scripts you chose to embed.
Start by running a cookie scan of your site. Payment gateway cookies often go undetected in manual audits because they only fire on specific pages or after particular user interactions. Automated scanning tools catch cookies that appear during checkout flows, form interactions, and iframe loads.
Once identified, categorise each payment cookie in your CMP. Session cookies tied to checkout belong in the "Strictly Necessary" category. Persistent fraud detection, analytics, or personalisation cookies belong in "Functional" or "Analytics" - categories that require consent under the ePrivacy Directive.
Document your classification rationale. If a regulator asks why you classified __stripe_mid as strictly necessary despite its one-year duration, you need a defensible answer. The evidence you prepare for a DPA investigation should include your reasoning for each classification.
Your Cookie Policy Must Name These Cookies
A compliant cookie policy lists every cookie by name, purpose, provider, and duration. Generic statements like "we use payment cookies" fail the transparency requirement under GDPR Article 13.
For each payment gateway, list the specific cookies set, who controls the data, how long the cookie persists, and whether it is classified as strictly necessary or requires consent. Link to the payment provider's own privacy policy so visitors can understand how their data is processed beyond your site.
Review your cookie inventory regularly. Payment gateways update their SDKs, and new cookies can appear without warning. Scheduled cookie scans catch these changes before a regulator does.
Frequently Asked Questions
Are payment gateway cookies strictly necessary under GDPR?
Session cookies that enable a checkout transaction the user initiated are strictly necessary. Persistent cookies used for cross-session fraud profiling or personalisation typically fall outside the strictly necessary exemption and require consent under Article 5(3) of the ePrivacy Directive.
Does Stripe set cookies on every page of my website?
If you load stripe.js on every page (as Stripe recommends for fraud detection), then yes - __stripe_mid and __stripe_sid will be set across your entire site. You can limit this by loading the script only on checkout pages or by blocking it via your consent management platform until needed.
Do I need to list PayPal cookies in my cookie policy?
Yes. Under GDPR Article 13 and the ePrivacy Directive, your cookie policy must list every cookie set on your domain, including those placed by third-party payment providers. You are responsible for cookies set through scripts you embed.
Can I block payment gateway cookies before consent?
You can block non-essential payment cookies before consent using a consent management platform. Strictly necessary cookies tied to an active checkout session do not require prior consent, but any cookies that fire before the user initiates a payment action should be gated behind consent.
Are Klarna cookies essential or non-essential?
Klarna session cookies used during an active buy-now-pay-later transaction are essential. Cookies used for personalising payment options based on prior browsing behaviour or for analytics purposes are non-essential and require consent.
Who is responsible for third-party payment cookies on my site?
You are. As the website operator, you chose to embed the payment gateway's script. European data protection authorities hold you accountable as a data controller for all cookies placed on your domain, even those set by third-party providers.
Take Control of Your Cookie Compliance
If you are not sure which cookies your payment gateways set, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
