Wat Adyen dekt versus wat jij nog steeds bezit
Adyen attesteert, net als elke PCI DSS Level 1 processor, de code die binnen zijn eigen iframe draait. Het attesteert niet de pagina die het inkadert. PCI DSS 4.0.1 vereisten 6.4.3 en 11.6.1 gaan over de scripts op je betaalpagina in de browser van de consument, en de meeste van die scripts zijn van jou. De scripteigendomsgrens is de rand van Adyens frame, en die verschuift afhankelijk van welke Adyen-integratie je uitlevert.
"Wij gebruiken Adyen" vertelt je QSA waar kaartgegevens worden verwerkt. Het vertelt ze niet wat je tag manager, analytics, consent-tool en SDK-loader in de browser uitvoeren terwijl een shopper een kaart intypt. Deze post koppelt die grens aan elk Adyen-integratietype, zodat je precies weet welke scripts Adyen van je bordje neemt en welke je zelf moet inventariseren, autoriseren en monitoren.
De grens per Adyen-integratietype
Adyen levert verschillende front-end-integraties uit, en elke trekt de iframe-grens op een andere plek. Hoe dieper de kaartvelden in een door Adyen geserveerd frame zitten, hoe minder van het betaalgegevenspad van jou is, maar de omringende paginascripts zijn in elk geval van jou.
| Adyen-integratie | Waar kaartvelden renderen | Typische SAQ | Adyen bezit (zijn iframe) | Jij bezit onder 6.4.3 / 11.6.1 |
|---|---|---|---|---|
| Hosted Payment Pages (redirect) | Adyens domein, volledige redirect | SAQ A | Kaartinvoer en de hosted pagina | Scripts op de pagina waar je vandaan redirect |
| Drop-in | Adyen iframe, gemount door Adyen SDK | SAQ A | Kaartinvoer binnen het Drop-in frame | SDK-loader + elk ander script op de bovenliggende pagina |
| Components (Custom Card) | Adyen iframes per veld | SAQ A | Elk hosted invoerveld-frame | SDK-loader, layout-JS, alle omringende scripts |
| API-only (server-to-server) | Je eigen DOM, geen Adyen iframe | SAQ D | Niets client-side | Het hele formulier en elk script dat het kan lezen |
Het patroon is consistent. Adyens verantwoordelijkheid eindigt bij de iframe-rand. De loader die de Adyen SDK ophaalt en mount is jouw script, geserveerd vanaf jouw origin, en valt binnen scope. Net als alles eromheen.
Hosted Payment Pages: lichtst, maar niet nul
Een volledige redirect naar een door Adyen gehoste betaalpagina is het schoonste geval voor kaartgegevens. De PAN wordt ingevoerd op Adyens domein, dus die raakt je DOM nooit. Dit is het klassieke SAQ A-scenario.
De valkuil is aannemen dat "redirect" betekent "geen client-side scope". De pagina waar je vandaan redirect, je winkelwagen of checkout-startpagina, draait nog steeds jouw scripts en is nog steeds onderdeel van de betaalreis van de klant. Een gemanipuleerd script daar kan een nepkaartformulier overlayen vóór de redirect, of het redirectdoel herschrijven naar een vervalste processor. Sinds de SAQ A-wijziging van januari 2025 hangt de eligibility zelf af van het bevestigen dat je betaalpagina niet vatbaar is voor scriptgebaseerde aanvallen, dus de pagina's die jij beheert hebben nog steeds een verdedigbaar scriptverhaal nodig.
Drop-in en Components: het meest voorkomende gat
Drop-in en Components zijn waar de meeste teams belanden, en waar de grens het vaakst verkeerd wordt gelezen. Adyen serveert de daadwerkelijke kaartinvoer binnen een iframe, wat de PAN buiten je DOM houdt en SAQ A ondersteunt. Goed. Maar om dat frame te renderen, laadt je pagina de Adyen Web SDK en draait een loaderscript dat jij hebt geschreven en host. Die loader is een betaalpaginascript onder 6.4.3, punt uit.
Eromheen zit de rest van je checkout: Google Tag Manager, analytics, session replay, chat, consentbeheer, fraude-SDK's, en wat marketing afgelopen sprint heeft uitgeleverd. Geen daarvan is van Adyen. Ze draaien allemaal in dezelfde browsercontext als het Adyen-frame, op jouw origin, en elk daarvan kan worden gecompromitteerd via een supply-chainaanval op een third-party script.
Het Polyfill[.]io-incident van 2024 is de concrete versie van dit risico: één vertrouwd third-party script dat op meer dan 490.000 sites was ingebed, werd van de ene op de andere dag kwaadaardig gemaakt en serveerde redirect- en skimmingcode naar checkout-pagina's (Sansec, 2024). Een merchant op Adyen Drop-in met perfect geïsoleerde kaartvelden was alsnog blootgesteld, omdat de kwaadaardige code meeliftte op de eigen pagina van de merchant, niet op Adyens iframe.
API-only: de grens verdwijnt
Een API-only, server-to-server-integratie verwijdert het Adyen iframe volledig. Je verzamelt de kaartgegevens in je eigen formulier, in je eigen DOM, en stuurt ze vanaf je server naar Adyen. Er is geen client-side isolatie, en daarom belandt dit pad je doorgaans in SAQ D met de zwaarste controleset.
Voor 6.4.3 en 11.6.1 is dit het ergste geval. Elk script op de pagina zit nu op het directe pad van ruwe kaartgegevens terwijl ze worden ingetypt. De inventaris, schriftelijke rechtvaardiging, integriteitsverificatie en tamperdetectie die je verschuldigd bent, beschermen niet langer de pagina rond een veilig iframe; ze beschermen het kaartveld zelf. Eén geïnjecteerd of gewijzigd script kan de PAN bij elke toetsaanslag uit het invoerveld lezen en exfiltreren. De meeste teams die voor API-only kiezen, doen dat voor controle over de checkout, en ze erven de volledige monitoringlast aan de browserkant als de prijs daarvoor.
Wat 6.4.3 en 11.6.1 vereisen, ongeacht de integratie
Het integratietype verschuift de grens, maar de twee controles verlaten jou nooit. Ze werden verplicht op 31 maart 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
- Inventariseer elk betaalpaginascript (6.4.3). Maak een lijst van elk script dat in de browser laadt op je betaalflow, inclusief de Adyen SDK-loader en elke third-party tag, met een schriftelijke reden waarom het er is.
- Autoriseer voordat het wordt uitgeleverd (6.4.3). Keur elk script en elke wijziging goed. Een niet-beoordeelde tag die door een marketingtool wordt afgevuurd faalt hier op zichzelf al op.
- Bevestig integriteit (6.4.3). Verifieer dat elk geautoriseerd script niet zonder goedkeuring is gewijzigd.
- Detecteer manipulatie en alarmeer (11.6.1). Draai een wijzigingsdetectiemechanisme dat alarmeert bij ongeautoriseerde wijziging van betaalpaginascripts en beveiligingsrelevante HTTP-headers, geëvalueerd zoals ontvangen door de browser van de consument, minstens elke zeven dagen of volgens je gerichte risicoanalyse.
- Bewaar bewijs dat een audit overleeft (6.4.3 / 11.6.1). Behoud scriptversies, goedkeuringen en wijzigingsgeschiedenis zodat een QSA registraties ziet, geen beweringen.
Geen van deze wordt door Adyen ingevuld, omdat geen van deze gaat over waar de kaartgegevens worden verwerkt. Ze gaan over wat er in de browser draait, en de browser is de helft die Adyen aan jou teruggeeft.
Hoe cside de helft dekt die Adyen aan jou overlaat
De handmatige versie, een spreadsheet met scripts plus een wekelijkse screenshot-diff, breekt op het moment dat een tag manager dynamisch scripts injecteert, wat de norm is op een echte Adyen-checkout. Het produceert ook precies het soort bewijs dat auditors wantrouwen.
cside PCI Shield is gebouwd voor precies het stuk dat Adyen niet dekt:
- Geautomatiseerde inventaris en rechtvaardiging (6.4.3). cside ontdekt elk script op de betaalpagina, inclusief de Adyen SDK-loader en alle third-party tags, bouwt de inventaris en registreert autorisatie en rechtvaardiging op één plek.
- Realtime integriteits- en tamperdetectie (11.6.1). cside monitort scripts en beveiligingsrelevante HTTP-headers continu en alarmeert bij ongeautoriseerde wijziging, in plaats van te samplen op een wekelijkse cron en te hopen dat er niets doorheen glipte.
- Auditklaar bewijs. cside archiveert elke scriptversie met volledige geschiedenis, zodat je een QSA forensische registraties overhandigt die netjes aansluiten op de merchantkant van de verantwoordelijkheidsverdeling.
cside vervangt Adyen niet. Adyen haalt kaartgegevens binnen zijn iframe uit scope; cside dekt de scripts op de bovenliggende pagina die 6.4.3 en 11.6.1 bij jou laten, welke integratie je ook draait.
Verder lezen over cside
- Kun je Adyen gebruiken voor PCI DSS?
- Maakt Stripe je PCI-compliant? Wat 6.4.3 en 11.6.1 nog steeds vereisen
- PCI DSS 4.0.1 client-side compliancegids
- cside PCI Shield
Per 2026-06-18, behandel dit als operationele richtlijn, niet als juridisch advies. Bevestig de exacte controletaal en je SAQ-eligibility met je QSA, juridisch adviseur of risk owner.
