Безопасность онлайн‑платежей: PCI DSS, 3‑D Secure 2, токенизация и антифрод
Принятие банковских карт на сайте — это не только удобство для клиента, но и зона повышенной ответственности. В этой статье разберем практики, которые повышают безопасность онлайн‑платежей: от «PCI DSS для сайта» и 3‑D Secure 2.0 до токенизации карт, antifraud систем и защиты вебхуков. Материал будет полезен владельцам интернет‑магазинов, подписочных сервисов и SaaS‑проектов на CMS и кастомных стэках.
Table of contents
- Зачем бизнесу системная безопасность платежей
- PCI DSS для сайта: что это и как сократить скоуп
- 3‑D Secure 2.0 и SCA/PSD2: когда будет «фрикшнлесс»
- Токенизация карт и хранение карточных данных
- Antifraud системы: правила, ML и метрики
- Техническая гигиена: HTTPS/HSTS, защита вебхуков, CSP
- Архитектура интеграции: Redirect, Hosted Fields, API
- Рекуррентные платежи, MIT и SCA
- Чеклист внедрения безопасности
- Выбор провайдера и модули для 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 и выведем в прод. Начните с шага «Подключение платежной системы к сайту».