Kort samengevat: PCI DSS-compliance met Stripe
- Stripe regelt PCI DSS Level 1-compliance voor de kaartverwerking zelf, daarom zeggen merchants vaak dat ze 'PCI-compliant zijn met Stripe'. Dat klopt half.
- Merchants blijven zelf verantwoordelijk voor PCI DSS 4.0.1-eisen 6.4.3 en 11.6.1 op hun eigen site ook al verwerkt Stripe de kaart. Deze dekken script-inventaris en tamperdetectie voor betaalpagina's op je domein.
- Stripe Elements minimaliseert maar elimineert niet de scope van de merchant. SAQ-A-merchants die Stripe Elements gebruiken moeten nog altijd voldoen aan 6.4.3 en 11.6.1, en het gratis niveau van cside dekt beide.
Weinig tijd? Bekijk cside PCI Shield. Dit dekt alles hieronder in één deployment.
Ja, Stripe heeft PCI DSS Niveau 1-certificering, het hoogste beschikbare niveau. Die certificering dekt de infrastructuur van Stripe. Jouw website valt daar niet onder. Als jouw betaalpagina een script laadt dat jij beheert, analytics, live chat, toestemmingsbeheer, A/B-tests, blijven twee vereisten van PCI DSS 4.0.1 jouw verantwoordelijkheid die Stripe niet namens jou kan invullen: §6.4.3 en §11.6.1.
Wie is waarvoor verantwoordelijk met Stripe en PCI DSS 4.0.1?
De status van Niveau 1 serviceprovider van Stripe wordt jaarlijks geverifieerd door een Qualified Security Assessor (QSA) en staat vermeld in het Visa Global Registry of Service Providers. De certificering bevestigt dat de datacenters, kaartverwerkingssystemen en interne infrastructuur van Stripe voldoen aan de PCI DSS-normen. Waar de grens tussen Stripe en jou ligt, hangt af van de integratie die je gebruikt:
| Jouw Stripe-integratie | Wat de certificering van Stripe dekt | Wat van jou blijft onder 4.0.1 |
|---|---|---|
| Stripe Checkout, gehoste betaalpagina (SAQ A) | De kaartvelden, de gehoste pagina zelf en de kaartgegevens van begin tot eind, geleverd vanuit het gecertificeerde domein van Stripe | Elk script en elke beveiligingsheader op de pagina die de klant naar Checkout stuurt, onder §6.4.3 en §11.6.1 |
| Stripe Elements, ingesloten gehoste velden (SAQ A) | Het iframe dat de kaart opneemt, plus de verzending en opslag van die kaartgegevens | De pagina rond het iframe: analytics, chat, toestemming, tagmanagers, plus wijzigingsdetectie op headers en cookie-attributen |
| Stripe.js met je eigen betaal-UI (SAQ A-EP) | De tokenisatie en de kaartgegevens zodra Stripe.js ze overneemt | Je hele checkout-DOM, de integriteit van elk script dat daarbij kan, en je headers |
| Mobiele SDK's en Terminal SDK's (SAQ A) | Het opnemen en verzenden van de kaart binnen de SDK van Stripe zelf | Elke webcheckout die je naast de app draait, op dezelfde voorwaarden als de rijen hierboven |
| Directe API, kaartgegevens op jouw server (SAQ D) | De kaartgegevens pas zodra ze bij Stripe aankomen, nooit zolang ze op jouw systemen staan | De volledige PCI DSS-scope: kaartgegevens opslaan en verzenden, plus §6.4.3 en §11.6.1 |
De grens ligt bij de servers van Stripe. Jouw betaalpagina, de pagina die kaartgegevens verzamelt of doorverwijst, wordt uitgevoerd in de browsers van jouw klanten, en dat oppervlak is van jou, in welke rij je ook zit.
Hoe compliant te zijn met Stripe
De producten van Stripe zijn ontworpen om gevoelige kaartgegevens veilig te verwerken, waardoor de reikwijdte van jouw PCI DSS-verantwoordelijkheden wordt verminderd:
- Stripe Checkout en Elements: Deze tools gebruiken gehoste betalingsvelden, waardoor gevoelige betalingsinformatie rechtstreeks naar de PCI DSS-gevalideerde servers van Stripe wordt verzonden zonder jouw servers te raken.
- Mobiele en Terminal SDK's: De SDK's van Stripe voor mobiele en persoonlijke betalingen sturen ook gevoelige informatie rechtstreeks naar Stripe, waardoor jouw PCI-reikwijdte wordt geminimaliseerd.
| Stripe-integratie | Vereiste SAQ | Reden |
|---|---|---|
| Stripe Checkout (gehoste betalingspagina) | SAQ A | Geen kaarthoudergegevens raken jouw server |
| Stripe Elements (ingesloten velden)* | SAQ A* | Elements verzendt gegevens veilig naar Stripe* |
| Stripe.js v2 met aangepaste UI | SAQ A-EP* | Jouw frontend beïnvloedt transactiebeveiliging |
| Directe API (kaartgegevens op jouw server) | SAQ D | Je slaat kaartgegevens op, verwerkt en/of verzendt deze |
*Je moet nu dependencies op betaalpagina's monitoren, meer hieronder.
- Als je Stripe Checkout (gehoste betalingspagina) gebruikt, kom je in aanmerking voor SAQ A.
- Als je Stripe Elements (ingesloten velden die gegevens rechtstreeks naar Stripe sturen) gebruikt, kom je in aanmerking voor SAQ A.
- Als je de mobiele of Terminal SDK's van Stripe gebruikt, worden betalingsgegevens veilig verwerkt door Stripe, waardoor je in SAQ A blijft.
- Als je kaarthoudergegevens verzamelt en opslaat of een directe API-integratie gebruikt, moet je SAQ D invullen en volledige PCI-controles implementeren.
Als je in aanmerking komt voor SAQ A, zijn jouw PCI DSS-verantwoordelijkheden minimaal omdat Stripe de gevoelige kaartgegevens verwerkt.
Als je SAQ A-EP of SAQ D nodig hebt, neem je meer verantwoordelijkheid voor het beveiligen van transacties.
Welke PCI DSS-vereisten Stripe niet dekt
PCI DSS 4.0.1 introduceerde twee vereisten gericht op de browserlaag, beide verplicht sinds 31 maart 2025:
Vereiste 6.4.3, Scriptautorisatie op betaalpagina's
Je moet een gedocumenteerde inventaris bijhouden van elk script dat gemachtigd is te draaien op jouw betaalpagina's. Voor elk script heb je een methode nodig om de integriteit te bevestigen, dat de code niet is gewijzigd sinds jouw laatste controle. Dit geldt zowel voor eigen scripts als voor third-party scripts (analytics, supportchat, A/B-testing tools).
Vereiste 11.6.1, Detectie van wijzigingen in HTTP-headers
Je moet een mechanisme inzetten dat ongeautoriseerde wijzigingen in HTTP-beveiligingsheaders en cookie-attributen op jouw betaalpagina's detecteert en meldingen genereert.
Stripe heeft geen zicht op deze scripts of headers. Beide vereisten betreffen wat er in de browsers van jouw klanten op jouw webpagina gebeurt, een oppervlak dat volledig buiten de omgeving van Stripe valt.
De update van januari 2025 van de PCI Security Standards Council op het SAQ A bevestigde dit: zelfs merchants die volledig gehoste Stripe Checkout gebruiken, moeten §6.4.3 en §11.6.1 naleven als hun betaalstroom via een pagina loopt die externe scripts laadt. Zie onze analyse van de SAQ A-update van januari 2025 voor meer details.
Voor een volledige technische uitsplitsing van wat Stripe wel en niet dekt voor §6.4.3 en §11.6.1, zie onze post: Maakt Stripe je PCI-compliant voor vereisten 6.4.3 en 11.6.1?
Scriptmonitoring voor SAQ A-naleving
Volgens de update van januari 2025 benadrukte de PCI Security Standards Council het belang van het monitoren van dependencies. Dit omvat zowel first-party als third-party scripts op websites.
Een client-side monitor voldoet aan §6.4.3 en §11.6.1 door te draaien in de browsers van jouw klanten, elk script op elke bezoek aan de betaalpagina te inventariseren en te waarschuwen wanneer een script wijzigt of een nieuw script verschijnt. cside monitort scripts en HTTP-headers in de browsers van echte bezoekers, inclusief conditionele payloads die schoon lijken voor scanners maar activeren in productieverkeer.
De documentatie van Stripe over PCI DSS vind je hier.
Verwante lectuur: onze gids voor PCI DSS 6.4.3- en 11.6.1-compliance · de gedeelde PCI DSS-verantwoordelijkheden van Adyen
Bepaal jouw PCI-nalevingsniveau
| Niveau | Criteria | Validatievereiste |
|---|---|---|
| Level 1 | Meer dan 6 miljoen transacties per jaar | Volledige onsite audit door een QSA + SAQ D |
| Level 2 | 1 tot 6 miljoen transacties per jaar | SAQ A, SAQ A-EP, of SAQ D + Attestation of Compliance (AOC) |
| Level 3 | 20.000 tot 1 miljoen online transacties per jaar | SAQ A, SAQ A-EP, of SAQ D + Attestation of Compliance (AOC) |
| Level 4 | Minder dan 20.000 online transacties OF tot 1 miljoen totale transacties | SAQ A, SAQ A-EP, of SAQ D + Attestation of Compliance (AOC) |
- Level 1 = Moet een ROC uitvoeren (Volledige PCI DSS-beoordeling met Report on Compliance door QSA)
- Level 2 = Moet minimaal een SAQ uitvoeren met third-party QSA of ISA attestation
- Level 3 = Moet een SAQ uitvoeren
- Level 4 = Optioneel
De PCI DSS Attestation of Compliance voor Stripe-merchants
De PCI DSS Attestation of Compliance (AoC) voor een Stripe-merchant is een document dat een QSA (of een geautoriseerde interne ondertekenaar onder SAQ) produceert aan het einde van een beoordelingscyclus, waarin staat welk SAQ-niveau de merchant kwalificeert en dat alle toepasselijke controls op hun plek zijn. Voor de meeste e-commerce Stripe-merchants betekent dat een SAQ A (volledig ge-outsourcede betaalpagina) of SAQ A-EP (checkout gehost op de site van de merchant) attestation.
Het belangrijke operationele punt is dat Stripes AoC Stripe dekt. Die dekt de merchant niet. Zelfs bij gebruik van Stripe Elements of Checkout houdt de merchant een AoC-verplichting omdat de betaalpagina op het domein van de merchant draait en de merchant verantwoordelijk is voor de scripts die op die pagina laden onder 6.4.3 en 11.6.1. Enterprise-inkoopteams vragen tijdens leveranciers-onboarding vaak om beide AoCs.
cside levert het bewijsspoor dat de eigen SAQ A of SAQ A-EP AoC van de merchant onderbouwt: continue script-inventaris, integriteitsmonitoring en audit-klaar 6.4.3 / 11.6.1-bewijs dat een QSA zonder haast kan opvragen.
Identificeer jouw integratietype en vereiste documentatie
Vul de juiste SAQ in Zodra je de juiste SAQ hebt geïdentificeerd op basis van jouw integratiemethode, vul deze grondig in. Stripe biedt een PCI-wizard in jouw Dashboard om je door dit proces te begeleiden.
Dien jouw documentatie in Nadat je de SAQ hebt ingevuld, dien je deze samen met eventuele vereiste Attestation of Compliance (AOC) of Report on Compliance (ROC) in bij Stripe voor beoordeling. Het Dashboard van Stripe stelt je in staat deze documenten rechtstreeks te uploaden.
Handhaaf voortdurende naleving PCI-naleving vereist continue monitoring. Controleer regelmatig jouw scriptinventaris, houd jouw SAQ actueel en monitor betaalpagina-headers op ongeautoriseerde wijzigingen.
Hetzelfde verschil tussen processorcertificering en verplichting van de merchant geldt ook bij gebruik van Adyen of PayPal en Braintree als betalingsverwerker.
