Аутентификация 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.

Информация о форматах запросов и оповещений приведена далее; общая информация о работе с API — в разделе Организация взаимодействия.

Формат оповещения с данными для перенаправления

Для передачи данных для перенаправления используются оповещения стандартного формата, описание которого представлено в разделе Оповещения. Данные для перенаправления пользователя передаются в одном из объектов такого оповещения: acs или redirectData.

В объекте acs оповещения передаются следующие данные: сообщение PAReq (в параметре pa_req) для направления запроса на прохождение аутентификации 3‑D Secure 1 эмитенту, адрес страницы аутентификации (acs_url) и данные мерчанта в платёжной системе — Merchant Data (md).

"acs":{  
  "pa_req":"eJxVUtluwyAQ/BUrH2DA...n8/4htjT7Em", // Сообщение PAReq 
  "acs_url":"https://example.com/ACS",
                              // Адрес страницы аутентификации
  "md":"eyJfto7jg456ZCI6IiJ9" // Данные мерчанта в платёжной системе
}

В объекте redirectData оповещения передаются следующие данные: тело запроса (body), метод отправки запроса (method) и адрес провайдера (url).

"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 — тело запроса, если оно получено в оповещении.

<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="
}