Buiten PCI-DSS-bereik blijven: kaartgegevens raken nooit je server

Je runt een restaurant met 18 tafels in Amsterdam en wilt dat gasten direct via het QR-menu met kaart betalen. Zodra een ruwe PAN je server raakt, val je binnen PCI-DSS SAQ-D — pen-tests, ASV-scans, segmentatie-audits, eenvoudig 8.000 EUR+ per jaar. Met de juiste architectuur zijn die kosten nul.

SAQ-A vs SAQ-D

SAQ-A is de lichtste PCI-DSS-zelfbeoordeling — 22 ja/nee vragen voor handelaren die kaartgegevens volledig uitbesteden. Juridische kosten: 0 EUR.

SAQ-D treedt in werking zodra kaartgegevens je systemen raken — geheugen, logs, tijdelijke variabelen. Reken op 8.000-15.000 EUR jaarlijkse compliance.

Het Stripe Elements patroon

Stripe.js Elements rendert het kaartveld binnen een iframe bediend vanuit js.stripe.com. PAN, CVV en vervaldatum delen nooit origin met je app.

• Gast typt kaart → blijft binnen Stripe-iframe
• Frontend roept stripe.confirmCardPayment(secret) aan
• Je server ziet alleen het token (pi_xxx)

thMenu doet dit standaard

De Platinum-laag van thMenu levert Stripe Elements out-of-the-box. Er bestaat geen optie om "kaart naar server te sturen", want de backendcode verwijst nooit naar een PAN. 3D Secure 2.0 en PSD2 SCA worden volledig aan de Stripe-zijde afgehandeld.

Voor een Nederlands restaurant betekent dit nul extra gesprekken met de AP over kaartretentie — gewoon de ingevulde SAQ-A indienen bij je acquirer.

FAQ

Vereist SAQ-A een jaarlijkse audit? Nee, het is een zelfbeoordeling die je jaarlijks invult en bij je acquirer indient.

Brengen Stripe webhooks je terug in scope? Nee. Payload bevat alleen laatste 4 cijfers, merk en vervaldatum.

Wat met telefonische bestellingen? Als personeel de kaart intypt val je in SAQ-D. Gebruik Stripe Terminal of Payment Links.

Was dit nuttig? Deel het.