Схемы работы

Схема работы через Payment Page

Аутентификация пользователя с использованием протокола 3‑D Secure 2 может выполняться при проведении одностадийных и двухстадийных оплат с применением платёжных карт, а также при проверках действительности платёжных карт.

Для проведения платежа с такой аутентификацией со стороны веб-сервиса необходимо отправить запрос, содержащий требуемые параметры и подпись, на рабочий URL ECommPay и принять оповещение о результате платежа.

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

Далее представлена схема аутентификации 3‑D Secure 2 в контексте оплаты в одну стадию.

Рис.: Выполнение аутентификации 3‑D Secure 2

  1. В платёжной платформе выполняется обработка запроса и выявляется необходимость аутентификации 3‑D Secure.
  2. От платёжной платформы к 3DS‑серверу, связанному с платёжной платформой, передаётся запрос на проверку возможности аутентификации с использованием одной из версий протокола 3‑D Secure: 1 или 2.
  3. На стороне 3DS‑сервера проверяется возможность аутентификации.
  4. От 3DS‑сервера к платёжной платформе направляются данные для формирования объекта iframe.
  5. От платёжной платформы к Payment Page передаются данные для формирования объекта iframe.
  6. Со стороны Payment Page выполняется открытие объекта iframe.
  7. С помощью объекта iframe выполняются сбор данных об устройстве пользователя и отправка этих данных к серверу управления доступом (Access Control Server) эмитента.
  8. От сервера управления доступом к Payment Page направляется уведомление о приёме этих данных.
  9. От Payment Page к платёжной платформе передаётся запрос на инициирование аутентификации.
  10. Запрос передаётся от платёжной платформы к 3DS-серверу.
  11. Запрос передаётся от 3DS‑сервера к серверу каталогов (Directory Server) международной платёжной системы.
  12. Запрос передаётся от сервера каталогов к серверу управления доступом.
  13. На стороне эмитента выполняется аутентификация пользователя. При этом в случае выбора варианта frictionless flow от сервера управления доступом к платёжной платформе (через сервер каталогов и 3DS-сервер) передаётся уведомление о результате аутентификации, а в случае выбора варианта challenge flow выполняются следующие шаги:
    • От сервера управления доступом к серверу каталогов и далее к 3DS-серверу, платёжной платформе и Payment Page передаются данные для перенаправления пользователя на страницу аутентификации (ACS URL).
    • Со стороны Payment Page выполняется перенаправление пользователя на страницу аутентификации.
    • Пользователю отображается страница аутентификации, после чего он осуществляет требуемые действия.
    • На стороне эмитента выполняется проверка подлинности пользователя.
    • От сервера контроля доступа к серверу каталогов и далее к 3DS-серверу передаётся информация о результате проверки.
    • От 3DS‑сервера к серверу каталогов и далее к серверу управления доступом передаётся ответ о приёме этой информации.
    • Со стороны сервера управления доступом выполняется перенаправление пользователя к Payment Page с передачей данных о результате аутентификации.
    • Пользователю отображается страница ожидания Payment Page.
    • От Payment Page к платёжной платформе передаётся запрос на продолжение проведения платежа.

Информация о формате запросов и оповещений, используемых для взаимодействий веб-сервиса с платёжной платформой в рамках данной процедуры, приведена в разделе Форматы данных; общая информация о работе с Payment Page API — в разделе Описание Payment Page API.

Схемы работы через Gate

Аутентификация пользователя с использованием протокола 3‑D Secure 2 может выполняться при проведении одностадийных и двухстадийных оплат с применением платёжных карт, а также при проверках действительности платёжных карт. При работе через Gate для аутентификации поддерживаются две схемы: базовая или расширенная.

Базовая схема

Для выполнения аутентификации по базовой схеме со стороны веб-сервиса необходимо:

  1. Принять от платёжной платформы оповещение с данными для перенаправления пользователя и отправить ответ о приёме этого оповещения.
  2. Перенаправить пользователя на страницу ожидания платёжной платформы с использованием данных из оповещения.
  3. Принять данные о результате аутентификации.
  4. Отправить в платёжную платформу запрос на продолжение проведение платежа с учётом результата аутентификации — 3ds_result.

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

Далее представлена базовая схема аутентификации 3‑D Secure 2 в контексте оплаты в одну стадию.

Рис.: Выполнение аутентификации 3‑D Secure 2 по базовой схеме

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

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

Расширенная схема

При использовании расширенной схемы со стороны веб-сервиса можно задавать необходимость отправки уведомления о приёме данных об устройстве пользователя от сервера управления доступом к веб-сервису. Для этого используется параметр 3ds_notification_url.

Для выполнения аутентификации по расширенной схеме со стороны веб-сервиса необходимо:

  1. Принять от платёжной платформы оповещение с данными для формирования объекта iframe и отправить ответ о приёме этого оповещения.
  2. Открыть объект iframe с использованием данных из оповещения.
  3. Если в запросе на проведение платежа был передан параметр 3ds_notification_url — принять от сервера управления доступом (ACS) эмитента уведомление о приёме данных и отправить в платёжную платформу запрос на инициирование аутентификации. Если этот параметр не был передан, данный шаг не используется.
  4. В случае выбора эмитентом варианта аутентификации frictionless flow — принять данные о результате аутентификации, а в случае выбора варианта аутентификации challenge flow выполнить следущие действия:
    • принять от платёжной платформы оповещение с данными для перенаправления пользователя на страницу аутентификации и отправить ответ о приёме этого оповещения;
    • перенаправить пользователя на страницу аутентификации;
    • принять данные о результате аутентификации;
    • отправить в платформу запрос на продолжение проведение платежа с учётом результата аутентификации — 3ds_result.

В некоторых случаях со стороны эмитента может приниматься решение об аутентификации пользователя без предоставления данных о его устройстве. Тогда со стороны веб-сервиса не требуется действий, отличных от стандартных при проведении платежа, а информация о результате аутентификации передаётся в оповещении о результате платежа.

Если аутентификация с использованием протокола 3‑D Secure 2 не выполнена из-за сбоя на стороне эмитента или платёжной системы либо из-за того, что эмитент не поддерживает протокол 3‑D Secure 2, со стороны платёжной платформы инициируется попытка аутентификации пользователя с использованием протокола 3‑D Secure 1. Такая попытка может быть инициирована на любом этапе, в том числе после перенаправления пользователя на страницу аутентификации. Со стороны веб-сервиса при этом необходимо принять и обработать оповещение с данными для перенаправления в формате, описанном в разделе Аутентификация 3‑D Secure 1, а пользователь может получить от эмитента не только проверочный код и уведомление об успешном платеже, но и уведомление об отклонении платежа.

Далее представлена расширенная схема аутентификации 3‑D Secure 2 с отображением двух способов уведомления о приёме данных об устройстве пользователя и двух вариантов аутентификации (frictionless flow и challenge flow) в контексте оплаты в одну стадию.

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

  1. В платёжной платформе выполняется обработка запроса и выявляется необходимость аутентификации 3‑D Secure.
  2. От платёжной платформы к 3DS‑серверу, связанному с платёжной платформой, передаётся запрос на проверку возможности аутентификации с использованием одной из версий протокола 3‑D Secure: 1 или 2.
  3. На стороне 3DS‑сервера проверяется возможность аутентификации.
  4. От 3DS‑сервера к платёжной платформе направляются данные для формирования объекта iframe.
  5. От платёжной платформы к веб-сервису направляется оповещение с данными для формирования объекта iframe.
  6. От веб-сервиса к платёжной платформе направляется ответ о приёме данных.
  7. На стороне веб-сервиса выполняется открытие объекта iframe.
  8. С помощью объекта iframe выполняются сбор данных об устройстве пользователя и отправка этих данных к серверу управления доступом (Access Control Server) эмитента.
  9. В зависимости от того, был ли указан в запросе на проведение платежа параметр 3ds_notification_url с адресом, уведомление о приёме этих данных отправляется от сервера управления доступом либо к веб-сервису, либо к платёжной платформе. Если уведомление направляется к веб-сервису, то выполняются следующие шаги:
    • От веб-сервиса на заданный URL ECommPay передаётся запрос на инициирование аутентификации пользователя.
    • Запрос поступает в платёжную платформу.
    • В платёжной платформе выполняется приём запроса с проверкой его корректности.
    • От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности.
  10. От платёжной платформы к 3DS-серверу передаётся запрос на аутентификацию пользователя.
  11. Запрос передаётся от 3DS‑сервера к серверу каталогов международной платёжной системы (Directory Server).
  12. Запрос передаётся от сервера каталогов к серверу управления доступом.
  13. На стороне эмитента выполняется аутентификация пользователя. При этом в случае выбора эмитентом варианта аутентификации frictionless flow от сервера управления доступом к платёжной платформе (через сервер каталогов и 3DS-сервер) передаётся информация о результате аутентификации, а в случае выбора варианта аутентификации challenge flow выполняются следующие шаги:
    • От сервера управления доступом к серверу каталогов и далее к 3DS-серверу и платёжной платформе передаются данные для перенаправления пользователя на страницу аутентификации (ACS URL).
    • От платёжной платформы к веб-сервису направляется оповещения с данными для перенаправления.
    • Со стороны веб-сервиса выполняется перенаправление пользователя на страницу аутентификации.
    • Пользователю отображается страница аутентификации, после чего он осуществляет требуемые действия.
    • На стороне эмитента выполняется проверка подлинности пользователя.
    • От сервера контроля доступа к серверу каталогов и далее к 3DS-серверу передаётся информация о результате проверки.
    • От 3DS‑сервера к серверу каталогов и далее к серверу управления доступом передаётся ответ о приёме этой информации.
    • Со стороны сервера управления доступом выполняется перенаправление пользователя к веб-сервису с передачей данных о результате аутентификации.
    • Пользователю отображается страница ожидания веб-сервиса.
    • От веб-сервиса на заданный URL ECommPay передаётся запрос на продолжение проведения платежа с учётом результата аутентификации.
    • Запрос поступает в платёжную платформу.
    • В платёжной платформе выполняется приём запроса с проверкой его корректности.
    • От платёжной платформы к веб-сервису направляется ответ с информацией о получении запроса и его корректности.

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