3-D Secure

Три домена и маршрут одного платежа

Название протокола расшифровывается буквально: three domains, три домена. Первый — домен эмитента, банка, выпустившего карту. Второй — домен эквайрера, банка, который обслуживает продавца. Третий — домен совместимости, инфраструктура платёжной системы, связывающая первые два. Протокол описывает, как эти три стороны обмениваются сообщениями, чтобы убедиться: карту в форме оплаты вводит её законный держатель, а не тот, кто переписал шестнадцать цифр с чужой квитанции.

В схеме участвуют три технических компонента. 3DS Server (в первой версии он назывался MPI, Merchant Plug-In) стоит на стороне продавца или платёжного шлюза и инициирует проверку. Directory Server платёжной системы по диапазону номера карты определяет, какой банк её выпустил, и поддерживает ли он аутентификацию. Access Control Server на стороне эмитента принимает решение: пропустить операцию молча или запросить подтверждение у клиента.

Порядок такой. Покупатель нажимает «оплатить», 3DS Server собирает данные об операции и устройстве и отправляет запрос в Directory Server. Тот маршрутизирует его в ACS нужного банка. ACS оценивает риск и отвечает либо «аутентификация пройдена без вопросов», либо «нужен вызов» — тогда клиент видит окно ввода одноразового кода или подтверждение в приложении банка. По итогу эмитент выпускает криптограмму подтверждения и индикатор электронной коммерции, которые прикладываются к авторизационному запросу. Только после этого начинается собственно списание денег: аутентификация и авторизация — разные шаги.

Юридическое следствие важнее технического: при успешно пройденной аутентификации ответственность за операцию, которую держатель позже оспорит как несанкционированную, по правилам платёжной системы смещается с продавца на эмитента. Именно из-за этого сдвига ответственности интернет-магазины подключают 3-D Secure, даже когда протокол добавляет шаг к оформлению заказа.

Что изменила версия 2.x

Первая версия протокола появилась на рубеже 2000-х и опиралась на статические пароли и всплывающие окна. Она плохо переносила мобильные приложения, ломала вёрстку на телефонах и отбирала у продавцов заметную долю конверсии: покупатель, увидев чужеродное окно, часто бросал корзину. Поддержка первой версии международными системами постепенно прекращена, и рынок перешёл на EMV 3-D Secure — спецификацию, которую ведёт консорциум EMVCo и которая развивается ветками 2.1, 2.2 и 2.3.

Главное содержательное изменение — риск-ориентированная аутентификация. Вместо десятка полей вторая версия передаёт эмитенту свыше сотни параметров: сведения об устройстве, история заказов в этом магазине, адрес доставки, способ доставки, поведение в сессии. Имея такой контекст, ACS в большинстве случаев принимает решение самостоятельно и не тревожит клиента — это и есть frictionless-сценарий, оплата без единого дополнительного экрана.

Второе — нативная поддержка приложений. В версии 2.x есть SDK, встраиваемый в мобильное приложение продавца, поэтому подтверждение показывается внутри интерфейса, а не в браузерном окне. Третье — двусторонний обмен: эмитент может передать продавцу причину отказа, а не просто вернуть ошибку. Четвёртое — отказ от статичных паролей в пользу одноразовых кодов и подтверждения биометрией в приложении банка.

В России протокол применяется в собственных реализациях платёжных систем: для карт «Мир» аутентификацию обеспечивает сервис Мир Accept, построенный на той же спецификации EMV 3-D Secure. Практическая часть для продавца описана в материале о платёжных ссылках: любая ссылка на оплату картой в итоге приводит покупателя на страницу эквайрера, где и отрабатывает 3DS.

Почему оплата по QR обходится без 3-D Secure

Протокол придуман для сценария, где карта не предъявлена физически, а её реквизиты вводятся в форму. У оплаты по QR-коду через СБП модель принципиально другая: покупатель инициирует перевод внутри своего банковского приложения, уже пройдя вход в него по PIN-коду или биометрии. Банк по определению знает, кто нажал кнопку, поэтому отдельный протокол подтверждения не нужен — аутентификация происходит на входе в приложение. Сравнение двух маршрутов разобрано в статье об оплате картой по QR и через СБП.

Из этого следует практический вывод для бизнеса. Подключая приём по QR-коду СБП, продавец получает платёж без шага 3DS и без связанного с ним отвала конверсии, но и без механики сдвига ответственности: спор по переводу разбирается по другим правилам, чем карточный чарджбэк. Как выстроить приём и что предусмотреть заранее, описано в инструкции по подключению QR-оплаты по СБП.

Отдельный риск лежит вне протокола. 3-D Secure защищает от использования украденных реквизитов, но бессилен, если клиент сам ввёл код на поддельной странице, куда попал по QR-коду с фальшивой наклейки. Такой сценарий разбирает материал о фишинге через QR-коды: код с наклейки на парковочном автомате ведёт на сайт-двойник, покупатель вводит карту, честно проходит аутентификацию и добровольно подтверждает списание в пользу мошенника. Никакой ACS такую операцию не отличит от нормальной.

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

Почему код подтверждения приходит не всегда?

Это штатное поведение второй версии протокола. ACS банка оценивает риск по переданному контексту: устройство, сумма, история операций в этом магазине, совпадение адресов. Если картина выглядит типичной для этого клиента, аутентификация проходит без запроса кода — frictionless-сценарий. Одноразовый код появляется тогда, когда модель видит отклонение от привычного профиля.

Кто отвечает за деньги, если платёж прошёл с 3-D Secure?

При успешной аутентификации ответственность за операцию, оспоренную держателем как несанкционированную, по правилам платёжной системы переходит к банку-эмитенту. Если магазин 3DS не подключил, спор в общем случае разбирается за его счёт. Конкретные условия и исключения прописаны в правилах платёжной системы и в договоре эквайринга.

Замедляет ли 3-D Secure оплату?

Первая версия добавляла к оформлению заказа отдельную страницу с ожиданием и вводом пароля, и это заметно било по конверсии. Вторая версия чаще отрабатывает незаметно: обмен сообщениями занимает доли секунды и происходит фоном. Ощутимая пауза остаётся только в сценарии с вызовом, когда клиенту действительно нужно ввести код или подтвердить операцию в приложении.

Можно ли отключить 3-D Secure для своего магазина?

Технически эквайрер может настроить приём операций без аутентификации, но экономически это почти всегда невыгодно: продавец берёт на себя риск по спорным транзакциям, а тариф на такие операции обычно выше. Для подписок и повторных списаний используют отдельные механики с первичной аутентификацией и последующими платежами по сохранённому идентификатору.

Защищает ли протокол от утечки номера карты?

Нет, это не его задача. 3-D Secure подтверждает личность в момент платежа, но не скрывает реквизиты от продавца. За сокрытие номера отвечают другие механизмы — токенизация и платёжные сервисы, где вместо карты магазину передаётся её цифровой заменитель, привязанный к устройству или к конкретному получателю.