Безопасность онлайн‑платежей: PCI DSS, 3‑D Secure 2, токенизация и антифрод

Безопасность онлайн‑платежей: PCI DSS, 3‑D Secure 2, токенизация и антифрод

Принятие банковских карт на сайте — это не только удобство для клиента, но и зона повышенной ответственности. В этой статье разберем практики, которые повышают безопасность онлайн‑платежей: от «PCI DSS для сайта» и 3‑D Secure 2.0 до токенизации карт, antifraud систем и защиты вебхуков. Материал будет полезен владельцам интернет‑магазинов, подписочных сервисов и SaaS‑проектов на CMS и кастомных стэках.

Зачем бизнесу системная безопасность платежей

Безопасность онлайн‑платежей — это сочетание регуляторных требований, технических мер и процессов. Цели:

• защитить данные держателей карт (PAN, срок, CVC/CVV);
• снизить фрод и chargeback‑расходы;
• повысить конверсию (меньше ложных отказов и трения);
• выполнить требования банков и международных платежных систем.

Типовые угрозы: фишинг и подмена страниц оплаты, подбор и прокрутка украденных карт, компрометация токенов, перехват/подмена вебхуков, повторная отправка платежей, XSS/CSRF на checkout‑странице, MITM без HSTS, утечки ключей. Ответ — многоуровневая защита.

PCI DSS для сайта: что это и как сократить скоуп

PCI DSS — стандарт безопасности индустрии платёжных карт. Для сайтов‑мерчантов он определяет, как обращаться с карточными данными.

Ключевые принципы:

• Не храните чувствительные карточные данные (полный PAN, CVC/CVV) без крайней необходимости. Для большинства проектов — вообще никогда. Используйте токенизацию и «вынесенный» ввод реквизитов.
• Сократите PCI‑скоуп с помощью Hosted Payment Page, Redirect‑флоу или Hosted Fields от провайдера. Тогда сайт не обрабатывает и не видит PAN — и вы переходите на менее сложные SAQ (например, SAQ A или A‑EP вместо D).
• Если у вас кастомный full‑API с вводом карты на стороне сайта, вам потребуется выполнение расширенных требований (сетевые сегментации, логирование, сканирования, тестирования), что дорого и трудозатратно.

SAQ и скоуп

• SAQ A: ввод карт полностью на стороне провайдера (редирект/хостед‑страница). Минимальные требования.
• SAQ A‑EP: ввод на вашей странице с встраиваемыми полями провайдера (Hosted Fields). Требования выше, но PAN не проходит через ваш сервер.
• SAQ D: на вашей стороне есть обработка/хранение карточных данных. Максимальный скоуп и ответственность.

Точка принятия решения — архитектура интеграции. Подробнее о вариантах подключения на странице «Подключение платежной системы к сайту».

Кто за что отвечает

Элемент защиты	Мерчант	Платёжный провайдер	Банк‑эмитент
Сегментация сети, патчи, сканирование	Да (в пределах сайта/инфраструктуры)	Да (в пределах своих систем)	—
Хранение карточных данных	Избегать, использовать токены	Да (при наличии PCI DSS Level 1)	—
3‑D Secure 2.0	Инициация, передача данных	Маршрутизация и протокол	Решение SCA, риск‑оценка
Antifraud	Настройки, правила бизнеса	Алгоритмы, ML‑модели	Мониторинг транзакций
Вебхуки	Проверка подписи, идемпотентность	Подпись/сертификаты	—

3‑D Secure 2.0 и SCA/PSD2: когда будет «фрикшнлесс»

3‑D Secure 2.0 — современный протокол аутентификации держателя карты. Он реализует требования SCA и PSD2 (для Европы) и снижает риск фрода во всем мире. Ключевая особенность 3DS2 — обмен расширенным набором контекстных данных (device, адрес, email, история) и «фрикшнлесс»‑флоу, когда банк одобряет платёж без дополнительного челенджа.

Различия 3DS1 vs 3DS2:

Критерий	3DS1	3DS2
UX	Часто редирект и дополнительные окна	Встроенный, нативный, SDK, web‑view
Данные для оценки риска	Ограниченные	Расширенный контекст (до сотен полей)
Фрикшнлесс	Редко	Часто при низком риске
Биометрия/Push	Нет	Да (через приложение банка)

SCA и PSD2 вводят обязательную сильную аутентификацию (двухфакторную) в EEA, но поддержка 3‑D Secure 2.0 полезна и вне Европы — эмитенты охотнее одобряют транзакции, а ответственность за фрод часто переносится на банк.

Советы для конверсии:

• Передавайте максимум корректных данных в 3DS‑реквесте (email, телефон, адрес, account_age, shipping_timeframe, merchant_risk_indicator) — это повышает шанс фрикшнлесс.
• Для повторных платежей используйте MIT‑сценарии (merchant‑initiated transactions) с ссылкой на первоначальную SCA.

Подбор методов оплаты и поведение 3DS зависят от провайдера. Сравните условия на странице «Сравнение провайдеров РФ» или изучите интеграции: YooKassa, CloudPayments, Тинькофф Касса.

Токенизация карт и хранение карточных данных

Токенизация карт — ключ к снижению рисков и к гибким сценариям оплаты.

Типы токенов:

• Provider tokens (Vault провайдера): провайдер хранит PAN, а мерчант получает безопасный токен. Это «золотой стандарт» для большинства сайтов.
• Network tokens (Visa VTS, Mastercard MDES): сетевые токены, часто устойчивее к утечкам, обновляются при перевыпуске карты.
• Device tokens (Apple Pay/Google Pay): токены на устройстве с криптограммой — чувствительные данные вообще не видит сайт.

Хранение карточных данных: что можно и нельзя

• Нельзя: хранить полный PAN и CVC/CVV без сертификации PCI DSS соответствующего уровня.
• Можно: хранить «последние 4», тип карты, срок действия, маскированный PAN, ID токена и профиль плательщика.
• Для подписок используйте токены и «one‑click». Подробнее в «Рекуррентные платежи и подписки».

Antifraud системы: правила, ML и метрики

Antifraud системы анализируют риск транзакции до авторизации и вместе с 3DS снижают фрод. Компоненты:

• Правила (rule‑engine): лимиты на сумму/час, проверки BIN/страны, стоп‑листы, velocity‑контроль.
• Машинное обучение: поведенческие профили, device fingerprint, графовые связи email‑телефон‑адрес.
• Обогащение: геолокация по IP, прокси/VPN‑сигналы, базы компрометированных аккаунтов.

Какие данные передавать провайдеру для лучшего скоринга:

• user_id, дата регистрации, подтверждение email/телефона;
• billing и shipping адреса, совпадение ФИО;
• история заказов, возвратов, chargeback‑статистика;
• характеристики товара (цифровой/физический, сроки доставки).

Основные метрики:

• Approval rate (доля успешных авторизаций);
• Chargeback rate (Visa/MC мониторинг обычно <0.9%);
• False positives (легитимные транзакции, ошибочно отклоненные);
• Доля фрикшнлесс 3DS и доля успешных челенджей.

Совет: согласуйте пороги риска с провайдером, включайте «soft decline retry» и тестируйте каскадную маршрутизацию методов оплаты. См. «Методы оплаты: карты и СБП».

Техническая гигиена: HTTPS/HSTS, защита вебхуков, CSP

Базовые меры напрямую влияют на доверие эмитента и клиента:

• HTTPS и HSTS: принудительный TLS 1.2+, включить HSTS (в идеале — preloading), отключить устаревшие шифры, настроить редиректы 301 с HTTP на HTTPS.
• CSP и защита встраиваемых SDK: Content‑Security‑Policy с разрешением доменов провайдера, SRI для скриптов, X‑Frame‑Options/Frame‑Ancestors на checkout‑странице.
• Cookies: Secure, HttpOnly, SameSite=Lax/Strict для сессий.
• Логи и мониторинг: аномалии, повторные попытки, резкие пики отказов 3DS.

Защита вебхуков:

• Подпись (HMAC) и верификация по секрету или mTLS; храните ключи в vault, обновляйте их по расписанию.
• Идемпотентность: обрабатывайте каждый event по idempotency‑ключу один раз.
• Ограничение источников: по доменам и подсетям провайдера; не полагайтесь только на IP‑списки.
• Быстрый 2xx‑ответ и асинхронная обработка, чтобы провайдер не ретраил лишний раз.

Потренируйтесь на тестовой среде: «Тестирование вебхуков и sandbox».

Архитектура интеграции: Redirect, Hosted Fields, API

Выбор архитектуры влияет и на UX, и на PCI‑скоуп.

Модель	UX	PCI‑скоуп	Когда выбрать
Redirect/Hosted Page	Надежный, минимальное внедрение	SAQ A	MVP, быстрый старт, высокий комплаенс
Hosted Fields (встраиваемые поля)	Бесшовный UI	SAQ A‑EP	Нужен единый дизайн без полного API
Full API (сбор карты у вас)	Полный контроль	SAQ D	Редко оправдан; только при сильной экспертизе и нужде

Посмотрите готовые инструкции для CMS: Tilda, WordPress/WooCommerce, 1C‑Bitrix, Shopify, Wix, Webflow, OpenCart/PrestaShop.

Рекуррентные платежи, MIT и SCA

Подписки и регулярные списания требуют особого внимания:

• Первичная оплата — Customer‑initiated (CIT) с 3‑D Secure 2.0 и сохранением токена.
• Последующие списания — Merchant‑initiated (MIT) по токену со ссылкой на первоначальную SCA. В зонах действия PSD2 такие списания обычно освобождаются от повторной SCA, если правильно проставлены индикаторы и reference.
• One‑click/покупка в один клик: используйте токен и CVC‑реплей только если это разрешает провайдер и нормы.

Разбор сценариев и Best Practices — на странице «Рекуррентные платежи и подписки».

Чеклист внедрения безопасности

• Выбран провайдер с PCI DSS Level 1 и поддержкой 3‑D Secure 2.0.
• Архитектура интеграции снижает PCI‑скоуп (Redirect/Hosted Fields).
• Включён HTTPS и HSTS; актуальный TLS 1.2/1.3, CSP, SRI, безопасные Cookies.
• Настроены antifraud правила и передача расширенных данных для скоринга.
• Включены SCA/3DS2; протестированы фрикшнлесс/челендж‑флоу.
• Токенизация включена; PAN/CSC не хранятся; храните только безопасные атрибуты.
• Вебхуки подписаны; реализована идемпотентность и ретраи.
• Логи и алерты настроены: пики отказов, рост chargeback.
• Проведено тестирование в sandbox и UAT.
• Организована фискализация по 54‑ФЗ при необходимости: «Онлайн‑касса и фискализация».

Выбор провайдера и модули для CMS

При выборе учитывайте: тарифы, поддержку СБП и альтернатив, зрелость antifraud, качество 3DS2, webhooks и техническую документацию. Сравните опции на странице «Сравнение провайдеров РФ» и посмотрите конкретные инструкции: YooKassa, CloudPayments, Тинькофф Касса. Для CMS изучите готовые модули: Tilda, WooCommerce, 1C‑Bitrix, Shopify, Wix, Webflow, OpenCart/PrestaShop. Обширный список методов — «Методы оплаты: карты и СБП».

Итоги и следующий шаг

Безопасность онлайн‑платежей — это не один инструмент, а слоёная архитектура: PCI DSS для сайта, 3‑D Secure 2.0 и SCA, токенизация карт, antifraud системы, плюс грамотная техническая гигиена (HTTPS и HSTS, защита вебхуков, строгие заголовки). Выберите модель интеграции, которая снижает PCI‑скоуп, и передавайте максимум корректных данных — так вы получите и меньше фрода, и выше конверсию.

Нужна помощь с выбором провайдера и безопасной интеграцией? Оставьте заявку — мы настроим платёжный поток, протестируем webhooks и выведем в прод. Начните с шага «Подключение платежной системы к сайту».