SAQ A — не броня, а бумажка для тех, кто спрятал платёжку в iframe
SAQ A продают как «минимум PCI-боли»: мол, если карточные данные не касаются вашего сервера, можно выдохнуть. На практике это означает лишь одно — вы переложили сбор PAN на чужой фронт, но не сняли с себя ответственность за всё остальное. Идемпотентность или смерть: утечка часто приходит не через платёжный шлюз, а через скрипт, который подменил страницу оплаты на вашем домене.
Если у вас есть:
— кастомные JS-теги, которые могут читать DOM;
— редиректы на оплату без жёсткой валидации return URL;
— виджеты, загружаемые с десятка CDN;
— формы логина и оплаты на одном домене;
то SAQ A превращается в костыль на костыле и финтехом погоняет. Документация обещает «не храните данные карт», а логи потом показывают, что вы сами засветили токены, email и полный путь до checkout.
Главная ошибка — считать, что compliance равен безопасности. Нет. PCI отвечает за срез требований, а не за ваш фронтенд, supply chain и дисциплину с CSP. Если злоумышленник внедрил скрипт, он украдёт ввод до отправки в PSP. Если вебхук не валидируется, он нарисует вам фейковый успех. Если токен живёт дольше сессии, ваш мерчант забанен без объяснения причин.
Проверяйте, кто реально исполняется на checkout: ограничивайте third-party JS, ставьте CSP, режьте лишние права, валидируйте все callback’и и не храните «временно» то, что потом никто не удалит. Документация — это ложь, логи — истина.
Интеграция платежных решений
@payment_integration_ops_arb
SAQ A — не броня, а бумажка для тех, кто спрятал платёжку в iframe
Этот пост опубликован в Telegram-канале Интеграция платежных решений. Подписаться можно по ссылке: @payment_integration_ops_arb.