Utanför PCI-DSS-omfattning: kortdata rör aldrig din server

Du driver en restaurang med 18 bord i Stockholm och vill att gäster betalar med kort direkt från QR-menyn. I det ögonblick ett rått PAN rör din server hamnar du inom PCI-DSS SAQ-D-omfattning — pen-tester, ASV-skanningar, segmenteringsrevisioner, lätt 8.000 EUR+ per år. Med rätt arkitektur är kostnaden noll.

SAQ-A vs SAQ-D

SAQ-A är den lättaste PCI-DSS-självbedömningen — 22 ja/nej-frågor för handlare som helt outsourcar kortdata. Juridiska kostnader: 0 EUR.

SAQ-D gäller så snart kortdata rör dina system — minne, loggar, tillfälliga variabler. Räkna med 8.000-15.000 EUR årlig compliance.

Stripe Elements-mönstret

Stripe.js Elements renderar kortfältet inuti en iframe serverad från js.stripe.com. PAN, CVV och utgång delar aldrig origin med din app.

• Gäst skriver kortet → förblir i Stripe-iframen
• Frontend anropar stripe.confirmCardPayment(secret)
• Servern ser bara tokenen (pi_xxx)

thMenu gör detta som standard

Platinum-planen i thMenu levererar Stripe Elements direkt. Det finns ingen "skicka kort till server"-option eftersom backendkoden aldrig refererar ett PAN. 3D Secure 2.0 och PSD2 SCA hanteras på Stripe-sidan.

För en svensk restaurang innebär detta noll extra samtal med IMY om kortlagring — bara lämna in den ifyllda SAQ-A till din acquirer.

FAQ

Kräver SAQ-A en årlig revision? Nej, det är en självbedömning du fyller i årligen och deklarerar till din acquirer.

Återför Stripe-webhooks mig till omfattningen? Nej. Payloaden innehåller bara sista 4 siffrorna, märke och utgång.

Och telefonbeställningar? När personalen knackar in kortet hamnar du i SAQ-D. Använd Stripe Terminal eller Payment Links.

Var detta hjälpsamt? Dela det.