Вне области PCI-DSS: данные карты никогда не попадают на ваш сервер

Вы управляете рестораном на 18 столиков и хотите, чтобы гости платили картой прямо через QR-меню. Как только сырой PAN коснётся вашего сервера, вы попадаете в область PCI-DSS SAQ-D — пен-тесты, ASV-сканирование, аудиты сегментации, легко 8.000 EUR+ в год. С правильной архитектурой эта сумма равна нулю.

SAQ-A против SAQ-D

SAQ-A — самая лёгкая самооценка PCI-DSS, 22 вопроса для торговцев, полностью отдающих данные карт PCI-валидированному провайдеру. Юридические затраты: 0 EUR.

SAQ-D вступает в силу, как только данные карты касаются ваших систем — памяти, логов, временных переменных. Рассчитывайте на 8.000-15.000 EUR ежегодных расходов на соответствие.

Паттерн Stripe Elements

Stripe.js Elements отрисовывает поле карты внутри iframe, обслуживаемого с js.stripe.com. PAN, CVV и срок никогда не делят origin с вашим приложением — ваш JavaScript не может их прочитать.

• Клиент вводит карту → остаётся в iframe Stripe
• Frontend вызывает stripe.confirmCardPayment(secret)
• Сервер видит только токен (pi_xxx)

thMenu делает это по умолчанию

В тарифе Platinum thMenu Stripe Elements встроены по умолчанию. Нет опции "отправить карту на сервер", потому что backend-код не ссылается на PAN. 3D Secure 2.0 и PSD2 SCA обрабатываются на стороне Stripe.

Для российского или европейского ресторана это означает отсутствие дополнительных переговоров с регулятором об удержании данных карт — просто подаёте заполненный SAQ-A эквайеру.

FAQ

Нужен ли ежегодный аудит при SAQ-A? Нет, это самооценка, которую вы заполняете и подаёте эквайеру раз в год.

Возвращают ли вебхуки Stripe меня в область? Нет. Payload содержит только последние 4 цифры, бренд и срок — никогда полный PAN.

А заказы по телефону? Если сотрудник вводит карту, вы попадаете в SAQ-D. Используйте Stripe Terminal или Payment Links.

Было полезно? Поделитесь.