FinTech and Cookie Consent: Navigating PCI DSS, PSD2, and GDPR Together

Why Fintech Sites Face Triple Compliance

Most websites deal with one privacy framework. Fintech companies don't get off that easy. If you process payments, operate in Europe, and collect user data through your website, you're answering to three regulatory frameworks simultaneously: PCI DSS for payment card security, PSD2 for payment authentication, and GDPR for data protection and consent.

These frameworks weren't designed to work together. PCI DSS 4.0 demands strict control over every script running on a payment page. PSD2's Strong Customer Authentication (SCA) requires session cookies and device fingerprinting that look like tracking to a consent management platform. And GDPR requires informed, granular consent before setting non-essential cookies, even when those cookies serve a fraud prevention function.

A single misconfigured cookie banner can create problems across all three frameworks. Block a fraud detection cookie because the user declined analytics? You've weakened your SCA implementation. Allow a marketing pixel on your checkout page? You've expanded your PCI scope and created a skimming vector. Getting this right requires understanding where these frameworks overlap and where the actual risk sits.

PCI DSS 4.0: What Changed for Payment Pages

PCI DSS 4.0 introduced two requirements that changed how fintech companies must handle scripts on payment pages. Both took full effect on March 31, 2025.

Requirement 6.4.3: Script Inventory and Authorization

Requirement 6.4.3 mandates that all scripts loaded on payment pages are managed with three controls: a method to confirm each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts with written justification for why each is needed. Every JavaScript file on a page where cardholder data is entered must be cataloged, justified in writing, and integrity-verified.

Requirement 11.6.1: Tamper Detection

Requirement 11.6.1 requires a change-and-tamper-detection mechanism on payment pages as received by the consumer's browser. It's not enough to monitor server files. You need to detect when page content or HTTP headers have been modified between your server and the user's browser. Detection must run at least every seven days, or per a targeted risk analysis.

The SAQ A Nuance

Companies that fully outsource payment processing via hosted pages or embedded iframes may qualify for SAQ A. In v4.0.1, the PCI SSC removed the explicit requirement for SAQ A merchants to validate 6.4.3 and 11.6.1, replacing it with an eligibility criterion: the merchant must confirm its site is "not susceptible to attacks from scripts." FAQ 1588 (February 2025) clarified that merchants with embedded payment forms must either implement technical controls aligned with 6.4.3/11.6.1 or get confirmation from their processor that the embedded solution includes script attack protections. The requirement shifted form, not substance.

The Magecart Problem and Third-Party Script Risk

Requirements 6.4.3 and 11.6.1 exist because of Magecart. These threat groups inject malicious JavaScript into payment pages to skim card data in real time. Over 11,000 e-commerce domains were infected in 2024, a 300% year-over-year increase. In January 2026, researchers exposed a network that had operated undetected since 2022, harvesting payment data from six major card networks.

Current attack techniques include supply chain compromise (injecting skimmers into legitimate third-party scripts like analytics libraries), GTM container hijacking (injecting malicious tags into a site's Tag Manager), WebRTC exfiltration (using peer-to-peer channels that bypass CSP rules), and SVG overlay injection (rendering fake payment forms over real ones).

Every third-party script on a payment page has full DOM access. A marketing pixel on your checkout page can read form field values, intercept keystrokes, and exfiltrate data. Its intended purpose is conversion tracking; its technical capability includes reading credit card numbers. This is why fintech companies that run the same tag management configuration across marketing and payment pages are creating unnecessary PCI scope. A script that's fine on your blog becomes a compliance liability on your checkout flow.

On fintech sites, the risk compounds. Analytics cookies capture financial behavior: which loan amounts users explored, whether they abandoned a credit application. A compromised analytics script exfiltrates financial details, not just browsing patterns. And PCI QSAs will flag every marketing tag on a payment page during assessments.

Strong Customer Authentication and Consent Interactions

PSD2's SCA requirement mandates multi-factor authentication for European electronic payments: at least two of knowledge (password), possession (device), and inherence (biometric). The 3D Secure 2 protocol implements SCA for card payments and relies on browser-side data to function.

Several cookies are essential to SCA flows: session cookies maintain authentication state during the 3DS challenge (blocking them causes payment declines), device fingerprinting data helps issuers assess transaction risk through browser metadata, and SCA exemption cookies store flags for low-value or trusted-beneficiary exemptions (blocking them forces re-authentication on every transaction).

The tension: GDPR requires consent before setting non-essential cookies, but SCA data collection can be classified as essential for contract performance (Article 6(1)(b)) or legitimate interests (Article 6(1)(f)). The classification depends on scope. A session cookie for payment state is clearly essential. A device fingerprint that also feeds a broader analytics model starts to blur the line.

The safest approach: classify SCA-supporting cookies as strictly necessary under ePrivacy (they're required for the service the user requested), document this classification, and ensure your consent platform doesn't block them. But keep SCA data collection narrowly scoped. The moment device fingerprinting data flows into a marketing pipeline, the "strictly necessary" argument collapses.

Which Cookies Are Essential for Payment Processing

Strictly necessary (no consent required)

• Session cookies: login state, order state during checkout, authentication tokens through multi-step flows
• CSRF tokens: prevent cross-site request forgery on payment forms
• Fraud detection cookies: first-party cookies for session behavior patterns (velocity checks, device consistency), narrowly scoped to fraud prevention only
• Load balancer cookies: session affinity through multi-step checkout
• SCA/3DS session cookies: state during Strong Customer Authentication challenge-response
• Consent preference cookies: the user's own consent choices

Requires consent

• Analytics cookies (GA4, Mixpanel, Amplitude): not required for payment completion
• Marketing and retargeting (Meta Pixel, Google Ads tags): require consent and create PCI scope issues on payment pages
• Session replay (Hotjar, FullStory): record keystrokes on payment forms, a compliance nightmare across all three frameworks
• Non-essential preferences: theme, UI customization, "remember me" beyond core payment service

The critical principle: classification depends on what a cookie actually does, not what the vendor calls it. A "fraud detection" cookie that feeds an analytics dashboard isn't strictly necessary. A "performance" cookie tracking journeys across marketing and payment pages is analytics wearing a different label.

Implementing Consent Without Breaking Payment Flows

Your consent banner must block non-essential scripts before consent, but never block scripts essential for payment completion. Getting this wrong means either payment failures (blocking 3DS scripts) or compliance violations (allowing tracking before consent).

1. Load essential payment scripts independently of the consent manager. CSRF tokens, session management, SCA/3DS scripts, and fraud detection cookies should initialize without waiting for consent decisions. Code them directly into the page rather than managing them as conditional tags.

2. Audit the "strictly necessary" category regularly. Teams sometimes dump scripts into this category to avoid consent friction. Each entry needs the same written justification that PCI DSS 6.4.3 requires for payment page scripts.

3. Test the full payment flow with all optional cookies rejected. Complete a payment end to end with all non-essential cookies declined. If any step breaks, you've miscategorized a required cookie or your consent logic is blocking something it shouldn't.

4. Handle consent state before redirecting to payment. If checkout redirects to a hosted payment page, capture consent state before the redirect and pass it server-side. The payment page shouldn't show another banner but needs to know the user's consent state.

5. Don't overlay the consent banner on the payment form. A popup obscuring card entry fields drives abandonment. Show the banner before checkout or use a non-blocking bottom bar.

Isolating Payment Pages from Tracking Scripts

The simplest way to satisfy both PCI DSS 4.0 and GDPR is to keep payment pages and marketing pages in separate script environments.

Separate subdomains. Run marketing on www.example.com and payments on pay.example.com. Each gets its own GTM container (or none on the payment subdomain). This creates a clean PCI scope boundary.

Hosted payment pages. Use your processor's hosted checkout (Stripe Checkout, Adyen Drop-in). The payment form runs on the processor's domain, and their PCI compliance covers it. But you still need to manage scripts on pages that embed the hosted form.

Iframe isolation. Embed the payment form in a processor iframe. Same-origin policy prevents parent-page scripts from accessing the form's content, provided your scripts can't modify or overlay the iframe.

Technical controls

Implement a strict Content Security Policy on payment pages that whitelists only authorized script sources, with no unsafe-inline or unsafe-eval, and report-uri configured for violation monitoring. Subresource Integrity (SRI) pins the expected hash of external scripts, but breaks when vendors update files. For frequently changing scripts, use server-side proxying or version-pinned URLs.

CSP and SRI are techniques that help satisfy PCI DSS requirements, but neither alone constitutes full compliance. Requirements 6.4.3 and 11.6.1 call for inventory, authorization, integrity verification, and tamper detection working together.

How CookieBeam Handles Fintech Compliance

Script inventory and classification. CookieBeam's automated scanner detects every cookie, script, and outbound connection on your site, including payment pages. The results map directly to the inventory PCI DSS 6.4.3 requires. Each script gets classified by purpose, giving your compliance team a baseline for PCI documentation and consent configuration simultaneously.

Default-block architecture. CookieBeam blocks all non-essential scripts before any code executes, not after the banner renders. No race condition where a marketing pixel fires before consent. For details on how this works, see our script blocking comparison.

Payment page isolation. Page-level consent policies let you configure payment pages to allow only strictly necessary scripts regardless of consent state elsewhere. Marketing cookies accepted on your homepage don't follow users into checkout.

Drift detection. CookieBeam monitors for new scripts and connections appearing on your pages. If someone adds a pixel to a payment page template, or a supply chain compromise introduces an unauthorized script, drift detection catches it. This feeds into PCI DSS 11.6.1's tamper-detection requirement.

Server-side consent enforcement. Consent state integrates with server-side blocking so decisions are enforced beyond the browser. No consent, no data forwarding, at every layer.

For fintech companies, the practical benefit is handling PCI script management and GDPR consent with a single tool rather than maintaining separate inventories for your QSA and your DPO.

Compliance Checklist

• Audit payment page scripts. Build the inventory PCI DSS 6.4.3 requires: what each script does, why it's there, who authorized it, and how integrity is verified.
• Remove non-essential scripts from payment pages. Analytics, marketing pixels, session replay, and social widgets don't belong on pages that collect card numbers.
• Implement tamper detection. Deploy CSP with report-uri, add integrity checks (SRI where feasible), and monitor for unauthorized changes weekly per 11.6.1.
• Classify payment cookies correctly in your CMP. Session, CSRF, fraud detection, and SCA cookies are strictly necessary. Document why. Audit quarterly.
• Test payments with all optional cookies rejected. If checkout breaks, you have a miscategorization.
• Isolate payment page script environments. Separate GTM containers, stricter CSP, and page-level consent policies.
• Align consent records with PCI documentation. Your CMP's inventory and your PCI script inventory should tell the same story.
• Review SCA dependencies. Confirm 3DS2 scripts aren't blocked by consent logic. Test the full SCA flow with non-essential cookies rejected.

PCI DSS, PSD2, and GDPR will continue evolving independently. The fintech companies that handle this well will treat script management, consent, and payment security as a single discipline rather than three separate checklists maintained by three separate teams.