Аутентификация 3‑D Secure 1
Общая информация
Аутентификация пользователя с использованием протокола 3‑D Secure (Three-Domain Secure) предназначена для безопасного проведения интернет-оплат с использованием платёжных карт. Она может выполняться с применением различных методов проверки подлинности пользователя, наиболее распространённым из которых является использование одноразовых проверочных кодов (One Time PIN, OTP). Как правило, пользователь получает такие коды в SMS-сообщениях, а затем вводит их на странице аутентификации.
В аутентификации 3‑D Secure используются три домена:
- Домен эквайера. В рамках работы с платёжной платформой ecommpay к нему относятся веб-сервис мерчанта, платёжная платформа и связанный с ней сервер Merchant Plug-In (или сервер MPI), а также сервис провайдера, если он участвует в аутентификации.
- Домен совместимости. К нему относятся серверы каталогов (Directory Servers, DS) международных платёжных систем.
- Домен эмитента. К нему относятся серверы управления доступом (Access Control Servers, ACS) эмитента.
Между этими доменами осуществляется обмен сообщениями, необходимыми для аутентификации пользователя. В первой версии протокола 3‑D Secure — 3‑D Secure 1 — к таким сообщениям относятся запрос на проверку возможности проведения аутентификации (Verifying Enrolment Request, VEReq) и ответ на него (Verifying Enrolment Response, VERes), а также запрос на аутентификацию пользователя (Payer Authentication Request, PAReq) и ответ с данными о результате аутентификации (Payer Authentication Response, PARes).
Следует учитывать, что информация о возможности проведения аутентификации пользователя хранится на сервере управления доступом, и следовательно эту информацию можно получить только после отправки запроса на проведение платежа. Также платёжная платформа не располагает информацией о действиях пользователей на странице аутентификации, а только получает результат прохождения аутентификации.
Со стороны веб-сервиса для аутентификации 3‑D Secure 1 необходимо:
- принять оповещение (или несколько оповещений в рамках одного платежа) о необходимости аутентификации 3‑D Secure 1;
- отреагировать на это оповещение;
- перенаправить пользователя на страницу аутентификации с отправкой запроса на аутентификацию (PAReq);
- если это необходимо, принять данные о результате аутентификации (PARes) и отправить эти данные в платёжную платформу.
Более подробные сведения о работе с аутентификацией 3‑D Secure 1 представлены далее.
Схема работы
Аутентификация пользователя с использованием протокола 3‑D Secure 1 может выполняться при проведении одностадийных и двухстадийных оплат с применением платёжных карт, а также при проверках действительности платёжных карт.
Информирование о необходимости аутентификации 3‑D Secure 1 осуществляется через оповещения, при приёме которых, как обычно при работе с платёжной платформой, необходимо отправлять ответы. В этих оповещениях передаются данные для перенаправления пользователя. В зависимости от способа проведения платежа и технических особенностей платёжных систем и провайдеров, участвующих в проведении платежа, состав этих данных может варьироваться и может потребоваться один из двух вариантов реагирования:
- Если оповещение содержит объект
acs
, необходимо: перенаправить пользователя на страницу аутентификации (ACS URL) эмитента с использованием данных из оповещения, принять данные о результате аутентификации от эмитента и отправить эти данные в запросе на продолжение платежа. Время ожидания такого запроса составляет, как правило, 30 минут и измеряется с момента выявления необходимости аутентификации и до получения запроса от веб-сервиса. Если время ожидания истекло и запрос не принят — платёж автоматически отклоняется. - Если оповещение содержит объект
redirectData
, необходимо перенаправить пользователя на страницу провайдера. Дальнейших действий со стороны веб-сервиса в этом случае не требуется. Информацию о ситуациях, при которых может понадобиться этот способ реагирования, можно получить у курирующего менеджера ecommpay.
После того как в платёжную платформу поступают данные о результате аутентификации, проведение платежа продолжается дальше. После этого дополнительно может понадобиться принять одно или несколько дополнительных оповещений о необходимости аутентификации 3‑D Secure 1. Если такое оповещение содержит параметр cascading_with_redirect
со значением true
, необходимо:
- Отобразить пользователю страницу с сообщением об ошибке и получить его согласие на повторное проведение аутентификации.
- Отреагировать одним из двух вариантов в зависимости от состава данных оповещения.
Информацию о таких дополнительных оповещениях можно получить у службы технической поддержки support@ecommpay.com.
Рис.: Выполнение аутентификации 3‑D Secure 1 по базовой схеме
- В платёжной платформе выполняется обработка запроса и выявляется необходимость аутентификации 3‑D Secure 1.
- От платёжной платформы к серверу MPI передаётся запрос на проверку возможности аутентификации.
- Запрос передаётся от сервера MPI к серверу каталогов (DS).
- Запрос передаётся от сервера каталогов к серверу управления доступом (ACS).
- На стороне сервера управления доступом выполняется проверка возможности аутентификации.
- От сервера управления доступом к серверу каталогов передаётся уведомление о возможности аутентификации.
- От сервера каталогов к серверу MPI передаётся уведомление с данными для перенаправления пользователя.
- Уведомление передаётся от сервера MPI к платёжной платформе.
- От платёжной платформы к веб-сервису направляется оповещение с данными для перенаправления пользователя.
- От веб-сервиса к платёжной платформе направляется ответ о приёме данных.
- Выполняется перенаправление пользователя на страницу аутентификации (ACS URL) эмитента.
- Пользователю отображается страница аутентификации и он осуществляет требуемые действия.
- На стороне эмитента выполняется аутентификация пользователя.
- Выполняется перенаправление пользователя к веб-сервису с передачей данных о результате аутентификации.
- Пользователю отображается страница ожидания веб-сервиса.
- От веб-сервиса на заданный URL ecommpay передаётся запрос на продолжение проведения платежа с учётом результата аутентификации.
- Запрос на продолжение проведения платежа поступает в платёжную платформу.
- В платёжной платформе выполняется приём запроса с проверкой его корректности.
- От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности.
Рис.: Выполнение аутентификации 3‑D Secure 1 по схеме с участием сервиса провайдера
- На стороне провайдера выполняется обработка платежа.
- От провайдера к платёжной платформе направляется уведомление с данными для перенаправления пользователя.
- От платёжной платформы к веб-сервису направляется оповещение с данными для перенаправления пользователя.
- От веб-сервиса к платёжной платформе направляется ответ о приёме данных.
- Выполняется перенаправление пользователя на страницу аутентификации (ACS URL) эмитента через сервис провайдера.
- Пользователь переходит на страницу аутентификации и осуществляет требуемые действия.
- На стороне эмитента выполняется аутентификация пользователя.
- Выполняется перенаправление пользователя к веб-сервису.
- Пользователь переходит к веб-сервису.
Информация о форматах запросов и оповещений приведена далее; общая информация о работе с API — в разделе Организация взаимодействия.
Формат оповещения с данными для перенаправления
Для передачи данных для перенаправления используются оповещения стандартного формата, описание которого представлено в разделе Оповещения. Данные для перенаправления пользователя передаются в одном из объектов такого оповещения: acs
или redirectData
.
В объекте acs
оповещения передаются следующие данные: сообщение PAReq (в параметре pa_req
) для направления запроса на прохождение аутентификации 3‑D Secure 1 эмитенту, адрес страницы аутентификации (acs_url
) и данные мерчанта в платёжной системе — Merchant Data (md
).
Рис.: Пример набора данных для перенаправления в объекте acs
"acs":{ "pa_req":"eJxVUtluwyAQ/BUrH2DA...n8/4htjT7Em", // Сообщение PAReq "acs_url":"https://example.com/ACS", // Адрес страницы аутентификации "md":"eyJfto7jg456ZCI6IiJ9" // Данные мерчанта в платёжной системе }
В объекте redirectData
оповещения передаются следующие данные: тело запроса (body
), метод отправки запроса (method
) и адрес провайдера (url
).
Рис.: Пример набора данных для перенаправления в объекте redirectData
"redirectData":{ "method":"GET", // Метод отправки запроса "body":[ ], // Тело запроса (может быть пустым) "encrypted": [ ], "url":"https://example.com/..." }
Формат запроса на перенаправление
Для перенаправления пользователя на страницу аутентификации или страницу провайдера необходимо направить запрос на адрес, полученный в оповещении с данными для перенаправления. В зависимости от состава данных для перенаправления это может быть POST-запрос или GET-запрос, в котором должны использоваться следующие объекты и параметры:
- Если данные получены в объекте
acs
:action
— адрес страницы аутентификации, полученный в параметреacs_url
оповещения;PaReq
— сообщение PAReq, полученное в параметреpa_req
оповещения;TermUrl
— адрес для перенаправления пользователя к веб-сервису после аутентификации;MD
— данные мерчанта в международной платёжной системе (Merchant Data), полученные в параметреmd
оповещения.
Метод отправки запроса — POST.
- Если данные получены в объекте
redirectData
:action
— адрес провайдера, полученный в параметреurl
оповещения;method
— метод отправки запроса, полученный в параметреmethod
оповещения;body
— тело запроса, если оно получено в оповещении.
Рис.: Пример HTML-формы с данными из объекта acs
<form id="3dsform" action="https://example.com/ACS" method="post" enctype="application/ x-www-form-urlencoded"> <input type="hidden" name="PaReq" value="eJxVUtluwyAQ/BUrH2DA...n8/4htjT7Em" /> <input type="hidden" name="TermUrl" value="http://example.com/termurl" /> <input type="hidden" name="MD" value="eyJfto7jg456ZCI6IiJ9" /> </form> <script type="text/javascript"> setTimeout(function() { document.getElementById("3dsform").submit(); }, 1000); </script>
Для удобства можно воспользоваться готовым примером — Пример HTML-формы, — заменив параметры на актуальные для платежа.
Формат запроса на продолжение проведения платежа
Для продолжения проведения платежа с учётом результата аутентификации необходимо отправить в платёжную платформу POST-запрос к конечной точке /v2/payment/card/3ds_result. В этом запросе должны использоваться следующие объекты и параметры:
general
— объект, содержащий основные идентификационные сведения запроса:project_id
— идентификатор проекта, полученный от ecommpay при интеграции;payment_id
— идентификатор платежа, уникальный в рамках проекта;signature
— подпись запроса, составленная после указания целевых параметров (подробнее — в разделе Работа с подписью к данным);
pares
— данные о результате аутентификации, полученные от эмитента.
Таким образом, корректный запрос на продолжение проведения платежа по итогам аутентификации 3‑D Secure 1 должен содержать идентификаторы проекта и платежа, подпись и данные о результате аутентификации.
Рис.: Пример набора данных в запросе на продолжение проведения платежа
{ "general": { "project_id": 42, "payment_id": "456789", "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" }, "pares": "eJzVWdfvq8iy/iujOY/WDBnbI+9ldZMMJpho4I1...Dfn76en3N+f/A1fJrSU=" }