Что делает 3-D Secure
3-D Secure - это слой аутентификации card-not-present платежа между merchant, issuer и платежной инфраструктурой.
EMVCo описывает EMV 3-D Secure как технологию для аутентификации потребителя и повышения безопасности card-not-present платежей. Для бизнеса это означает, что часть платежей может потребовать дополнительного подтверждения у банка-эмитента.
По открытым страницам банков Армении 3D Secure прямо упоминается в vPOS-сценариях. Например, Evocabank описывает V-POS как решение для сайта и мобильного приложения с включенной 3D Secure системой. Поэтому при проектировании checkout нужно считать 3-D Secure штатным элементом, а не исключением.
- платеж может перейти в шаг дополнительной аутентификации;
- клиент может не завершить шаг у банка;
- финальный статус может прийти позже через callback или webhook;
- mobile browser и in-app flow нужно тестировать отдельно.
Как 3-D Secure влияет на UX
Проблемы обычно возникают не из-за самой аутентификации, а из-за плохого возвращения клиента в checkout.
Если пользователь проходит подтверждение в банковском окне или приложении, сайт должен корректно обработать все варианты: успех, отказ, закрытие вкладки, timeout, повторный переход по success URL и задержку финального статуса.
Главное правило: UX может сказать "мы проверяем платеж", но не должен выдавать товар или услугу до server-side подтверждения. Это особенно важно для цифровых товаров, бронирований, CRM-счетов и заказов с автоматической доставкой.
- success page показывает понятное ожидание, если статус еще pending;
- fail page предлагает безопасный retry без дубля заказа;
- mobile flow проверяется в Safari, Chrome и in-app browser;
- поддержка видит provider reference и последнюю проверку.
Какие тесты обязательны перед запуском
Проверять нужно не только успешную карту, но и сценарии отказа, закрытия окна и повторной доставки события.
Перед запуском команда должна пройти тест-кейсы: успешная оплата, отказ банка, незавершенная аутентификация, повторный refresh success page, закрытие вкладки, задержанный callback и повторный webhook.
Если какой-то сценарий не описан, он все равно случится на production. Разница только в том, увидит ли бизнес понятный pending/manual review или получит ручной конфликт между клиентом, менеджером и бухгалтерией.
- проверить все return URLs и webhook endpoint;
- убедиться, что raw frontend result не закрывает заказ;
- сохранить provider reference для поддержки;
- описать текст клиенту для pending и failed cases.
FAQ
3-D Secure гарантирует успешную оплату?
Нет. 3-D Secure помогает аутентифицировать клиента, но платеж все равно может завершиться отказом, timeout или pending-статусом. Финальный результат нужно проверять server-side.
Нужно ли делать отдельный UX для 3-D Secure?
Да. Клиент должен понимать, что происходит после банковского подтверждения, что делать при pending и как безопасно повторить попытку без дубля заказа.
Можно ли отключить 3-D Secure ради конверсии?
Это зависит от банка, провайдера, правил платежной схемы и риска операции. Для сайта правильнее проектировать хороший 3DS flow, чем рассчитывать на его отсутствие.
Источники
- EMVCo - EMV 3-D SecureОфициальное описание EMV 3-D Secure как технологии для card-not-present аутентификации.
- Evocabank - V-POS terminalОфициальная страница V-POS, где указаны сайт, мобильное приложение и 3D Secure.
- Stripe Documentation - PaymentIntents lifecycleПример модели статусов, где дополнительное действие клиента является частью платежного lifecycle.
