Многие интернет-магазины считают, что, передав приём платежей Stripe, PayPal или аналогичному провайдеру, вопрос безопасности платежей их больше напрямую не касается. Это верно лишь отчасти. Стандарт PCI DSS, регулирующий безопасность данных банковских карт, по-прежнему применяется к любому бизнесу, принимающему платежи картой, даже когда техническая обработка делегирована третьей стороне.

Что на самом деле означает PCI DSS

PCI DSS, Payment Card Industry Data Security Standard, — это набор требований безопасности, установленных самими платёжными системами, такими как Visa и Mastercard, для любого бизнеса, хранящего, обрабатывающего или передающего данные карт. Это не закон в строгом смысле, а договорное обязательство, связанное с приёмом карточных платежей, несоблюдение которого может повлечь санкции, применяемые через банк-эквайер продавца.

Почему малый бизнес, использующий Stripe или PayPal, всё равно подпадает под требования

Подавляющее большинство небольших интернет-магазинов относится к самой простой категории, называемой SAQ A, предназначенной для продавцов, полностью передающих обработку платежа стороннему провайдеру, который сам соответствует стандарту. Это типичный случай магазина на WooCommerce, перенаправляющего клиента на страницу оплаты, размещённую у Stripe или PayPal, либо встраивающего их форму без прохождения номера карты через собственный сервер. Такой упрощённый уровень значительно снижает нагрузку по соответствию, но не устраняет её полностью: продавец сохраняет собственную ответственность, в частности за безопасность собственной веб-страницы вокруг платёжного модуля.

Что изменилось с 2025 года

Версия 4.0 стандарта, ставшая полностью обязательной с 31 марта 2025 года, ввела два требования, напрямую касающихся сайтов электронной коммерции, использующих размещённую у провайдера оплату: мониторинг сторонних скриптов, загружаемых на странице оплаты, и механизм авторизации для любого скрипта, добавленного или изменённого на этой странице. На практике сайт WooCommerce, загружающий на той же странице, что и платёжный модуль, скрипты аналитики, рекламные пиксели или маркетинговые плагины, даже если сама оплата размещена внешне, теперь должен вести инвентарь этих скриптов и отслеживать любые несанкционированные изменения. Эти требования существуют потому, что скомпрометированный сторонний скрипт на странице оплаты может перехватить данные карты в момент их ввода, даже если сама форма оплаты принадлежит Stripe или PayPal.

Остальные обязательства, сохраняющиеся даже при SAQ A

Форма самооценки SAQ A остаётся самой короткой, но это не простая декларация. Она требует подтверждения, что сайт не хранит, не обрабатывает и не передаёт данные карт в незашифрованном виде, что сам платёжный провайдер сертифицирован по PCI DSS, а также сохранения доказательства этого соответствия, обычно в виде аттестации, предоставленной провайдером. Стандарт также требует на всех уровнях многофакторную аутентификацию для любого административного доступа, затрагивающего платёжную среду, а также пароли не короче двенадцати символов.

Что конкретно должен проверить малый бизнес

Первый шаг — определить, какая форма самооценки реально применима, исходя из того, как технически интегрирована оплата, а не автоматически предполагать самый простой уровень. Второй шаг — составить инвентарь сторонних скриптов, присутствующих на странице оплаты сайта, часто их оказывается больше, чем кажется, если учесть маркетинговые и аналитические плагины. Третий шаг — запросить у платёжного провайдера актуальную аттестацию соответствия PCI DSS, документ, который обычно должен предоставляться по запросу.

Тема, которую не стоит полностью передавать на аутсорс

Часто повторяемое утверждение, что использование Stripe или PayPal автоматически обеспечивает соответствие PCI, неточно и может создать у продавца ложное чувство защищённости. Передача обработки платежей на аутсорс остаётся лучшим техническим решением для малого бизнеса, поскольку значительно сокращает зону ответственности, но не освобождает от проверки немногих оставшихся обязательств, особенно после ужесточения стандарта в отношении скриптов на странице оплаты.

Что стоит проверить перед публикацией: подтвердить на момент публикации, что версия 4.0.1 PCI DSS остаётся единственной действующей версией, требуемой платёжными системами, что срок 31 марта 2025 года для ранее отложенных требований остаётся точным, и проверить, что описание области действия SAQ A и требований 6.4.3 и 11.6.1 по-прежнему соответствует официальной документации PCI Security Standards Council.