Adyen and PCI DSS: What the Processor Covers vs. What You Must Do

TL;DR: Adyen iframe boundary for PCI DSS 6.4.3 scripts

• Processor boundary: "We use Adyen" tells your QSA where card data lives, not what your tag manager is doing while a shopper types a card. Adyen's responsibility ends at its iframe border, and every parent-page script stays yours under PCI DSS 6.4.3 and 11.6.1.
• Real-world risk: The 2024 Polyfill[.]io script was embedded on more than 490,000 sites and turned malicious overnight, exposing Adyen Drop-in merchants with perfectly isolated card fields. cside PCI Shield inventories every payment-page script, including the Adyen SDK loader, with full change history.
• By integration type: If you run Hosted Payment Pages or Drop-in, script inventory and tamper detection still ride on your side. If you run API-only, every script sits in the direct path of raw card data, so browser-layer monitoring is not optional.

Short on time? See cside PCI Shield. It covers everything below in one deployment.

What Adyen covers vs. what you still own

Adyen, like any PCI DSS Level 1 processor, attests the code that runs inside its own iframe. It does not attest the page that frames it. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 govern the scripts on your payment page in the consumer browser, and most of those scripts are yours. The script-ownership boundary is the edge of Adyen's frame, and it moves depending on which Adyen integration you ship.

"We use Adyen" tells your QSA where card data is processed. It does not tell them what your tag manager, analytics, consent tool, and SDK loader are doing in the browser while a shopper types a card. This post maps that boundary to each Adyen integration type so you know precisely which scripts Adyen takes off your plate and which ones you have to inventory, authorize, and monitor yourself.

The boundary by Adyen integration type

Adyen ships several front-end integrations, and each one draws the iframe boundary in a different place. The further the card fields sit inside an Adyen-served frame, the less of the payment-data path is yours, but the surrounding page scripts are yours in every case.

The pattern is consistent. Adyen's responsibility ends at the iframe border. The loader that fetches and mounts the Adyen SDK is your script, served from your origin, and it is in scope. So is everything around it.

Hosted Payment Pages: lightest, but not zero

A full redirect to an Adyen-hosted payment page is the cleanest case for card data. The PAN is entered on Adyen's domain, so it never touches your DOM. This is the classic SAQ A scenario.

The trap is assuming "redirect" means "no client-side scope." The page you redirect from, your cart or checkout-start page, still runs your scripts and is still part of the customer's payment journey. A tampered script there can overlay a fake card form before the redirect, or rewrite the redirect target to a spoofed processor. Since the January 2025 SAQ A change, eligibility itself depends on confirming your payment page is not susceptible to script-based attacks, so the pages you control still need a defensible script story.

Drop-in and Components: the most common gap

Drop-in and Components are where most teams land, and where the boundary is most misread. Adyen serves the actual card inputs inside an iframe, which keeps the PAN out of your DOM and supports SAQ A. Good. But to render that frame, your page loads the Adyen Web SDK and runs a loader script that you wrote and host. That loader is a payment-page script under 6.4.3, full stop.

Around it sits the rest of your checkout: Google Tag Manager, analytics, session replay, chat, consent management, fraud SDKs, and whatever marketing shipped last sprint. None of those are Adyen's. All of them execute in the same browser context as the Adyen frame, on your origin, and any one of them can be compromised through a third-party script supply-chain attack.

The 2024 Polyfill[.]io incident is the concrete version of this risk: a single trusted third-party script embedded on more than 490,000 sites was turned malicious overnight and served redirect and skimming code to checkout pages (Sansec, 2024). A merchant on Adyen Drop-in with perfectly isolated card fields was still exposed, because the malicious code rode in on the merchant's own page, not Adyen's iframe.

API-only: the boundary disappears

An API-only, server-to-server integration removes the Adyen iframe entirely. You collect the card data in your own form, in your own DOM, and send it to Adyen from your server. There is no client-side isolation, which is why this path typically lands you in SAQ D with the heaviest control set.

For 6.4.3 and 11.6.1 this is the worst case. Every script on the page now sits in the direct path of raw card data as it is typed. The inventory, written justification, integrity verification, and tamper detection you owe now have to cover the card field itself, because there is no safe iframe left around it. A single injected or modified script can read the PAN from the input on keypress and exfiltrate it. Most teams choosing API-only do so for checkout control, and they inherit the full browser-side monitoring burden as the price.

What 6.4.3 and 11.6.1 require, regardless of integration

The integration type moves the boundary, but the two controls never leave you. They became mandatory on 31 March 2025 (PCI Security Standards Council, PCI DSS v4.0.1).

1. Inventory every payment-page script (6.4.3). List each script that loads in the browser on your payment flow, including the Adyen SDK loader and every third-party tag, with a written reason it is there.
2. Authorize before it ships (6.4.3). Approve each script and each change. An unreviewed tag fired by a marketing tool fails this on its own.
3. Confirm integrity (6.4.3). Verify each authorized script has not been altered without approval.
4. Detect tampering and alert (11.6.1). Run a change-detection mechanism that alerts on unauthorized modification of payment-page scripts and security-impacting HTTP headers, evaluated as received by the consumer browser at least every seven days or per your targeted risk analysis.
5. Keep evidence that survives an audit (6.4.3 / 11.6.1). Retain script versions, approvals, and change history so a QSA sees records, not assertions.

None of these is satisfied by Adyen, because none of them is about where the card data is processed. They are about what runs in the browser, and the browser is the half Adyen hands back to you.

How cside covers the half Adyen leaves you

The manual version, a spreadsheet of scripts plus a weekly screenshot diff, breaks the moment a tag manager injects scripts dynamically, which is the norm on a real Adyen checkout. It also produces the kind of evidence auditors distrust.

cside PCI Shield is built for the exact slice Adyen does not cover:

• Automated inventory and justification (6.4.3). cside discovers every script on the payment page, including the Adyen SDK loader and all third-party tags, builds the inventory, and records authorization and justification in one place.
• Real-time integrity and tamper detection (11.6.1). cside monitors scripts and security-impacting HTTP headers continuously and alerts on unauthorized change, instead of sampling on a weekly cron and hoping nothing slipped through.
• Audit-ready evidence. cside archives every script version with full history, so you hand a QSA forensic records that map cleanly to the merchant side of the responsibility split.

cside does not replace Adyen. Adyen takes card data out of scope inside its iframe; cside covers the parent-page scripts that 6.4.3 and 11.6.1 leave with you, whichever integration you run.

Further reading on cside

• Can you use Adyen for PCI DSS?
• Does Stripe make you PCI compliant? What 6.4.3 and 11.6.1 still require
• PCI DSS 4.0.1 client-side compliance guide
• cside PCI Shield

As of 2026-06-18, treat this as operational guidance, not legal advice. Confirm the exact control language and your SAQ eligibility with your QSA, counsel, or risk owner.