3‑D Secure (3DS): как работает аутентификация и почему проходят ошибки платежей

Почему это важно

3‑D Secure (в особенности 3DS2) — основной технический способ проверки эмитентом клиента в онлайн‑транзакциях без физической карты; основные причины сбоев — ошибки интеграции, проблемы устройства/интерфейса, политика эмитента, обработка шлюзом или региональные правила SCA, для каждой проблемы есть практические пути решения.

Что такое 3‑D Secure и какие версии используются

3‑D Secure — протокол, позволяющий интегрировать проверку эмитентом (ACS) в процесс онлайн‑оплаты, чтобы эмитент мог оценить риск или запросить подтверждение перед авторизацией транзакции. Современные внедрения используют EMV® 3‑D Secure (v2.x).

EMVCo выпускает версии v2.x; рекомендуется применять v2.2 или новее. Обновления (например v2.3 — WebAuthn/FIDO) уточняйте на портале EMVCo.

• 3DS связывает запрос аутентификации продавца с ACS эмитента для оценки риска.
• Рекомендуется EMVCo v2.x (v2.2+ для улучшенной функциональности).

Как работает типичный 3DS2‑поток

Продавец отправляет AReq с данными транзакции и устройства в директорию схемы и ACS эмитента. Эмитент либо принимает транзакцию без вызова (‘frictionless’), либо инициирует challenge (SMS‑OTP, push, WebAuthn).

ACS возвращает ARes, после чего продавец продолжает авторизацию через эквайрера и сеть карт. 3DS2 поддерживает более подробные данные и нативные SDK для мобильных приложений, что уменьшает количество ненужных вызовов.

• AReq → ACS → frictionless или challenge → ARes → авторизация.
• 3DS2 поддерживает WebAuthn и нативные SDK для улучшения UX.

Основные причины сбоев аутентификации

Типичные причины: неполные или отсутствующие поля 3DS в AReq (ошибки интеграции), проблемы клиента (блокировка iframe, смена приложения), политика банка‑эмитента и неполная поддержка 3DS2, уязвимости и неудобство OTP через SMS, а также ошибки шлюза или неверная обработка кодов аутентификации.

Диагностика включает проверку AReq на обязательные поля, тестирование SDK в реальных условиях (нативный vs web), анализ кодов отказа от эмитента и проверку маппинга результатов 3DS в платежной цепочке.

• Неполный AReq → фолбек или отклонение; проверьте обязательные поля.
• Блокировка iframe/смена приложения → таймауты; применяйте нативные SDK.
• OTP (SMS) уязвим к SIM swap; поддерживайте WebAuthn/пуш, где возможно.
• Шлюз может терять результат аутентификации — тестируйте и логируйте.

Практические меры по снижению отказов

Убедитесь, что вы используете одобренный EMVCo 3DS2 SDK, отправляете полный набор данных в AReq и тестируете сценарии в sandbox вашего PSP. Это увеличит шанс, что эмитент примет решение без challenge.

Улучшите UX во время challenge: предупредите пользователей не переключаться из браузера/приложения, настройте разумные таймауты и предлагайте альтернативные способы оплаты при неудаче аутентификации.

• Проверить, что SDK присутствует в списке одобренных продуктов EMVCo.
• Отправлять полные device/transaction поля в AReq.
• Тестировать с официальными тест‑картами в sandbox.
• Реализовать понятные сообщения и запасные способы оплаты.

Что проверить

• Установить и проверить EMVCo‑одобренный 3DS2 SDK.
• Отправлять полный AReq (данные устройства и контекст транзакции).
• Тестировать флоу в sandbox PSP с тестовыми картами.
• Обеспечить пользовательский UX при challenge и альтернативные методы оплаты.