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

3‑D Secure 2 — это новая версия протокола 3‑D Secure (Three-Domain Secure), который обеспечивает безопасное проведение интернет-оплат с использованием платежных карт. К основным преимуществам 3‑D Secure 2 по сравнению с 3‑D Secure 1 относятся:

• Расширение возможностей проведения платежей за счет поддержки аутентификации в мобильных приложениях (без необходимости задействовать браузер).
• Повышение безопасности платежей за счет отказа от использования статических паролей (таких как пароли из списка, полученного от эмитента) и перехода к более надежным методам аутентификации, например с использованием биометрических данных пользователя, а также за счет расширения состава передаваемых при аутентификации данных.
• Повышение удобства платежей за счет добавления варианта аутентификации с подтверждением личности пользователя эмитентом, без каких-либо действий со стороны пользователя.

Вариант аутентификации без каких-либо действий пользователя называется frictionless flow. Другой вариант — challenge flow — предусматривает подтверждение пользователем своей личности, например с помощью одноразового кода (аналогично 3‑D Secure 1) или биометрических данных, если такая возможность поддерживается эмитентом.

Выбор между этими вариантами осуществляется на стороне эмитента. Для этого могут применяться интеллектуальные механизмы проверки подлинности с использованием разнообразной информации о пользователе и платеже, в том числе переданной со стороны мерчанта. Это может быть, например, информация об учетной записи пользователя на стороне веб-сервиса и об адресе доставки. Чтобы повысить вероятность выбора варианта frictionless flow, такую информацию рекомендуется передавать в запросах на проведение платежа.

Как и в случае с 3‑D Secure 1, при аутентификации 3‑D Secure 2 используются три домена:

• Домен эквайера. В рамках работы с платежной платформой Rocketpay к нему относятся веб-сервис мерчанта, платежная платформа и связанный с ней 3DS-сервер (3DS Server).
• Домен совместимости. К нему относятся серверы каталогов (Directory Servers, DS) международных платежных систем.
• Домен эмитента. К нему относятся серверы управления доступом (Access Control Servers, ACS) эмитента (и, соответственно, страница аутентификации).

Следует учитывать, что информация о возможности проведения аутентификации пользователя хранится на 3DS-сервере, и следовательно эту информацию можно получить только после отправки запроса на проведение платежа. Также платежная платформа не располагает информацией о действиях пользователей на странице аутентификации, а только получает результат прохождения аутентификации.

Подробнее о порядке взаимодействия между этими доменами см. в разделе Схемы работы через Gate.

В этом разделе содержатся ответы на вопросы о протоколе 3‑D Secure 2, его поддержке и возможностях его использования.

Общие вопросы о протоколе:

• Что меняется при переходе от 3‑D Secure 1 к 3‑D Secure 2?
• Что меняется в пользовательском сценарии аутентификации?
• Каким образом используются биометрические данные пользователя?
• Можно ли заранее узнать о необходимости аутентификации пользователя?
• Есть ли такие виды платежей, при проведении которых не требуется аутентификация 3‑D Secure 2?
• Использование исключений гарантирует проведение платежа без аутентификации 3‑D Secure 2?

Вопросы о переходе к использованию протокола:

• Что нужно сделать для поддержки 3‑D Secure 2?
• Что необходимо изменить для работы с Gate?
• Какие данные следует использовать для тестирования изменений?

Вопросы об использовании протокола:

• Можно ли использовать 3‑D Secure 2 для всех оплат картами Visa, Mastercard и Maestro?
• Нужно ли поддерживать 3‑D Secure 1 при переходе к 3‑D Secure 2?
• Можно ли мерчанту выбрать аутентификацию 3‑D Secure 1 вместо 3‑D Secure 2?
• Как узнать какая аутентификация выполнялась?
• Можно ли проводить платежи без выполнения аутентификации 3‑D Secure (non-3DS)?

За дополнительной информацией по этим и другим вопросам обращайтесь к курирующему менеджеру Rocketpay.

Что меняется при переходе от 3‑D Secure 1 к 3‑D Secure 2?

К общим изменениям относятся:

• Расширение возможностей проведения платежей за счет поддержки аутентификации в мобильных приложениях (без необходимости задействовать браузер).
• Повышение безопасности платежей за счет перехода к более надежным методам аутентификации и расширения состава передаваемых при аутентификации данных.
• Повышение удобства платежей за счет добавления варианта аутентификации, не требующего действий пользователя.

В пользовательском сценарии добавляется вариативность: с возможным промежуточным перенаправлением пользователя, с поддержкой двух вариантов аутентификации (frictionless flow и challenge flow) и с допустимыми нововведениями в способе подтверждения пользователем своей подлинности (например, с использованием биометрических данных).

К изменениям во взаимодействиях веб-сервисов с платежной платформой Rocketpay относятся поддержка новых параметров для запросов и изменения структур данных в оповещениях. Кроме того, при переходе к работе с 3‑D Secure 2 осуществляется регистрация мерчантов в программах аутентификации Visa Secure и Mastercard Identity Check и на платежных страницах необходимо использовать логотипы этих программ.

Со стороны веб-сервиса допустимо не поддерживать изменения в запросах и оповещениях, но необходимо использовать новые логотипы.

Для получения информации о регистрации в программах Visa Secure и Mastercard Identity Check и о замене логотипов следует обращаться к курирующему менеджеру Rocketpay.

Что меняется в пользовательском сценарии аутентификации?

Если при использовании протокола 3‑D Secure 1 аутентификация выполняется с перенаправлением пользователя от веб-сервиса к странице аутентификации (ACS) эмитента, то при использовании протокола 3‑D Secure 2 количество перенаправлений может варьироваться:

• В зависимости от используемой на стороне веб-сервиса схемы аутентификации: при использовании схемы с тем же алгоритмом, что и в схеме для поддержки 3‑D Secure 1, перед перенаправлением на страницу аутентификации (ACS) выполняется промежуточное перенаправление пользователя на страницу ожидания платежной платформы, а при использовании схемы с новым алгоритмом такое перенаправление не выполняется.
• В зависимости от выбранного на стороне эмитента варианта аутентификации: при выборе варианта challenge flow пользователь перенаправляется на страницу аутентификации (ACS), а при выборе варианта frictionless flow такое перенаправление не выполняется.

Также для пользователя возможны изменения в способе подтверждения своей подлинности: например, со стороны эмитента может запрашиваться подтверждение с использованием биометрических данных.

Каким образом используются биометрические данные пользователя?

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

Примером использования биометрических данных может быть подтверждение личности пользователя с использованием сканера отпечатков пальцев или сканера объемно-пространственной формы лица (такого как Face ID) на его мобильном устройстве.

Можно ли заранее узнать о необходимости аутентификации пользователя?

Нет, информация о возможности проведения аутентификации пользователя хранится на сервере управления доступом, и следовательно эту информацию можно получить только после отправки запроса на проведение платежа.

Есть ли такие виды платежей, при проведении которых не требуется аутентификация 3‑D Secure 2?

Да. К платежам, на которые не распространяются требования PSD2 к аутентификации, относятся:

• Оплата с использованием платежных карт не из Европейской экономической зоны.
• Оплата с использованием анонимных предоплаченных платежных карт, например с использованием подарочной карты.
• Оплата по инициативе мерчанта (Merchant-initiated transactions, MIT) в случаях, когда первоначальная операция выполнялась с аутентификацией 3‑D Secure 2 независимо от ее варианта: challenge flow или frictionless flow.

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

Кроме того, есть виды платежей, которые в соответствии с решениями эмитентов могут относиться к исключениям и проводиться без аутентификации 3‑D Secure 2. Это:

• Платежи на суммы до 30 евро, в случаях, когда с момента последней успешной аутентификации проведено не более пяти платежей и общая сумма этих платежей не превышает 100 евро.
• Платежи с низким уровнем риска, с учетом порогов, определяемых в соответствии с PSD2.
• Платежи в пользу тех мерчантов, которые по инициативе или с согласия держателя карты занесены в список доверенных.
• Платежи, инициируемые юридическими лицами с использованием процессов и протоколов, обеспечивающих высокий уровень защиты от мошенничества (так называемые безопасные корпоративные платежи).

Работа с такими исключениями в платежной платформе пока не поддерживается.

Использование исключений гарантирует проведение платежа без аутентификации 3‑D Secure 2?

Нет. В случае проведения платежа, который относится к исключениям, решение о необходимости аутентификации 3‑D Secure 2 остается за эмитентом. С его стороны может быть направлен «мягкий отказ» (soft decline), означающий необходимость выполнения аутентификации 3‑D Secure 2. При получении такого отказа со стороны мерчанта следует повторно направить запрос на проведение платежа с теми же платежными данными, которые были переданы в первоначальном запросе.

Что нужно сделать для поддержки 3‑D Secure 2?

Для поддержки 3‑D Secure 2 на стороне веб-сервиса необходимо:

1. Согласовать с курирующим менеджером Rocketpay возможность, порядок и сроки перехода к 3‑D Secure 2.
2. Выполнить необходимые доработки.
3. Совместно со специалистами технической поддержки Rocketpay провести тестирование и запуск новой функциональности (подробнее о данных для тестирования — в ответе на вопрос ниже).

Что необходимо изменить для работы с Gate?

При использовании Gate веб-сервис может поддерживать одну из следующих схем аутентификации 3‑D Secure 2:

• Базовая схема — алгоритм, аналогичный применяемому для 3‑D Secure 1 (с теми же параметрами в запросах и оповещениях). При использовании этой схемы на платежных страницах необходимо отображать новые логотипы программ аутентификации международных платежных систем, а в остальном взаимодействие веб-сервиса с платежной платформой остается прежним.
• Расширенная схема — новый алгоритмом, позволяющий избежать промежуточных перенаправлений пользователя. В этой схеме на стороне веб-сервиса необходимо обеспечить прием оповещений с новыми параметрами и поддержку нового алгоритма перенаправления пользователя на страницу аутентификации (ACS). Дополнительно можно обеспечить прием уведомлений от сервера управления доступом и отправку запросов нового типа и использовать эту возможность для некоторых или для всех платежей. (Подробнее см. Схемы работы через Gate.)

При использовании любой из этих схем рекомендуется отправлять дополнительные параметры в запросах на проведение платежей, чтобы повысить вероятность выбора варианта аутентификации frictionless flow.

После подключения базовой схемы возможен упрощенный переход к использованию расширенной схемы, без обращения к курирующему менеджеру и специалистам технической поддержки. Для такого перехода достаточно начать передавать в запросах на проведение платежей объект acs_return_url с параметром return_url (подробнее о параметре — в разделе Формат запроса на платеж через Gate). В этом случае платежи, в запросах на проведение которых передается return_url, проводятся по расширенной схеме, а остальные — по базовой.

Какие данные следует использовать для тестирования изменений?

Для проведения тестовых платежей необходимо использовать данные платежных карт, перечисленные ниже.

Данные платежных карт Visa:

• с выбором варианта аутентификации frictionless flow:
  • 4477000000000006 — успешный платеж (статус платежа success);
  • 4012000000020063 — отказ в проведении платежа (статус платежа decline);
• с выбором варианта аутентификации challenge flow:
  • 4314220000000056 — успешный платеж (статус платежа success);
  • 4012000000020089 — отказ в проведении платежа (статус платежа decline);

Данные платежных карт Mastercard:

• с выбором варианта аутентификации frictionless flow:
  • 5252000000000004 — успешный платеж (статус платежа success);
  • 5544330000000029 — отказ в проведении платежа (статус платежа decline);
• с выбором варианта аутентификации challenge flow:
  • 5413330000000019 — успешный платеж (статус платежа success);
  • 5544330000000045 — отказ в проведении платежа (статус платежа decline);

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

Можно ли использовать 3‑D Secure 2 для всех оплат картами Visa, Mastercard и Maestro?

Нет, возможность использования нового протокола для конкретной оплаты зависит от готовности эмитента и провайдеров, участвующих в ее проведении. Эмитенты Европейской экономической зоны должны поддерживать 3‑D Secure 2 с 14 сентября 2019-го года, а эмитенты других регионов — к концу 2020-го года.

Нужно ли поддерживать 3‑D Secure 1 при переходе к 3‑D Secure 2?

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

Можно ли мерчанту выбрать аутентификацию 3‑D Secure 1 вместо 3‑D Secure 2?

Нет, необходимость использования того или иного протокола определяется на стороне 3DS-сервера и зависит от возможностей эмитента. Мерчант не может повлиять на этот выбор.

Как узнать какая аутентификация выполнялась?

Информация о протоколе аутентификации, который был использован при проведении платежа, передается в оповещении о результате платежа.

Можно ли проводить платежи без выполнения аутентификации 3‑D Secure (non-3DS)?

Со стороны мерчанта допустим отказ от аутентификации. При этом необходимо учитывать следующее:

• С 1 февраля 2020-го года эмитенты, действующие на территории Европейской экономической зоны, должны отклонять все платежи без аутентификации 3‑D Secure 2, кроме платежей двух видов: не подпадающих под действие PSD2 и отнесенных в соответствии с PSD2 к допустимым исключениям (подробнее — в ответе на вопрос об этих видах платежей). Отказ от аутентификации при проведении платежей с использованием карт, эмитированных в Европейской экономической зоне, возможен только для платежей, не подпадающих под действие PSD2.
• В случае отказа от аутентификации ответственность за мошеннические платежи полностью перекладывается на мерчанта.

Для уточнения условий отказа следует обращаться к курирующему менеджеру Rocketpay.

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

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

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

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

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

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

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

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

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

Общее описание форматов запросов при работе через Gate представлено в разделе Общий порядок интеграции, а описание объектов и параметров, использование которых рекомендуется для повышения вероятности выбора варианта аутентификации frictionless flow, — в этом разделе.

Объект acs_return_url

Объект содержит параметры, необходимые для перенаправления пользователя к веб-сервису после выполнения аутентификации, а также для получения уведомления о приеме данных от сервера управления доступом (ACS) эмитента при использовании расширенной схемы аутентификации.

Параметры в объекте customer

Параметры из объекта customer, рекомендуемые для повышения вероятности выбора варианта аутентификации frictionless flow, условно можно разделить на следующие группы:

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

Описания этих параметров представлены в таблицах далее.

Параметры в объекте payment

Параметр в объекте billing

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

Информация о результате платежа передается от платежной платформы в веб-сервис в оповещении стандартного формата, описание которого представлено в разделе Оповещения (callbacks) в Gate.

В случае выполнения аутентификации 3‑D Secure 2 при проведении платежа в объекте mpi_result оповещения дополнительно могут передаваться следующие параметры:

• mpi_operation_id — идентификатор операции на стороне 3DS‑сервера;
• ds_operation_id — идентификатор операции на стороне cервера каталогов международной платежной системы;
• acs_operation_id — идентификатор операции на стороне сервера управления доступом эмитента;
• mpi_timestamp — дата и время аутентификации;
• cardholder_info — информация об аутентификации, которую рекомендуется отобразить пользователю при уведомлении о результате проведения платежа;
• authentication_flow — указатель использованного варианта аутентификации: 01 для frictionless flow или 02 для challenge flow.

По умолчанию эти параметры не передаются. Для того, чтобы получать их в оповещениях, необходимо обратиться в службу технической поддержки support@rocketpay.kz.

{
  "account": {
    "number": "424242******4243",
    "token": "f365bb1729f9b72fd9c09703a751c979f3becc679f29c3e35c91d18070d15654",
    "type": "visa",
    "card_holder": "JUDY DOE",
    "id": 45678,
    "expiry_month": "08",
    "expiry_year": "2025"
  },
  "customer": {
    "id": "customer_12",
    "phone": "44991234567"
  },
  "payment": {
    "date": "2019-01-11T13:02:42+0000",
    "id": "456789",
    "method": "card",
    "status": "success",
    "sum": {
      "amount": 400000,
      "currency": "USD"
    },
    "type": "purchase",
    "description": ""
  },
  "project_id": 42,
  "operation": {
    "id": 969000002636,
    "type": "sale",
    "status": "success",
    "date": "2019-01-11T13:02:42+0000",
    "created_date": "2019-01-11T13:01:45+0000",
    "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c",
    "sum_initial": {
      "amount": 400000,
      "currency": "USD"
    },
    "sum_converted": {
      "amount": 400000,
      "currency": "USD"
    },
    "provider": {
      "id": 408,
      "payment_id": "330157196",
      "date": "2019-01-11T13:02:32+0000",
      "auth_code": "",
      "endpoint_id": "612266625"
    },
    "mpi_result":{
      "mpi_operation_id":"",
            // Идентификатор операции на стороне 3DS‑сервера
      "ds_operation_id":"",
            // Идентификатор операции на стороне сервера каталогов международной платежной системы
      "acs_operation_id":"",
            // Идентификатор операции на стороне сервера управления доступом эмитента
      "mpi_timestamp":"YYYYMMDDHHMM",
            // Дата и время выполнения аутентификации
      "cardholder_info":"Additional authentication is needed for this transaction",
            // Информация об аутентификации, которую рекомендуется отобразить пользователю
      "authentication_flow":"02"
            // Информация о варианте аутентификации
    },
    "code": "0",
    "message": "Success",
    "eci": "07"
  },
  "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...=="
}