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

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/ru/blog/pci-dss

Если данные карт хоть раз касаются написанного вами кода, на вас ложится весь груз PCI DSS. Вот лестница эскалации от SAQ A до SAQ D, причины, почему при очной оплате необходимо сертифицированное оборудование, и как построить архитектуру так, чтобы избежать этих проблем.

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

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

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

PCI DSS (Payment Card Industry Data Security Standard) — это договорное обязательство, а не закон. Карточные системы налагают его на банки и платежные процессоры, а те — на продавцов и программное обеспечение, используемое этими продавцами. Текущая версия — 4.0.1, и последняя волна новых требований стала обязательной 31 марта 2025 года[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Стандарт охватывает 12 семейств требований — от сетевой безопасности и шифрования до контроля доступа и логирования, которые разворачиваются в сотни отдельных контролей[²](https://secureframe.com/blog/pci-saq).

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

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

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

- **SAQ A** (Self-Assessment Questionnaire A): платежи полностью переданы стороннему провайдеру, соответствующему стандарту, и данные карт никогда не касаются ваших систем. Самый короткий опросник.
- **SAQ A-EP**: ваш сайт никогда не касается данных карт, но управляет тем, как клиенты переходят к форме оплаты. Значительная часть полного стандарта теперь применяется к вашим веб-серверам.
- **SAQ D**: данные карт проходят через что-либо, созданное вами, даже кратковременно и без сохранения. Фактически весь стандарт, документируемый и подтверждаемый ежегодно.

![Стопка документов по соответствию с банковской картой наверху, символизирующая опросники самооценки PCI DSS](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

Нижняя ступень — это тоже не «ничего». В январе 2025 года Совет по стандартам безопасности PCI удалил требования к скриптам на платежной странице из SAQ A, но добавил условие допуска: вы должны подтвердить, что ваш сайт не подвержен скриптовым атакам, которые могут повлиять на систему электронной коммерции[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Даже при полной передаче на аутсорсинг от вас требуется защищать страницу, на которой размещена чужая форма оплаты.

При превышении шести миллионов карточных транзакций в год самооценка прекращается полностью, и начинается очный аудит квалифицированным аудитором QSA[²](https://secureframe.com/blog/pci-saq).

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

Нет. При очной оплате лестница превращается в стену. Транзакции с присутствием карты требуют сертифицированного оборудования: физических считывателей, прошедших [программу лаборатории PTS](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/) Совета, работающих на утвержденной прошивке и предоставленных через платежный процессор. Превращение смартфона в считыватель только с помощью ПО подпадает под отдельный стандарт — [Mobile Payments on COTS (MPoC)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/), и он сертифицирует провайдера решения, а не вашу разработку.

![Сертифицированный платежный терминал без логотипа на прилавке магазина — аппаратный уровень, требуемый PCI для очных платежей](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

Это граница, которую генерация кода ИИ не может пересечь. Модель может за полдня создать убедительный экран кассы; в статьях [Можно ли создать POS с помощью Lovable или Replit?](/blog/build-a-pos-with-lovable-or-replit) и [Вайб-кодинг POS-системы](/blog/vibe-coding-a-point-of-sale) показано, где такие проекты заходят в тупик. Никакой сгенерированный код не заменит сертифицированный считыватель, эквайринговый договор или сертификат соответствия, [сколько бы модель ни кодила без присмотра](/blog/claude-opus-5-pos-more-than-code). Соответствие требованиям также является регулярной причиной, почему [созданные вайб-кодингом платежные приложения получают отказ в App Store](/blog/why-vibe-coded-payment-apps-get-rejected).

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

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

- Никогда не допускайте попадания PAN (основного номера счета, то есть самого номера карты) в ваш код. Используйте хостинговые платежные поля вашего процессора, чтобы данные карт отправлялись из браузера клиента напрямую процессу.
- Храните токены, а не карты. Токенизация (замена номера карты ссылочной строкой, бесполезной при краже) защищает вашу базу данных от попадания в область применения PCI при сохранении карт и возвратах.
- Для очных продаж используйте сертифицированные считыватели от вашего процессора, чтобы данные карт передавались со считывателя процессору без прохождения через ваше приложение.
- Делайте платежную страницу максимально простой. Каждый сторонний скрипт на ней превращается в объект, за который вам придется отчитываться.

![Запечатанная в стеклянном футляре банковская карта, символизирующая вывод данных карт из области применения PCI](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

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

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

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

Именно такую архитектуру использует и Final. Оформление заказа в Final, независимо от того, создано ли оно по запросу в Build или с помощью вашего собственного ИИ через MCP, проводит платежи через Final Pay: платежный процессор и сертифицированное терминальное оборудование обрабатывают данные карт, поэтому сам сценарий никогда не владеет номером карты. В статье [Где доступен Final Pay](https://finalpos.com/help/where-final-pay-is-available) описана практическая сторона, а в материале [Подключение Tap to Pay к AI POS-процессу](/blog/connecting-tap-to-pay-to-an-ai-pos-flow) показано, как выглядит прием карт, когда уровень соответствия уже заложен внутри.

## FAQ

**Q: Является ли соответствие PCI DSS законодательным требованием?**
A: Нет. PCI DSS — это договорное обязательство, налагаемое карточными системами через банки и платежные процессоры. Последствия носят коммерческий характер: штрафы, транслируемые через ваш банк-эквайер, повышенные комиссии за обработку или лишение возможности принимать карты.

**Q: Снимает ли полная передача обработки платежей на аутсорсинг обязательства по PCI?**
A: Нет. Продавцы, полностью передавшие платежи на аутсорсинг, могут проходить валидацию по опроснику SAQ A (самому короткому), однако с января 2025 года они также должны подтверждать, что их сайт не уязвим для скриптовых атак, способных повлиять на систему электронной коммерции.

**Q: В чем разница между SAQ A и SAQ D?**
A: SAQ A применяется, когда все данные карт обрабатываются сторонним провайдером, соответствующим стандарту, и охватывает лишь небольшую часть требований. SAQ D применяется, если данные карт касаются ваших собственных систем, и фактически охватывает весь стандарт с ежегодным подтверждением.

**Q: Может ли приложение, созданное ИИ, соответствовать PCI DSS?**
A: Код может следовать безопасным паттернам, но соответствие стандарту относится к бизнесу и его инфраструктуре: сертифицированные считыватели карт, договор с процессором и ежегодное подтверждение. Никакой сгенерированный код не заменит эти элементы.

**Q: Какая версия PCI DSS является актуальной?**
A: PCI DSS 4.0.1 на момент публикации этой статьи. Ее последние отложенные требования стали обязательными 31 марта 2025 года. Актуальную информацию смотрите на сайте Совета по стандартам безопасности PCI.