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.
| Adyen integration | Where card fields render | Typical SAQ | Adyen owns (its iframe) | You own under 6.4.3 / 11.6.1 |
|---|---|---|---|---|
| Hosted Payment Pages (redirect) | Adyen's domain, full redirect | SAQ A | Card entry and the hosted page | Scripts on the page you redirect from |
| Drop-in | Adyen iframe, mounted by Adyen SDK | SAQ A | Card entry inside the Drop-in frame | SDK loader + every other parent-page script |
| Components (Custom Card) | Per-field Adyen iframes | SAQ A | Each hosted input field frame | SDK loader, layout JS, all surrounding scripts |
| API-only (server-to-server) | Your own DOM, no Adyen iframe | SAQ D | Nothing client-side | The whole form and every script that can read it |
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 are no longer protecting the page around a safe iframe; they are protecting the card field itself. 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).
- 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.
- 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.
- Confirm integrity (6.4.3). Verify each authorized script has not been altered without approval.
- 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.
- 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.
