Bij het openen van een creditcardbetaalmethode, of bij een vraag van uw bank, komt de term voorbij: PCI DSS. Een vragenlijst van tientallen pagina’s, Engelse termen, en het gevoel dat u als eigenaar van een webshop met vijftig bestellingen per week ineens een IT-afdeling moet optuigen.
Dat gevoel is grotendeels onterecht. PCI DSS voor een webshop is een reële norm, maar de manier waarop de meeste Nederlandse webshops betalingen afhandelen, zorgt ervoor dat het zwaarste deel bij uw betaalprovider ligt en niet bij u. In dit artikel leg ik uit wat de norm is, in welke categorie een gewone WooCommerce-shop valt, wat u dan wél moet regelen en waar het misgaat als u zonder na te denken een betaalplugin installeert.
Wat PCI DSS is
PCI DSS staat voor Payment Card Industry Data Security Standard. Het is geen wet, maar een norm van de creditcardmaatschappijen (Visa, Mastercard en anderen) die via de banken en betaalproviders wordt opgelegd aan iedereen die kaartbetalingen accepteert. De kern: wie kaartgegevens verwerkt, opslaat of doorstuurt, moet dat volgens vaste regels beveiligen. De norm beschrijft twaalf hoofdeisen, van firewalls en versleuteling tot toegangsbeheer en logging.
De zwaarte van wat u moet aantonen, hangt af van hoeveel kaartgegevens u zelf aanraakt. En daar zit het goede nieuws voor de meeste webshops.
Waarom uw betaalprovider het zware werk doet
In Nederland betaalt het overgrote deel van de klanten met iDEAL. Daar komen geen kaartgegevens aan te pas. En wie wel met creditcard betaalt, doet dat vrijwel altijd via een betaalprovider als Mollie, Pay.nl, Adyen of Buckaroo. Die providers werken op één van twee manieren:
- Omleiding. De klant wordt na “bestelling plaatsen” doorgestuurd naar een betaalpagina van de provider, vult daar zijn gegevens in en komt terug bij uw shop. Uw server ziet nooit een kaartnummer.
- Ingesloten velden (iframe of hosted fields). De kaartvelden staan visueel op uw afrekenpagina, maar zijn technisch een venster van de provider. De gegevens gaan rechtstreeks naar hen, niet via uw server.
In beide gevallen is uw webshop wat de norm noemt een handelaar die de kaartverwerking volledig heeft uitbesteed. U valt dan in de lichtste categorie, met de kortste zelfbeoordelingsvragenlijst (SAQ A). Die vragenlijst gaat niet over versleutelde databases of netwerksegmentatie, maar over vragen als: heeft u de verwerking inderdaad uitbesteed, is uw provider zelf gecertificeerd, en zorgt u dat uw website niet zo gemanipuleerd kan worden dat de betaalpagina wordt omgeleid?
Wat er dan wél van u wordt verwacht
Lichtste categorie betekent niet: niets. Het betekent dat uw verantwoordelijkheid verschuift van “kaartgegevens beveiligen” naar “zorgen dat de weg naar de betaalpagina betrouwbaar blijft”. Concreet:
- Gebruik alleen gecertificeerde betaalproviders. Alle grote Nederlandse providers zijn dat. Controleer het toch als u een onbekende plugin overweegt.
- Sla nooit kaartgegevens op. Ook niet “even” in een notitieveld, een mail of een spreadsheet, als een klant ze telefonisch doorgeeft. Dat is de snelste manier om alsnog in een zware categorie te belanden.
- Houd de shop up-to-date en beveiligd. Een gehackte webshop kan een nepbetaalpagina tonen of een script inladen dat kaartgegevens onderschept (zogeheten skimming). Dan is niet uw database het probleem, maar uw afrekenpagina. Updates, een firewall en malwarescans zijn daarmee onderdeel van uw PCI-verplichting.
- Beperk wie er bij de shop kan. Beheerdersrechten, tweestapsverificatie, geen gedeelde accounts. De bredere checklist daarvoor staat in het artikel over klantgegevens beschermen in WooCommerce.
- Gebruik https op de hele shop. Vanzelfsprekend, maar het staat expliciet in de vragenlijst.
- Vul de vragenlijst in als uw provider erom vraagt. Veel providers vragen bij kleine handelaren niets of alleen een jaarlijkse bevestiging. Als ze wél om een SAQ vragen, is het bij uitbestede verwerking een kwestie van een uur.
Waar het misgaat: de verkeerde betaalplugin
Het risico zit niet bij iDEAL en niet bij Mollie. Het zit bij plugins die kaartgegevens op uw eigen afrekenpagina laten invoeren en vervolgens via uw server doorsturen. Dat komt voor bij sommige goedkope of verouderde creditcardplugins, en bij maatwerkkoppelingen van jaren geleden. Op het oog werkt het prima, maar uw server “ziet” het kaartnummer, en daarmee valt u in een categorie waarin u wél zelf moet aantonen dat uw hele omgeving aan de norm voldoet. Dat is voor een kleine webshop praktisch niet te doen.
Zo controleert u het: open uw afrekenpagina, kies creditcard en kijk waar het kaartveld vandaan komt. Wordt u doorgestuurd naar een pagina van de provider, of staat het veld in een ingesloten venster (in de ontwikkelaarsconsole zichtbaar als een iframe van het domein van de provider)? Dan zit u goed. Is het een gewoon invoerveld van uw eigen thema, vraag dan uw provider of onderhoudspartij om uitsluitsel.
Wat dit te maken heeft met de AVG
PCI DSS en de AVG overlappen, maar zijn niet hetzelfde. PCI DSS gaat over kaartgegevens; de AVG over alle persoonsgegevens. Een shop kan volledig aan PCI DSS voldoen (omdat kaartgegevens nooit bij u komen) en toch AVG-problemen hebben met onversleutelde back-ups vol klantadressen. Zie PCI DSS als een deelgebied: belangrijk, maar smal. Wie de bredere beveiliging op orde heeft, voldoet aan het PCI-deel bijna vanzelf.
Praktijk en volgende stap
Een cadeauwinkel uit Maastricht kreeg van hun bank een PCI-vragenlijst en dacht een consultant te moeten inhuren. Bij nader inzien: iDEAL, creditcard via Mollie met omleiding, geen opgeslagen kaartgegevens. Het invullen kostte een uur, en de enige actie die eruit kwam, was tweestapsverificatie voor de twee beheerders. Het onderhoud dat de shop up-to-date en gescand houdt, en daarmee de afrekenpagina betrouwbaar, liep al via het WooCommerce-onderhoud; dat bleek het grootste deel van de vragenlijst af te dekken.
Volgende stap: controleer vandaag waar het creditcardveld op uw afrekenpagina vandaan komt. Dat ene antwoord bepaalt of PCI DSS voor u een uur werk is of een project.
