PCI DSS-naleving voor e-commerceis een van de gebieden waarop handelaren de meeste beoordelingsfouten maken. Velen geloven dat het gebruik van Stripe, PayPal of een bekende betaalgateway hen automatisch vrijstelt van alle PCI DSS-verplichtingen. De werkelijkheid is genuanceerder: de gekozen integratiemethode bepaalt welkeSAQvan toepassing is en hoeveel controles bij de handelaar blijven. Inzicht in dit onderscheid maakt het mogelijk de nalevingsperimeter via de keuze van de juiste architectuur vanaf het begin te minimaliseren.
E-commerce-checkout en PCI DSS: wat kaartacceptatie in gang zet
Elke webshop die kaartbetalingen accepteert, brengt PCI DSS-verplichtingen voor de handelaar met zich mee. De vraag is niet of de verplichtingen gelden, maar welke en in welk bereik. Alles hangt af van hoe kaartgegevens tijdens de checkout stromen. Wanneer de browser van de klant kaartgegevens rechtstreeks naar de server van de handelaar stuurt (al is het maar even), valt de handelaar onder de meest uitgebreide verplichtingen vanSAQ Dmet meer dan200 te vervullen controles. Wanneer kaartgegevens echter nooit de server van de handelaar raken, omdat het betaalformulier door de aanbieder wordt gehost, kan de handelaar in aanmerking komen voor het veel eenvoudigereSAQ A.
Er is ook een tussenweg, vertegenwoordigd door deSAQ A-EP-aanpak: de handelaar gebruikt het JavaScript van de aanbieder om kaartgegevens rechtstreeks in de browser van de klant te verzamelen, zonder dat de gegevens de server van de handelaar passeren. Dit verkleint het bereik ten opzichte van SAQ D, maar vereist nog steeds meer controles dan SAQ A, waaronder het beheer van de webserverbeveiliging en van de JavaScript-code op uitcheckpagina's. MetPCI DSS v4heeft de vereiste voor betalingspaginascripts de positie van SAQ A-EP-handelaren verder gecompliceerd.
Integratieopties en hun invloed op het SAQ
De belangrijkste integratieopties voor e-commerce zijn er drie, geordend van de meest naar de minst belastende in PCI DSS-termen. De eerste is de native checkout: de handelaar ontwikkelt en beheert het kaartinvoerformulier intern. Dit vereistSAQ Dmet de breedste nalevingsperimeter. De tweede optie zijnhosted fieldsof JavaScript-injectie: de aanbieder voegt invoervelden in op de pagina van de handelaar die kaartgegevens rechtstreeks in de browser verzamelen en naar de aanbieder sturen. Dit leidt tot SAQ A-EP met een gemiddeld bereik. De derde en minst belastende optie is de doorverwijzing naar eengehoste betaalpagina: de gebruiker verlaat de website van de handelaar om de betaling af te ronden op een door de aanbieder gehoste pagina en keert daarna terug. Deze architectuur maaktSAQ Amogelijk.
Tokenisatie voegt in elk scenario een extra beschermingslaag toe. Wanneer een gecertificeerde tokenisatieaanbieder hetPANonderschept voordat het de systemen van de handelaar bereikt, en een onomkeerbaartokenteruggeeft, heeft de handelaar nooit gevoelige kaartgegevens in handen. Het token kan vrij worden opgeslagen voor toekomstig gebruik (abonnementsverlengingen, terugkerende bestellingen), zonder dat dit extra betalingsgegevens-beveiligingsverplichtingen met zich meebrengt, omdat het token buiten de systemen van de aanbieder geen waarde heeft.
Hoe PCI Proxy EU het PCI-bereik uit uw e-commerce elimineert
MetPCI Proxy EUziet de checkout van de handelaar nooit kaartgegevens. Het betaalformulier wordt beheerd door de gecertificeerdePCI DSS Level 1-infrastructuur van PCI Proxy EU, die hetPANonderschept en de handelaar een token teruggeeft voordat gevoelige gegevens de server van de webshop bereiken. Dit brengt de handelaar rechtstreeks naarSAQ Aen elimineert de noodzaak voor driemaandelijkse kwetsbaarheidscans van de server, uitgebreide penetratietests, certificaatbeheer en CDE-specifiek toegangscontrolebeleid.
Het operationele voordeel is aanzienlijk, ook voor shops die terugkerende bestellingen of abonnementen beheren. Het token dat door de handelaar is opgeslagen, kan worden gebruikt om in de toekomst kaarten te belasten, zonder dat de handelaar ooit het oorspronkelijke PAN kent. Dit scenario, dat eerder complex te beheren was in de context van PCI DSS-naleving, wordt met een tokenisatieaanbieder eenvoudig: de handelaar vraagt de aanbieder een afschrijving te verwerken met behulp van het token, en de aanbieder gebruikt het PAN dat hij in zijn gecertificeerde vault houdt. De handelaar ziet nooit de gevoelige gegevens en behoudt de SAQ A-perimeter in alle fasen van de klantenlevenscyclus.
Veelgestelde vragen
Ben ik PCI DSS-conform wanneer ik Stripe of PayPal gebruik?
Dat hangt van de integratie af. Wanneer u de doorverwijzing naar de Stripe- of PayPal-uitcheckpagina gebruikt, is uw bereik teruggebracht tot SAQ A. Wanneer u hun API's of JavaScript-elementen gebruikt met formulieren die op uw eigen domein worden gehost, is uw bereik SAQ A-EP. Wanneer u de API's rechtstreeks hebt geïntegreerd en kaartgegevens via uw server leidt, bevindt u zich in SAQ D. Het gebruik van een bekende gateway betekent niet automatisch naleving: de integratiearchitectuur is beslissend.
Verkleint een gehoste betaal-iFrame mijn bereik?
Ja, wanneer de iFrame wordt geladen vanuit het domein van de aanbieder en kaartgegevens niet via de server van de handelaar passeren. In dat geval is de typische kwalificatie SAQ A. Let op: wanneer de handelaar aangepast JavaScript uitvoert op dezelfde pagina als de iFrame, dat theoretisch toegang zou kunnen krijgen tot de gegevens, kan de PCI Council vereisen dat de handelaar SAQ A-EP in plaats van SAQ A invult. Controleer altijd de juiste classificering met uw acquirer.
Ik heb een WooCommerce-shop: wat moet ik doen?
WooCommerce zelf bepaalt uw PCI-bereik niet: beslissend is welke betaalgateway u gebruikt en hoe u deze hebt geïntegreerd. Wanneer u de doorverwijzing naar de gehoste betaalpagina van uw aanbieder gebruikt, kunt u SAQ A invullen. Wanneer u plugins gebruikt die kaartgegevens rechtstreeks in het WooCommerce-uitcheckformulier verzamelen en via API verzenden, is uw bereik groter. Controleer de documentatie van uw betaalplugin en schakel indien nodig over naar een gehoste formulieroplossing.
Geen kaartgegevens in uw e-commerce betekent SAQ A, vereenvoudigde naleving en veiligere klanten.Ontdek PCI Proxy EU.
Hulp nodig bij PCI-naleving?
Ons team helpt u uw CDE in kaart te brengen, het juiste SAQ te kiezen en tokenisatie te implementeren met gegevensresidentie in de EU.
Neem contact op