CloudPayments
Войти

Безопасность и соответствие: PCI DSS, 54‑ФЗ и 152‑ФЗ в интернет‑эквайринге

Получить CloudPayments бесплатно

Безопасность и соответствие: PCI DSS, 54‑ФЗ и 152‑ФЗ в интернет‑эквайринге

В интернет‑торговле безопасный прием платежей — это сочетание технологий и соблюдения норм. Для российского бизнеса критичны три опоры: стандарт PCI DSS для защиты карточных данных, онлайн‑кассы по 54‑ФЗ и правила обработки персональных данных по 152‑ФЗ. Разберем, как совместить требования, выстроить практичную архитектуру и повысить конверсию без риска. Ключевая тема — pci dss эквайринг и безопасность онлайн платежей 54‑ФЗ 152‑ФЗ на реальных примерах.

Материал носит справочный характер и не заменяет юридическую консультацию.

Что регулируют PCI DSS, 54‑ФЗ и 152‑ФЗ

Три обязательных направления соответствия в онлайн‑эквайринге:

Регуляция Что регулирует Для кого критично Риски при несоблюдении
PCI DSS Безопасность обработки, передачи и хранения данных платежных карт Интернет‑магазины, платежные провайдеры, банки‑эквайреры Утечки карт, штрафы платежных систем, блокировка приема карт
54‑ФЗ Применение онлайн‑кассы, фискализация и отправка электронных чеков через ОФД Любые продавцы, принимающие оплату от физлиц онлайн Штрафы, блокировка расчетов, претензии от покупателей
152‑ФЗ Правомерность и безопасность обработки персональных данных (ПДн) Все сайты, собирающие ПДн (ФИО, телефон, e‑mail, адрес и т. п.) Предписания, существенные штрафы, ограничения Роскомнадзора

Начинать лучше с выбора модели интеграции и провайдера эквайринга: это определит глубину зоны PCI DSS и архитектуру фискализации. Сравнить варианты поможет раздел Сравнение провайдеров эквайринга и обзор Онлайн‑эквайринг для сайта.

Получить CloudPayments бесплатно

Потоки данных и роли участников

![Схема потоков: покупатель — сайт — платежный шлюз — банк‑эквайрер — платежная система — ОФД — онлайн‑касса — e‑mail/SMS чек]

В e‑commerce участвуют:

  • Сайт мерчанта (владельца интернет‑магазина)
  • Платежный провайдер/шлюз (PSP)
  • Банк‑эквайрер
  • ОФД и онлайн‑касса (фискализация по 54‑ФЗ)

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

PCI DSS для e‑commerce: SAQ, интеграции и минимизация зоны ответственности

Стандарт PCI DSS обязателен для всех, кто «хранит, обрабатывает или передает» данные карт. Для интернет‑магазинов чаще всего применимы сокращенные анкеты самооценки SAQ (Self‑Assessment Questionnaire) — тип зависит от интеграции.

Вариант интеграции Тип SAQ Что это значит на практике
Hosted Payment Page/редирект на платежную страницу провайдера SAQ A Карточные данные полностью обрабатываются у провайдера. Задача магазина — политика безопасности, обучение, корректные настройки сайта, отсутствие хранения карт.
Встраиваемый iFrame/виджет провайдера SAQ A или A‑EP (зависит от реализации) Если поля ввода полностью из домена провайдера — чаще SAQ A. Если страница мерчанта может повлиять на процесс — SAQ A‑EP (потребуются регулярные сканы ASV, усиленная защита веб‑части).
Собственная платежная форма, POST на провайдера SAQ A‑EP Ужесточаются требования к веб‑безопасности, мониторингу, сканированию уязвимостей и журналированию.
Прием и обработка карточных данных на стороне магазина (full API) SAQ D Полный объем PCI DSS: сегментация сети, инвентаризация, шифрование, IDS/IPS, тесты на проникновение и пр.

Рекомендация: стремиться к модели SAQ A (редирект или безопасный iFrame). Это облегчает соответствие, ускоряет запуск и снижает стоимость. В любом случае нельзя хранить PAN и CVV у себя; используйте tokenization эквайринг у провайдера.

Подробности для популярных CMS: WordPress/WooCommerce, 1C‑Битрикс, OpenCart, Tilda, CS‑Cart.

3‑D Secure 2.0, токенизация и антифрод

Три «обязательных» инструмента современного интернет‑эквайринга:

  • 3‑D Secure 2.0. Уменьшает мошенничество и сдвигает ответственность за спорные операции на эмитента. 3‑d secure настройка чаще всего выполняется через кабинет провайдера: включите 3DS по всем MCC, используйте фрикшнлесс‑потоки (RBA), корректно обрабатывайте soft decline (повтор с 3DS). Многие банки (например, Сбербанк и Альфа‑Банк) поддерживают гибкие сценарии 3DS 2.x.
  • Токенизация. Для повторных и регулярных списаний не храните реквизиты карт — получайте токены от провайдера. Это и есть tokenization эквайринг: безопасно, удобно и соответствует PCI DSS.
  • Антифрод. Используйте поведенческие правила, стоп‑листы, 3DS‑триггеры, velocity‑лимиты. Раздел Антифрод, возвраты, чарджбеки поможет выстроить политику споров и возвратов.

54‑ФЗ: онлайн‑касса и фискализация интернет‑платежей

Онлайн касса 54‑ФЗ требует пробивать чеки и передавать их через ОФД при расчетах с покупателями. В онлайне есть нюансы:

  • Когда выбивать чек. При предоплате — чек «приход» на сумму предоплаты; при отгрузке — итоговый чек (или доплата). Возвраты оформляются чеком «возврат прихода».
  • Что включать в чек. Номенклатура, цены, налоги (НДС и др.), признак способа расчета, предмет расчета, доставка (как отдельная позиция), e‑mail или телефон покупателя.
  • Кто фискализирует. Варианты: собственная облачная касса или касса провайдера/партнера. Многие PSP умеют автоматически отправлять чек по вебхуку «успешная оплата».
  • Что протестировать. Дубли платежей/чеков, отмены, частичные возвраты, подписки (регулярные списания), предавторизация/капчур.

Практическая рекомендация: синхронизировать статусы «оплата» ↔ «чек» на уровне интеграции (webhook → API кассы). Проверьте тарифы на фискализацию и эквайринг в разделе Тарифы и комиссии эквайринга.

152‑ФЗ: персональные данные, согласия и локализация

Закон 152‑ФЗ регулирует сбор, хранение и обработку ПДн. Это не только «аккаунты» — уже форма заказа с e‑mail и телефоном подпадает под 152‑ФЗ. Ключевые практики:

  • Правовые основания. Договор (оферта/пользовательское соглашение) и/или согласие субъекта данных. Согласие — явное, информированное, с целями и сроками.
  • Политика ПДн и документы. Общедоступная политика, регламенты обработки, назначение ответственного, модели угроз/рисков, учет обращений субъектов.
  • Локализация (242‑ФЗ). Первичная запись ПДн граждан РФ — на серверах в России. Выбирайте провайдеров с дата‑центрами в РФ.
  • Передача и поручение. Договоры поручения обработки ПДн с PSP, ОФД, логистикой, колл‑центром. Пропишите предмет, меры защиты, сроки и возврат/удаление данных.
  • Безопасность. TLS 1.2+, шифрование, резервное копирование, строгие роли доступа, журналирование событий, защита от утечек. Минимизация данных «по умолчанию».

Фраза для ориентирования: пдн обработка 152‑фз — это про законность, прозрачность и технические меры защиты. Проверьте, требуется ли уведомление Роскомнадзора (в большинстве случаев интернет‑магазины обязаны его подать).

Матрица ответственности: кто за что отвечает

Область Магазин Платежный провайдер Банк‑эквайрер ОФД/ККТ
PCI DSS Выбор безопасной интеграции, SAQ, политика, веб‑защита Сертификация PCI DSS Level 1, токенизация, шифрование Верификация мерчанта, риск‑контроль —
3‑D Secure Настройки правил, UI/UX, обработка soft decline Реализация 3DS 2.x, RBA Поддержка Directory Server —
Фискализация (54‑ФЗ) Корректные данные в чеке, интеграция Вебхуки статусов, автопечать чека (если есть сервис) — Обработка чека и передача в ФНС
ПДн (152‑ФЗ) Согласия, политика, договоры поручения Статус оператора‑порученца, защита ПДн — —
Антифрод/чарджбеки Правила, общение с покупателем Скоринг, антифрод‑движок Правила оспаривания —

Чек‑лист внедрения и типовые ошибки

Шаги к безопасному запуску:

  1. Выберите провайдера и банк‑эквайрер — смотрите сравнение и подключение интернет‑эквайринга.
  2. Определите модель интеграции (стремитесь к SAQ A). Для CMS — готовые модули: WooCommerce, 1C‑Битрикс, OpenCart, Tilda, CS‑Cart.
  3. Включите 3‑D Secure 2.0 и правила антифрода. Проверьте UX оплаты и обработку исключений. Подробнее — антифрод и чарджбеки.
  4. Настройте фискализацию: свяжите вебхуки оплаты с API кассы; протестируйте предоплату, отгрузку, возврат.
  5. Подготовьте пакет по 152‑ФЗ: политика, согласия, договоры поручения, реестр операций, назначение ответственного, локализация данных в РФ.
  6. Обеспечьте базовый периметр безопасности: HTTPS, обновления CMS/плагинов, резервное копирование, WAF/CDN, журналирование.
  7. Пройдите тесты в песочнице и приемку — смотрите API и Sandbox для разработчиков.
  8. Обучите поддержку: сценарии возвратов, споры, работа с чеками и ПДн‑запросами.

Частые ошибки: хранение «масок» и CVV у себя, устаревшие модули оплаты, отсутствие чека при предавторизации/капчуре, лишние персональные поля в формах, отсутствие публичной политики ПДн.

Частые вопросы

  • Нужен ли PCI DSS, если у нас редирект на платежную страницу? Как правило, достаточно SAQ A: вы подтверждаете выполнение организационных мер и не обрабатываете карточные данные у себя.
  • Обязательно ли включать 3DS? Закон этого не требует, но 3DS существенно снижает риск мошенничества и часто обязателен у эквайреров для определенных MCC/сумм.
  • Можно ли хранить данные карты для автоплатежей? Нет, у себя — нельзя. Используйте токены провайдера, а в оферте закрепите условия регулярных списаний (CIT/MIT).
  • Как фискализировать подписки? Чек на каждое списание. При отмене — чек «возврат прихода».
  • Что относится к ПДн в интернет‑магазине? Минимум: имя, телефон, e‑mail, адрес доставки. Придерживайтесь принципа минимизации и укажите цели обработки.

Полезные страницы

Вывод и следующий шаг

Свести воедино PCI DSS, 54‑ФЗ и 152‑ФЗ — реально: выбирайте интеграцию, где карточные данные не попадают на ваш сервер, подключайте 3DS 2.0, используйте токены и автоматизируйте фискализацию. Поддерживайте прозрачные процессы обработки ПДн и минимизацию данных.

Готовы настроить безопасный эквайринг с высокой конверсией? Оставьте заявку в разделе Подключить интернет‑эквайринг — поможем выбрать провайдера, спроектировать архитектуру и пройти соответствие быстрее.

Получить CloudPayments бесплатно