PCI-DSS-laajuuden ulkopuolella: korttitiedot eivät koskaan kosketa palvelintasi

Pyörität 18-pöytäistä ravintolaa Helsingissä ja haluat asiakkaiden maksavan kortilla suoraan QR-ruokalistalta. Sillä hetkellä kun raaka PAN koskettaa palvelintasi, putoat PCI-DSS SAQ-D -laajuuteen — pen-testit, ASV-skannaukset, segmentointitarkastukset, helposti 8.000 EUR+ vuodessa. Oikealla arkkitehtuurilla kustannus on nolla.

SAQ-A vs SAQ-D

SAQ-A on kevyin PCI-DSS-itsearvio — 22 kyllä/ei-kysymystä kauppiaille jotka ulkoistavat korttitiedot kokonaan. Lakikustannukset: 0 EUR.

SAQ-D astuu voimaan heti kun korttitiedot koskettavat järjestelmiäsi — muistia, lokeja, väliaikaismuuttujia. Varaudu 8.000-15.000 EUR vuotuisiin compliance-kuluihin.

Stripe Elements -malli

Stripe.js Elements renderöi korttikentän iframe-elementissä, jota tarjoaa js.stripe.com. PAN, CVV ja erääntyminen eivät koskaan jaa origin-arvoa sovelluksesi kanssa.

• Asiakas kirjoittaa kortin → pysyy Stripe-iframessä
• Frontend kutsuu stripe.confirmCardPayment(secret)
• Palvelimesi näkee vain tokenin (pi_xxx)

thMenu tekee tämän oletuksena

thMenun Platinum-taso käyttää Stripe Elementsiä oletuksena. "Lähetä kortti palvelimelle" -vaihtoehtoa ei ole olemassa, koska backend-koodi ei koskaan viittaa PANiin. 3D Secure 2.0 ja PSD2 SCA käsitellään Stripen puolella.

Suomalaiselle ravintolalle tämä tarkoittaa nolla lisäkeskustelua tietosuojavaltuutetun kanssa kortin säilytyksestä — vain täytetty SAQ-A acquirerille.

FAQ

Vaatiiko SAQ-A vuositarkastuksen? Ei, se on itsearvio jonka täytät vuosittain ja vakuutat acquirerillesi.

Palauttavatko Stripe-webhookit minut laajuuteen? Ei. Payload sisältää vain viimeiset 4 numeroa, brändin ja erääntymisen.

Entä puhelintilaukset? Kun henkilökunta näppäilee kortin, siirryt SAQ-D:hen. Käytä Stripe Terminalia tai Payment Linksiä.

Oliko tästä hyötyä? Jaa se.