Аутентификация 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 Secure3‑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 по базовой схеме

  1. В платёжной платформе выполняется обработка запроса и выявляется необходимость аутентификации 3‑D Secure 1.
  2. От платёжной платформы к серверу MPI передаётся запрос на проверку возможности аутентификации.
  3. Запрос передаётся от сервера MPI к серверу каталогов (DS).
  4. Запрос передаётся от сервера каталогов к серверу управления доступом (ACS).
  5. На стороне сервера управления доступом выполняется проверка возможности аутентификации.
  6. От сервера управления доступом к серверу каталогов передаётся уведомление о возможности аутентификации.
  7. От сервера каталогов к серверу MPI передаётся уведомление с данными для перенаправления пользователя.
  8. Уведомление передаётся от сервера MPI к платёжной платформе.
  9. От платёжной платформы к веб-сервису направляется оповещение с данными для перенаправления пользователя.
  10. От веб-сервиса к платёжной платформе направляется ответ о приёме данных.
  11. Выполняется перенаправление пользователя на страницу аутентификации (ACS URL) эмитента.
  12. Пользователю отображается страница аутентификации и он осуществляет требуемые действия.
  13. На стороне эмитента выполняется аутентификация пользователя.
  14. Выполняется перенаправление пользователя к веб-сервису с передачей данных о результате аутентификации.
  15. Пользователю отображается страница ожидания веб-сервиса.
  16. От веб-сервиса на заданный URL ECommPay передаётся запрос на продолжение проведения платежа с учётом результата аутентификации.
  17. Запрос на продолжение проведения платежа поступает в платёжную платформу.
  18. В платёжной платформе выполняется приём запроса с проверкой его корректности.
  19. От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности.

Рис.: Выполнение аутентификации 3‑D Secure 1 по схеме с участием сервиса провайдера

  1. На стороне провайдера выполняется обработка платежа.
  2. От провайдера к платёжной платформе направляется уведомление с данными для перенаправления пользователя.
  3. От платёжной платформы к веб-сервису направляется оповещение с данными для перенаправления пользователя.
  4. От веб-сервиса к платёжной платформе направляется ответ о приёме данных.
  5. Выполняется перенаправление пользователя на страницу аутентификации (ACS URL) эмитента через сервис провайдера.
  6. Пользователь переходит на страницу аутентификации и осуществляет требуемые действия.
  7. На стороне эмитента выполняется аутентификация пользователя.
  8. Выполняется перенаправление пользователя к веб-сервису.
  9. Пользователь переходит к веб-сервису.

Информация о форматах запросов и оповещений приведена далее; общая информация о работе с 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="
}