PCI DSS SAQ A не спасает данные, если у вас кривой checkout и вебхуки без замка
SAQ A — это не бронежилет, а бумажка о том, что вы кое-как ушли от прямого приема карты. Дальше начинается любимый цирк: JS на странице подмешивает сторонние скрипты, редирект на провайдера встраивается через костыль, а токены и ответы API гуляют по логам и аналитике.
Идемпотентность или смерть. Если у вас нет жесткой схемы ключей, повторный запрос превращается в двойное списание, а потом в ручной разбор с поддержкой и мерчантом на нервах. Документация — это ложь, логи — истина. Проверяйте не «как задумано», а что реально улетает в webhook, retry и callback.
Три дыры, которые SAQ A не закрывает:
— доступ к админке платежного виджета через слабые роли;
— хранение PII и email рядом с платежными идентификаторами;
— отсутствие сегментации: фронт, бэкенд и аналитика сидят в одной куче. Костыль на костыле и финтехом погоняет.
Если хотите не изображать комплаенс, а снизить риск, режьте лишние скрипты, подписывайте вебхуки, изолируйте платежный контур и регулярно проверяйте, кто вообще видит payload. И да, ваш мерчант забанен без объяснения причин чаще всего не из-за пинков PCI, а из-за собственной архитектурной халтуры.
Интеграция платежных решений
@payment_integration_ops_arb
PCI DSS SAQ A не спасает данные, если у вас кривой checkout и вебхуки без замка
Этот пост опубликован в Telegram-канале Интеграция платежных решений. Подписаться можно по ссылке: @payment_integration_ops_arb.