Соответствие PCI DSS для разработчиков приложений: краткая и суровая версия

Соответствие PCI DSS (правила безопасности индустрии платежных карт для всех, кто обрабатывает данные карт) — это цена слов «принимаем кредитные карты». Краткая версия: если данные карт хоть раз касаются написанного вами кода или используемых вами серверов, вы наследуете стандарт безопасности с сотнями требований, ежегодным подтверждением соответствия (формальной подписанной декларацией о соответствии стандарту) и последствиями, транслируемыми через ваш платежный процессор. Суровая версия PCI DSS для разработчиков приложений: большинство узнает об этом уже после того, как кассовый модуль построен.

Одно примечание перед детализацией. Номера версий, даты и правила опросников ниже точны на момент публикации; стандарт меняется, поэтому воспринимайте детали как снимок на текущий момент.

Что такое PCI DSS на самом деле?

PCI DSS (Payment Card Industry Data Security Standard) — это договорное обязательство, а не закон. Карточные системы налагают его на банки и платежные процессоры, а те — на продавцов и программное обеспечение, используемое этими продавцами. Текущая версия — 4.0.1, и последняя волна новых требований стала обязательной 31 марта 2025 года¹. Стандарт охватывает 12 семейств требований — от сетевой безопасности и шифрования до контроля доступа и логирования, которые разворачиваются в сотни отдельных контролей².

Никакие регуляторы не придут к вашей двери. Последствия наступают коммерческим путем: штрафы, транслируемые через ваш банк-эквайер (банк, осуществляющий расчеты по картам для продавца), повышенные комиссии за обработку, а в худшем случае — лишение возможности принимать карты вообще. После утечки данных расходы на расследование и перевыпуск карт идут по тому же пути.

Почему «просто добавить оплату» вводит всё приложение в область аудита?

Область применения (scope) — это главное. PCI DSS применяется ко всем системам, которые хранят, обрабатывают или передают данные держателей карт, а также ко всему, что подключено к этим системам. Валидация похожа на лестницу, где каждая следующая ступень значительно тяжелее предыдущей²:

• SAQ A (Self-Assessment Questionnaire A): платежи полностью переданы стороннему провайдеру, соответствующему стандарту, и данные карт никогда не касаются ваших систем. Самый короткий опросник.

• SAQ A-EP: ваш сайт никогда не касается данных карт, но управляет тем, как клиенты переходят к форме оплаты. Значительная часть полного стандарта теперь применяется к вашим веб-серверам.

• SAQ D: данные карт проходят через что-либо, созданное вами, даже кратковременно и без сохранения. Фактически весь стандарт, документируемый и подтверждаемый ежегодно.

Нижняя ступень — это тоже не «ничего». В январе 2025 года Совет по стандартам безопасности PCI удалил требования к скриптам на платежной странице из SAQ A, но добавил условие допуска: вы должны подтвердить, что ваш сайт не подвержен скриптовым атакам, которые могут повлиять на систему электронной коммерции¹. Даже при полной передаче на аутсорсинг от вас требуется защищать страницу, на которой размещена чужая форма оплаты.

При превышении шести миллионов карточных транзакций в год самооценка прекращается полностью, и начинается очный аудит квалифицированным аудитором QSA².

Можно ли решить вопрос очной оплаты только с помощью кода?

Нет. При очной оплате лестница превращается в стену. Транзакции с присутствием карты требуют сертифицированного оборудования: физических считывателей, прошедших программу лаборатории PTS Совета, работающих на утвержденной прошивке и предоставленных через платежный процессор. Превращение смартфона в считыватель только с помощью ПО подпадает под отдельный стандарт — Mobile Payments on COTS (MPoC), и он сертифицирует провайдера решения, а не вашу разработку.

Это граница, которую генерация кода ИИ не может пересечь. Модель может за полдня создать убедительный экран кассы; в статьях Можно ли создать POS с помощью Lovable или Replit? и Вайб-кодинг POS-системы показано, где такие проекты заходят в тупик. Никакой сгенерированный код не заменит сертифицированный считыватель, эквайринговый договор или сертификат соответствия, сколько бы модель ни кодила без присмотра. Соответствие требованиям также является регулярной причиной, почему созданные вайб-кодингом платежные приложения получают отказ в App Store.

Как разработчики на самом деле сокращают область применения PCI DSS?

Не нужно пытаться выполнить требования «сильнее» — нужно проектировать архитектуру так, чтобы соответствовать приходилось меньшему количеству правил:

• Никогда не допускайте попадания PAN (основного номера счета, то есть самого номера карты) в ваш код. Используйте хостинговые платежные поля вашего процессора, чтобы данные карт отправлялись из браузера клиента напрямую процессу.

• Храните токены, а не карты. Токенизация (замена номера карты ссылочной строкой, бесполезной при краже) защищает вашу базу данных от попадания в область применения PCI при сохранении карт и возвратах.

• Для очных продаж используйте сертифицированные считыватели от вашего процессора, чтобы данные карт передавались со считывателя процессору без прохождения через ваше приложение.

• Делайте платежную страницу максимально простой. Каждый сторонний скрипт на ней превращается в объект, за который вам придется отчитываться.

При правильном подходе ваше приложение организует продажу, ни разу не получая данные карт, и опросник остается коротким. При неправильном — одна удобная функция («давайте просто логировать тело запроса целиком») незаметно переведет вас на SAQ D.

Так насколько болезненно соответствие PCI DSS для разработчиков приложений?

Болезненно ровно в той степени, в какой ваш код касается данных карт, поэтому самый выигрышный ход — не касаться их вовсе. Стандарту все равно, кто написал ваше приложение — команда разработчиков или ИИ за один день: область применения есть область применения. Прежде чем запускать что-либо, принимающее карты, задайте один вопрос: может ли номер карты хоть раз пройти через написанный мною код? Если да — закладывайте бюджет на аудит. Если нет — сохраняйте такую архитектуру.

Именно такую архитектуру использует и Final. Оформление заказа в Final, независимо от того, создано ли оно по запросу в Build или с помощью вашего собственного ИИ через MCP, проводит платежи через Final Pay: платежный процессор и сертифицированное терминальное оборудование обрабатывают данные карт, поэтому сам сценарий никогда не владеет номером карты. В статье Где доступен Final Pay описана практическая сторона, а в материале Подключение Tap to Pay к AI POS-процессу показано, как выглядит прием карт, когда уровень соответствия уже заложен внутри.