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

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

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

Безопасность онлайн оплат на сайте — это не только про технические стандарты. Это про доверие к бренду, конверсию и юридическую ответственность. Прорыв данных карт, фрод‑транзакции или чарджбеки бьют по выручке, рейтингу банка‑эквайера и репутации. Современный стек включает несколько слоёв: стандарт PCI DSS для сайта, сильную клиентскую аутентификацию (3‑D Secure 2, SCA), шифрование и антифрод‑системы с fraud scoring. Ни один компонент не работает в одиночку: безопасность — это комплекс мер на стороне сайта, провайдера и банков.

Полезно начать с общей схемы интеграции оплаты и требований. Подробный гид по запуску — в материале «Как подключить онлайн‑оплату на сайт».

PCI DSS для сайта: что это и кто за что отвечает

PCI DSS — международный стандарт защиты данных держателей карт (PAN, срок, имя, CVC/CVV). Его цель — минимизировать риски компрометации. Важно понимать зону ответственности: даже если вы пользуетесь провайдером эквайринга, часть мер остаётся на вашей стороне (настройка сервера, управление доступами, безопасная разработка).

Ниже — упрощённое сравнение вариантов интеграции и влияния на PCI DSS‑обязанности.

Вариант интеграции	Охват PCI DSS у мерчанта	Тип SAQ (примерно)	Где вводятся данные карты	Плюсы	Минусы
Редирект на хост‑страницу провайдера	Минимальный	SAQ A	На стороне провайдера	Быстрый старт, низкие риски	Меньше контроля над UX
Встраиваемый виджет / iFrame / Hosted Fields	Низкий–средний (зависит от реализации)	SAQ A или A‑EP	В iFrame провайдера	Лучший UX, не касаетесь PAN	Требует корректной реализации JS/iFrame
Прямая форма на сайте + API	Максимальный	SAQ D	На вашем домене	Полный контроль UX	Высокие требования, аудит, расходы

Примечание: точный тип SAQ определяется архитектурой. Согласуйте с вашим провайдером/PCI QSA.

Что остаётся на вашей стороне при любом варианте:

• Безопасная конфигурация сервера и CI/CD, контроль доступа и логирование.
• Шифрование трафика (TLS 1.2+), политика паролей и MFA для админов.
• Регулярные обновления CMS/плагинов, устранение уязвимостей (OWASP Top‑10).
• Процедуры реагирования на инциденты и резервное копирование.

Подробнее о банках‑эквайерах и их ролях — в статье «Эквайринг: оплата банковскими картами».

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

Главное правило PCI DSS: никогда не храните PAN и CVC/CVV у себя в открытом виде. Даже хэширование CVC запрещено. Если вам нужны «сохранённые карты» для подписок и автосписаний, используйте токенизацию у провайдера — вы храните только токен, не карточные реквизиты. Это резко сужает PCI‑скоуп и упрощает соответствие.

• Рекуррентные платежи: используйте провайдерский vault и токены. Подробнее — «Рекуррентные платежи и подписки».
• Миграция токенов при смене провайдера возможна, но требует согласования с банками и соблюдения безопасности.
• Период хранения биллинговых данных мерчанта (не карт) ограничивайте разумно; внедрите политику удаления.

Шифрование и защита соединений (TLS, HSTS, CSP)

Шифрование — базовый слой, без которого не работает никакая безопасность.

Рекомендации:

• Принудительно используйте TLS 1.2+ (лучше TLS 1.3), отключите устаревшие шифры.
• Включите HSTS и безопасные флаги для cookie (Secure, HttpOnly, SameSite=Lax/Strict).
• Настройте Content Security Policy, запретите inline‑скрипты, ограничьте источники.
• Используйте подпись и валидацию вебхуков (секрет/подпись, проверка IP). См. «Sandbox, тестирование и вебхуки».
• Применяйте WAF и rate limiting к платёжным эндпоинтам.

3‑D Secure 2 и SCA: меньше трения — больше одобрений

3‑D Secure 2 — современный протокол аутентификации держателя карты. Он снижает трение (frictionless flow), используя risk‑based подход и обмен расширенным набором атрибутов (девайс, адрес, история). В ЕС действует принцип Strong Customer Authentication (SCA), в РФ банки также широко применяют риск‑ориентированную аутентификацию с 3‑D Secure 2.

Характеристика	3‑D Secure 1.0	3‑D Secure 2.0
Каналы	Веб	Веб + мобильные SDK
UX	Часто всплывающие окна/редиректы	Встроенная аутентификация, лучше UX
Frictionless	Нет	Да, при низком риске
Данные для оценки	Ограниченные	Расширенные (device, адрес, поведенческие)
SCA/биометрия	Ограниченно	Поддерживается
Ответственность (liability shift)	Есть при успешной аутентификации	В большинстве случаев также действует

Как влияет на конверсию:

• При корректной передаче параметров (email, телефон, адрес, индикаторы доставки/цифрового товара) растёт доля frictionless‑одобрений.
• Для повторных покупок помогает токенизация в сочетании с 3DS‑exemption у эмитента (если применимо правила банка/региона).

Подробнее об Apple Pay / Google Pay и QR‑платежах СБП — «Apple Pay, Google Pay, SBP QR». Для СБП 3DS не требуется, но антифрод‑контроль нужен.

Антифрод и fraud scoring: какие правила настроить

Антифрод — это набор правил и скорингов, который выявляет подозрительные транзакции до авторизации банка. В идеале он риск‑ориентированный: низкорисковые платежи идут без лишних запросов, рискованные — усиливаются 3DS/челленджем или отклоняются.

Типовые правила:

Правило	Порог/пример	Назначение
Velocity по карте/почте/телефону	≤3 попыток/15 минут	Защита от перебора и проб биллинга
Несоответствие страны IP и BIN	Разные регионы	Выявление прокси/подмены гео
BIN‑листы (дебет/кредит/препейд)	Ограничивать риск‑пулы	Контроль категорий карт
Сумма/валюта	> средних чеков	Отсечение аномалий
Первые транзакции клиента	Усиленный 3DS	Нулевой трек‑рекорд — выше риск
Чёрные/белые списки	По email/телефону/карте	Локальные знания мерчанта
Повторные возвраты	Снижение лимитов	Борьба с абьюзом возвратов

Советы по настройке:

• Начните с мягких правил: метки и ручная проверка. Затем постепенно включайте автодеклайн на высокие риски.
• Передавайте максимум контекста в антифрод: SKU/категория, доставка/самовывоз, цифровой товар, время до выдачи.
• Для «дорогих» товаров — обязательный 3DS Challenge и подтверждение личности при доставке.

Как снизить чарджбеки и спорные списания

Даже с 3DS2 чарджбеки возможны (неузнанная транзакция, неоказанная услуга, мошенничество). Полезные практики:

• Понятный descriptor в выписке, совпадающий с брендом и телефоном поддержки.
• 3DS2 для риск‑покупок; храните логи аутентификации для споров.
• Подтверждение доставки (трек‑номер, подпись получателя, фото‑подтверждение).
• Прозрачные правила возврата средств; быстрый частичный/полный возврат при конфликте. Подробнее — «Возвраты и chargeback».
• Для подписок — явное согласие, напоминания перед списанием, лёгкая отмена.
• Для фискализации — корректные чеки по 54‑ФЗ: «Онлайн‑касса для сайта».

Compliance чек‑лист владельца сайта

• Выберите модель интеграции, минимизирующую PCI‑скоуп (редирект/виджет). Подбор провайдера — «Выбор платёжного провайдера».
• Включите TLS 1.2+, HSTS, CSP; обновите зависимости и плагины.
• Разделите роли и доступы, включите MFA для админов и менеджеров возвратов.
• Настройте антифрод и 3DS‑политику (когда требовать челлендж).
• Проведите тесты в песочнице, подпишите вебхуки — «Sandbox и вебхуки».
• Документируйте процессы инцидент‑респонса и резервного копирования.
• Проведите сканирование уязвимостей; при SAQ D — планируйте аудит PCI QSA.

Особенности для WordPress, 1C‑Битрикс и Tilda

• WordPress + WooCommerce: выбирайте плагины с Hosted Fields/Redirect, регулярно обновляйте ядро и темы. См. «WordPress/WooCommerce: оплата».
• 1C‑Битрикс: включите проактивную защиту, следите за модулем безопасности и журналами. Подробности — «1C‑Битрикс: оплата».
• Tilda: используйте официальные виджеты провайдера/эквайера, избегайте кастомных форм для карт. См. «Tilda: оплата».

Во всех случаях — минимизируйте собственную обработку карточных данных, отдайте ввод реквизитов провайдеру.

Эквайринг, SBP и альтернативные способы оплаты

Не ограничивайтесь картами: диверсификация снижает риски фрода и повышает конверсию.

• Банковские карты: «Эквайринг: оплата банковскими картами». Отдельно про банки — «Сбербанк‑эквайринг», «Тинькофф‑эквайринг».
• СБП и QR: мгновенные платежи, без PCI‑обязательств, но с антифрод‑контролями — «СБП: оплата для сайта».
• Кошельки/Pay: упрощённый UX и сильная аутентификация — «Apple Pay, Google Pay, SBP QR».
• Счета и платёжные ссылки: безопасная альтернатива для B2B/CS‑каналов — «Платёжные ссылки и счета».

Сравнение комиссий и затрат — «Тарифы и комиссии эквайринг».

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

• Нужен ли PCI DSS, если я использую редирект? — Да, но в упрощённой форме (обычно SAQ A). Ваш сервер, процессы и доступы всё равно должны быть защищены.
• 3‑D Secure 2 гарантирует отсутствие чарджбеков? — Нет. Но при успешной аутентификации ответственность часто переносится на банк‑эмитент; сохраняйте доказательства.
• Можно ли хранить данные карты «для удобства»? — Только в виде токена у провайдера. CVC хранить нельзя никогда.
• Как совместить SCA и высокую конверсию? — Передавайте максимум данных для risk‑based оценки, используйте токены и разумные антифрод‑исключения.
• А если я принимаю только СБП? — Требования PCI DSS к вам не применяются, но серверная безопасность, вебхуки, антифрод и 54‑ФЗ остаются важными.

Итоги и что делать дальше

Надёжная безопасность онлайн‑оплат — это совокупность мер: корректная архитектура интеграции (минимальный PCI‑скоуп), сильная аутентификация (3‑D Secure 2 и SCA), грамотно настроенный антифрод и базовая гигиена инфраструктуры (TLS, HSTS, CSP, WAF). Такой подход повышает доверие, сокращает фрод и чарджбеки и стабилизирует конверсию.

Готовы настроить безопасные платежи? Начните с пошаговой инструкции «Как подключить онлайн‑оплату на сайт», протестируйте интеграцию в «песочнице» и выберите оптимальные «тарифы эквайринга». Если нужен совет по выбору провайдера и стратегии защиты — загляните в «Выбор платёжного провайдера» и свяжитесь с нами.