Аутентификация по протоколу 3‑D Secure 1

Общая информация

Аутентификация пользователя с использованием протокола 3‑D Secure (Three-Domain Secure) предназначена для безопасного проведения интернет-оплат с использованием платежных карт. Она может выполняться с применением различных методов проверки подлинности пользователя, наиболее распространенным из которых является использование одноразовых проверочных кодов (One Time PIN, OTP). Как правило, пользователь получает такие коды в SMS-сообщениях, а затем вводит их на странице аутентификации.

В аутентификации 3‑D Secure используются три домена:

  • Домен эквайера. В рамках работы с платежной платформой Rocketpay к нему относятся веб-сервис мерчанта, платежная платформа и связанный с ней сервер 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 минут и измеряется с момента выявления необходимости аутентификации и до получения запроса от веб-сервиса. Если время ожидания истекло и запрос не принят — платеж автоматически отклоняется.
  • Если оповещение содержит объект redirect_data, необходимо перенаправить пользователя на страницу провайдера. Дальнейших действий со стороны веб-сервиса в этом случае не требуется. Информацию о ситуациях, при которых может понадобиться этот способ реагирования, можно получить у курирующего менеджера Rocketpay.

После того как в платежную платформу поступают данные о результате аутентификации, проведение платежа продолжается дальше. После этого дополнительно может понадобиться принять одно или несколько дополнительных оповещений о необходимости аутентификации 3‑D Secure 1. Если такое оповещение содержит параметр cascading_with_redirect со значением true, необходимо:

  • Отобразить пользователю страницу с сообщением об ошибке и получить его согласие на повторное проведение аутентификации.
  • Отреагировать одним из двух вариантов в зависимости от состава данных оповещения.

Информацию о таких дополнительных оповещениях можно получить у службы технической поддержки support@rocketpay.kz.

Рис.: Выполнение аутентификации 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 Rocketpay передается запрос на продолжение проведения платежа с учетом результата аутентификации.
  17. Запрос на продолжение проведения платежа поступает в платежную платформу.
  18. В платежной платформе выполняется прием запроса с проверкой его корректности.
  19. Платежная платформа направляет в веб-сервис ответ с информацией о получении запроса и его корректности.

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

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

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

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

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

В объекте 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" // Данные мерчанта в платежной системе
}
В объекте redirect_data оповещения передаются следующие параметры:
  • url — ссылка для перенаправления пользователя к провайдеру
  • body — данные для отправки запроса (может быть пустым)
  • method — HTTP-метод отправки запроса

Если параметр body не содержит данных, он представлен в оповещении как пустой массив, в противном случае он присутствует в оповещении как JSON-объект с данными. Далее приведены примеры представления body в оповещении.

Рис.: Пример объекта redirect_data с данными для перенаправления: пустой массив body

"redirect_data": {
              "body": [],    // Пустой массив 
              "method": "POST",
              "url": "https://example.com/redirect/absd1234",
}

Рис.: Пример объекта redirect_data с данными для перенаправления: объект body с данными

"redirect_data": {
            "body": {       // Объект с данными
                 "reference": "2000016"                 
              },
              "method": "POST",
              "url": "https://example.com/redirect/absd1234",
}

Запрос на перенаправление

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

  • Если данные получены в объекте acs:
    • action — адрес страницы аутентификации, полученный в параметре acs_url оповещения;
    • PaReq — сообщение PAReq, полученное в параметре pa_req оповещения;
    • TermUrl — адрес для перенаправления пользователя к веб-сервису после аутентификации;
    • MD — данные мерчанта в международной платежной системе (Merchant Data), полученные в параметре md оповещения.

    Метод отправки запроса — POST.

    Рис.: Пример 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-формы, — заменив параметры на актуальные для платежа.

  • Если данные получены в объекте redirect_data:
    • action — адрес провайдера, полученный в параметре url оповещения;
    • method — метод отправки запроса, полученный в параметре method оповещения;
    • body — тело запроса, если оно получено в оповещении.

Запрос на продолжение проведения платежа

Для продолжения проведения платежа с учетом результата аутентификации необходимо отправить в платежную платформу POST-запрос к конечной точке /v2/payment/card/3ds_result. В этом запросе должны использоваться следующие объекты и параметры:

  • general — объект, содержащий основные идентификационные сведения запроса:
    • project_id — идентификатор проекта, полученный от Rocketpay при интеграции;
    • 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="
}