Utenfor PCI-DSS-omfang: kortdata berører aldri serveren din

Du driver en restaurant med 18 bord i Oslo og vil at gjestene betaler med kort direkte fra QR-menyen. Idet en rå PAN berører serveren din, faller du innenfor PCI-DSS SAQ-D-omfang — pen-tester, ASV-skanninger, segmenteringsrevisjoner, lett 8.000 EUR+ per år. Med riktig arkitektur er kostnaden null.

SAQ-A vs SAQ-D

SAQ-A er den letteste PCI-DSS-egenvurderingen — 22 ja/nei-spørsmål for handlere som outsourcer kortdata fullstendig. Juridiske kostnader: 0 EUR.

SAQ-D gjelder så snart kortdata berører systemene dine — minne, logger, midlertidige variabler. Forvent 8.000-15.000 EUR årlig compliance.

Stripe Elements-mønsteret

Stripe.js Elements rendrer kortfeltet inni en iframe servert fra js.stripe.com. PAN, CVV og utløp deler aldri origin med appen din.

• Gjest skriver kortet → forblir i Stripe-iframen
• Frontend kaller stripe.confirmCardPayment(secret)
• Serveren ser bare tokenet (pi_xxx)

thMenu gjør dette som standard

Platinum-planen til thMenu leverer Stripe Elements rett ut av boksen. Det finnes ingen "send kort til server"-alternativ, fordi backend-koden aldri refererer en PAN. 3D Secure 2.0 og PSD2 SCA håndteres på Stripe-siden.

For en norsk restaurant betyr dette null ekstra samtaler med Datatilsynet om kortlagring — bare lever det utfylte SAQ-A til din acquirer.

FAQ

Krever SAQ-A årlig revisjon? Nei, det er en egenvurdering du fyller ut årlig og erklærer overfor din acquirer.

Tar Stripe-webhooks meg tilbake i omfanget? Nei. Payloaden inneholder kun siste 4 sifre, merke og utløp.

Hva med telefonbestillinger? Når personalet taster inn kortet havner du i SAQ-D. Bruk Stripe Terminal eller Payment Links.

Var dette nyttig? Del det.