3-D Secure 2.0
Порядок обработки запросов при аутентификации по протоколу 3-D Secure 2.0 отличается от первой версии протокола 3-D Secure. Основной особенностью протокола 3-D Secure 2.0 и отличием от первой версии является возможность Frictionless аутентификации.
- Frictionless Flow — процесс 3-D Secure аутентификации без участия держателя карты. Для Покупателя процесс оплаты выглядит как платеж без 3DS, а для Продавца платеж остается защищенным 3-D Secure.
- Challenge Flow — процесс 3-D Secure аутентификации с проверкой держателя карты. Для Покупателя процесс проверки выглядит аналогично 3DS 1.0.
Решение о выполнении Frictionless или Challenge аутентификации принимает банк-эмитент на основе анализа параметров транзакции, в том числе информации о браузере Покупателя.
Параметры браузера собираются Продавцом и передаются перед выполнением платежа. Однако эмитент может запросить возможность самостоятельного сбора параметров браузера. Для этого в протоколе 3-D Secure 2.0 используется 3DS Method — открытие скрытого iframe в браузере Покупателя для сбора параметров браузера.
Предварительная аутентификация
Предварительная аутентификация выполняется для проверки версии протокола 3-D Secure и необходимости использования 3DS метода. Для предварительной аутентификации используется запрос api/PreAuth (Payture API) или vwapi/PreAuth (Payture eWallet). Описание методов доступно в документациях 3‑D Secure 2.0 на стороне Продавца и 3‑D Secure 2.0 на шаблоне.
Выполнение 3DS метода
Если в ответе PreAuth переданы параметры ThreeDSServerTransId, ThreeDSMethodURL и ThreeDSMethodNotificationURL, то необходимо выполнение 3DS метода — открытие скрытого iframe в браузере клиента, с помощью которого данные браузера автоматически передаются на сервер банка-эмитента.
В ином случае (если в ответе PreAuth отсутствуют параметры ThreeDSServerTransId, ThreeDSMethodURL и ThreeDSMethodNotificationURL или хотя бы один из этих параметров не имеет значения), открытие скрытого iframe не требуется — переходите к следующему шагу.
Примеры ответов методов apim/PreAuth (Payture API) и vwapi/PreAuth (Payture eWallet) описаны в документациях 3‑D Secure 2.0 на стороне Продавца и 3‑D Secure 2.0 на шаблоне.
Выполнение платежа (добавление карты)
Для оплаты или добавления карты используются следующие методы:
- На стороне продавца — api/Pay , api/Block , api/MobilePay , api/MobileBlock , vwapi/Pay — на стороне Продавца или vwapi/Add — на стороне Продавца
- На стороне Payture — apim/PaySubmit, vwapi/AddSubmit или vwapi/AddSubmit. Описание методов доступно в документации 3‑D Secure 2.0 на шаблоне
Если банк эмитент разрешил выполнение операции по сценарию Frictionless Flow, то платеж выполняется без проверки Покупателя. В ответе на запрос оплаты (добавления карты) передается «Success=True» и отсутствуют параметры 3DS, что говорит о выполненном списании или блокировании средств на карте Покупателя. Процесс оплаты завершен.
В случае, если необходима проверка Покупателя, операция проходит по сценарию Challenge Flow. Дальнейший порядок действий различается в зависимости от того, чья сторона обрабатывает карточные данные. Более подробная информация доступна в документациях 3‑D Secure 2.0 на стороне Продавца и 3‑D Secure 2.0 на шаблоне.
Проверка Покупателя (только для Challenge Flow)
В случае необходимости прохождения аутентификации Продавец перенаправляет Покупателя на страницу банка-эмитента. На странице банка-эмитента выполняется проверка Покупателя, обычно это ввод СМС-кода.
Для перенаправления используется POST запрос по адресу, указанному в параметре ACSUrl. Передаваемые параметры:
| Параметр | Описание |
|---|---|
| threeDSSessionData | Уникальный идентификатор транзакции Соответствует параметру ThreeDSSessionData из ответа на запрос Pay, Block, Add, MobilePay или MobileBlock |
| creq | Соответствует параметру CReq из ответа на запрос Pay, Block, Add, MobilePay или MobileBlock |
При выполнении операции на стороне Payture после выполнения проверки ACS перенаправляет Покупателя POST запросом на шаблон возврата Payture. А с шаблона возврата Покупатель возвращается на сайт Продавца (аналогично сценарию 3DS 1.0).
При выполнении операции на стороне продавца после выполнения проверки ACS возвращает Покупателя POST запросом по адресу, указанному в параметре ChallengeNotificationUrl. В запросе передаются следующие параметры:
| Параметр | Описание |
|---|---|
| threeDSSessionData | Уникальный идентификатор транзакции Соответствует переданному в запросе |
| cres | Base64 encoded строка, содержащая результаты 3-D Secure аутентификации |
Пример HTML формы
<html><head><title></title></head>
<body onload="setTimeout(document.forms['form'].submit(), 10000)">
<form name='form' action='{ACSUrl}' method='post'>
<input type='hidden' name='creq' value='{CReq}'>
<input type='hidden' name='threeDSSessionData' value='{ThreeDSSessionData}'>
</form>
</body></html>Завершение оплаты (только для Challenge Flow на стороне Продавца)
Для завершения списания или блокирования средств на карте, защищенной 3-D Secure, Продавцу необходимо передать в платежный шлюз результаты аутентификации, полученные от ACS.
Для интерфейса Payture API результаты передаются в запросе Pay3DS или Block3DS. Для Payture eWallet — в PaySubmit3DS или AddSubmit3DS. Описание методов доступно в документации 3‑D Secure 2.0 на стороне Продавца.
3-D Secure 1.0
В целях повышения безопасности платежей большинство банковских карт защищены механизмом аутентификации 3-D Secure.
Платежный виджет
Встраиваемое всплывающее окно для приема платежей на сайте Продавца. Включает защищенные поля ввода платежных данных и e-mail для отправки электронного чека по 54-ФЗ.
