Poza zakresem PCI-DSS: dane karty nigdy nie dotykają twojego serwera

Prowadzisz restaurację z 18 stolikami w Krakowie i chcesz, by goście płacili kartą bezpośrednio z menu QR. W momencie gdy surowy PAN dotknie twojego serwera, wpadasz w zakres PCI-DSS SAQ-D — pen-testy, skany ASV, audyty segmentacji, łatwo 8.000 EUR+ rocznie. Z właściwą architekturą koszt to zero.

SAQ-A kontra SAQ-D

SAQ-A to najlżejsza samoocena PCI-DSS — 22 pytania tak/nie dla sprzedawców całkowicie wynajmujących dane karty. Koszt prawny: 0 EUR.

SAQ-D obowiązuje, gdy dane karty dotkną twoich systemów — pamięci, logów, zmiennych tymczasowych. Spodziewaj się 8.000-15.000 EUR rocznego compliance.

Wzorzec Stripe Elements

Stripe.js Elements renderuje pole karty wewnątrz iframe serwowanego z js.stripe.com. PAN, CVV i data ważności nigdy nie współdzielą origin z twoją aplikacją.

• Gość wpisuje kartę → pozostaje w iframe Stripe
• Frontend wywołuje stripe.confirmCardPayment(secret)
• Serwer widzi tylko token (pi_xxx)

thMenu robi to domyślnie

Plan Platinum thMenu wykorzystuje Stripe Elements domyślnie. Nie istnieje opcja "wyślij kartę na serwer", ponieważ kod backendu nigdy nie odwołuje się do PAN. 3D Secure 2.0 i PSD2 SCA są obsługiwane po stronie Stripe.

Dla polskiej restauracji oznacza to zero dodatkowych rozmów z UODO o retencji karty — wystarczy przesłać wypełniony SAQ-A do acquirera.

FAQ

Czy SAQ-A wymaga rocznego audytu? Nie, to samoocena którą wypełniasz raz w roku i deklarujesz acquirerowi.

Czy webhooki Stripe wracają mnie do zakresu? Nie. Payload zawiera tylko ostatnie 4 cyfry, markę i datę ważności.

A zamówienia telefoniczne? Gdy personel wpisuje kartę, przechodzisz do SAQ-D. Używaj Stripe Terminal lub Payment Links.

Czy to było pomocne? Udostępnij.