Betaalveiligheid: PCI en fraude

Module 6: Beheer en veiligheid · Leestijd: 11 minuten

Leerdoel: Na deze les kun je uitleggen waarom een shop kaartgegevens nooit zelf verwerkt, wat PCI DSS en SAQ A voor een kleine shop betekenen, hoe je de afrekenpagina beschermt, en hoe je fraude en card testing herkent en beperkt.

Kernbegrippen: PCI DSS, kaartgegevens, betaalprovider, doorsturen naar de betaalpagina, ingebed betaalformulier (iframe), SAQ A, scripts op de afrekenpagina, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, terugboeking (chargeback), frauderisico

Kaartgegevens horen niet in je shop

Een creditcardnummer, de vervaldatum en de beveiligingscode zijn voor criminelen goud waard. Wie ze opslaat of doorgeeft, valt onder PCI DSS (Payment Card Industry Data Security Standard), de beveiligingsstandaard van de kaartmaatschappijen. De huidige versie is v4.0.1. Voor een bedrijf dat kaartgegevens zelf verwerkt, is dat een flink pakket eisen: netwerkscheiding, logboeken, scans, testen door een erkende partij.

Een kleine shop wil daar niet in zitten, en hoeft dat ook niet. De vaste regel: kaartgegevens komen nooit in je shop. De klant typt ze in bij je betaalprovider (Mollie, Stripe, PayPal, WooPayments of een andere, les 4.4). De shop krijgt daarna alleen te horen: betaald of niet, met een kenmerk. Geen kaartnummer, geen code. Dat betekent ook:

• nooit een eigen formulierveld voor kaartnummers maken, ook niet "even voor een telefonische bestelling";
• nooit kaartgegevens per mail, chat of telefoon aannemen en in een notitie bij de bestelling zetten;
• geen plugin gebruiken die kaartgegevens in je eigen database bewaart.

Doorsturen of ingebed: SAQ A

Kleine shops tonen met een SAQ (Self-Assessment Questionnaire, een vragenlijst) dat ze aan PCI DSS voldoen. Je betaalprovider vraagt daar soms om. De lichtste is SAQ A, voor shops die de betaling volledig uitbesteden. Er zijn twee manieren waarop dat in een shop werkt:

1. Doorsturen. Na "bestellen" gaat de klant naar de betaalpagina van de provider en daarna terug. De shop ziet de kaartgegevens nooit, ook de pagina niet waarop ze worden ingetypt.
2. Ingebed formulier. Het betaalveld staat in je afrekenpagina, maar is een iframe (een stukje pagina) van de provider. De kaartgegevens gaan van de browser rechtstreeks naar de provider.

Sinds 31 maart 2025 geldt een nieuwe versie van SAQ A. Daarin staat een voorwaarde die vooral de tweede manier raakt: wie een ingebed formulier gebruikt, moet bevestigen dat zijn site niet vatbaar is voor aanvallen met scripts die het betaalsysteem kunnen raken. De achtergrond is e-skimming: een kwaadaardig script op je afrekenpagina dat meeleest wat de klant intypt, of een nep-betaalveld over het echte heen legt. Wie doorstuurt naar de pagina van de provider, valt niet onder die voorwaarde. Stel je betaalprovider de vraag welke SAQ voor jouw koppeling geldt; die weet het precies.

Wat je in elk geval doet:

• Houd de afrekenpagina kaal. Elk script op die pagina kan in principe meelezen: chatwidgets, tagmanagers, advertentiepixels, A/B-testtools. Laad op de afrekenpagina alleen wat nodig is voor de betaling. Een tagmanager op de afrekenpagina is een poort waardoor iedereen met toegang tot dat account scripts kan toevoegen.
• Weinig plugins, en bijgewerkt (les 6.2). De meeste e-skimming op WordPress komt binnen via een lek in een plugin of een gestolen beheerderswachtwoord.
• Een Content-Security-Policy (een kopregel die zegt van welke domeinen scripts mogen komen) beperkt de schade als er toch iets binnenkomt. Dat is werk voor iemand die het kan testen; een verkeerde CSP breekt je betaalknop.

https en HSTS op de afrekenpagina

Dat je hele shop via https loopt, is vanzelfsprekend (WordPress-cursus, les 3.1). Voor de afrekenpagina komen er twee dingen bij:

• http moet direct doorsturen naar https, met een permanente doorsturing (301 of 308). Een klant die ooit http://shop.example.com/afrekenen/ intypt, mag geen onversleutelde pagina krijgen.
• HSTS (HTTP Strict Transport Security) is een kopregel waarmee je de browser opdraagt je site een tijd lang alleen via https te openen. Daarmee voorkom je dat iemand op een open wifi de eerste onversleutelde opvraging onderschept. Een max-age van minstens 180 dagen is een gangbaar minimum. Zet HSTS pas aan als alles, ook subdomeinen die je meeneemt, via https werkt: een browser die HSTS heeft gezien, weigert daarna http. KB 6752 legt uit hoe je het instelt.

Gemengde inhoud (een script of stylesheet via http op een https-pagina) op de afrekenpagina is extra gevaarlijk: precies zo'n bestand kan onderweg worden vervangen.

Card testing

Bij card testing gebruiken criminelen jouw shop om gestolen kaartnummers uit te proberen. Ze plaatsen automatisch honderden kleine bestellingen. Elke gelukte betaling vertelt hen dat een kaart werkt. Jij krijgt een stapel mislukte bestellingen, kosten per transactie, terugboekingen en in het ergste geval een betaalprovider die je account blokkeert.

Herkennen: veel bestellingen in korte tijd, vaak van hetzelfde kleine product, met verschillende namen maar dezelfde of rare adressen, en veel status Mislukt.

Beperken:

• Rate limiting (een grens aan het aantal verzoeken per tijd). De Store API van WooCommerce, die de blokken voor winkelwagen en afrekenen gebruiken, heeft rate limiting ingebouwd, maar die staat standaard uit. Bij WooCommerce > Instellingen > Geavanceerd > Functies kun je "Rate limiting Checkout block and Store API" aanzetten voor het plaatsen van bestellingen. Met code (een filter) kun je de grens zelf instellen; de standaard is 25 verzoeken per 10 seconden en alleen bestellen en andere schrijfacties tellen mee. Zit je shop achter een proxy of CDN, dan moet de proxyondersteuning aan, anders tellen alle bezoekers als één.
• Een captcha of een vergelijkbare drempel bij het afrekenen. WooCommerce zegt zelf dat rate limiting en captcha samen het best werken: aanvallers wisselen vaak van IP-adres.
• De instellingen van je betaalprovider. Providers hebben eigen fraudefilters en limieten. Zet ze aan en kijk wat ze melden.
• 3-D Secure (de extra bevestiging in de bankapp, onderdeel van sterke klantauthenticatie in de EU) maakt het voor criminelen lastiger en verschuift bij een geschil vaak de aansprakelijkheid naar de bank van de kaarthouder.

Andere fraude

Niet elke fraude is geautomatiseerd. Signalen die bij elkaar opgeteld reden geven om even te wachten met verzenden:

• factuur- en afleveradres in verschillende landen, of een afleveradres bij een doorzendservice;
• een eerste bestelling met alleen dure, makkelijk door te verkopen producten, met spoedverzending;
• meerdere pogingen met verschillende kaarten;
• een klant die na betaling vraagt naar een ander adres te sturen.

Een terugboeking (chargeback) is het terugdraaien van een kaartbetaling door de bank van de klant. Je verliest het bedrag, vaak met kosten, en het product is weg. Bewaar daarom bewijs van verzending en levering. Een iDEAL-betaling kon tot nu toe niet worden teruggedraaid op deze manier; hoe dat bij Wero gaat, hoor je van je betaalprovider (les 4.4).

Samenvatting

• Kaartgegevens komen nooit in je shop: niet in formulieren, notities of mails. De betaalprovider verwerkt ze.
• Doorsturen naar de betaalpagina of een ingebed veld van de provider houdt je in de lichtste PCI-vragenlijst (SAQ A); bij een ingebed veld moet je afrekenpagina beschermd zijn tegen scriptaanvallen.
• Houd de afrekenpagina kaal, via https met een 301 vanaf http en met HSTS van minstens 180 dagen.
• Card testing beperk je met rate limiting (standaard uit), een captcha en de filters van je provider.
• Let op signalen van fraude en bewaar bewijs van levering tegen terugboekingen.

Quiz

Opdracht

Opdracht A6.3: Is je afrekenpagina veilig? Vul het adres van je shop in en het adres van je afrekenpagina. Het programma controleert het certificaat, vraagt de afrekenpagina op via http (zonder door te sturen) en via https (met een lege winkelwagen, er wordt niets besteld). Groen als het certificaat geldig is, http met 301 of 308 naar https stuurt, de kopregel Strict-Transport-Security een max-age van minstens 180 dagen heeft, er geen gemengde inhoud is en er hoogstens vijf andere domeinen scripts op de pagina laden (het programma toont ze). Oranje bij geen of te korte HSTS, een tijdelijke doorsturing (302 of 307), meer dan vijf scriptdomeinen of een tagmanager, of een kaartnummerveld in de eigen HTML in plaats van bij de provider. Rood als https of het certificaat niet klopt, http niet doorstuurt, of scripts of stylesheets via http laden. Kaartgegevens nooit zelf opslaan. Deze controle ziet alleen wat er zonder winkelwagen op de pagina staat.

Vraag voor jezelf (niet nagekeken): stuurt jouw betaalplugin door naar de provider, of staat het betaalveld in je pagina? Welke SAQ zegt je provider dat geldt?

Een groen vinkje betekent dat deze controle nu klopt, niet dat je shop veilig is.

Verder lezen

Stappen in een paneel gelden voor WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Gratis WordPress-cursus 3.1: https en het certificaat
• HSTS en beveiligingsheaders voor je website
• Bezoekers verplicht doorsturen naar https
• DirectAdmin handleiding 6.4: Bezoekers altijd naar https sturen
• Gratis cursus Veilig online voor ondernemers 4.2: Je website: https, HSTS en beveiligingsheaders
• Updates voor SAQ A (PCI Security Standards Council, Engels): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting voor de Store API (developer.woocommerce.com, Engels): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, Engels): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/
• Betaalveiligheid in je webshop: PCI, card testing en wat je hoster doet