Аутентификация по протоколу 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-сервере, и следовательно эту информацию можно получить только после отправки запроса на проведение платежа. Также платежная платформа не располагает информацией о действиях пользователей на странице аутентификации, а только получает результат прохождения аутентификации.

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

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

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

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

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

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

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

• Можно ли использовать 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 провести тестирование и запуск новой функциональности (подробнее о данных для тестирования — в ответе на вопрос ниже).

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

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

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

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

Данные платежных карт 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.

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

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

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

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

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

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

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

Новый параметр payment_merchant_risk

Параметр payment_merchant_risk используется при работе через Payment Page и представляет собой строку, полученную в результате кодирования с применением алгоритма Base64, с информацией о деталях покупки пользователя и о предпочтительном для мерчанта варианте аутентификации. Для получения такой строки необходимо:

1. Сформировать JSON-объект payment с необходимыми объектами и параметрами, в качестве которых можно использовать любые параметры из представленных в примере.

   Рис.: Пример JSON-объекта

   { 
     "payment":{ 
       "reorder":"01",
       "preorder_purchase":"01",
       "preorder_date":"01-10-2019",
       "challenge_indicator":"01",
       "challenge_window":"01",
       "gift_card":{ 
         "amount":12345,
         "currency":"USD",
         "count":1
       }
     }
   }

   Табл. 1. Описание параметров

   ПАРАМЕТР	ТИП	ОПИСАНИЕ
   challenge_indicator	string	Указатель предпочтения по использованию варианта аутентификации challenge flow. Возможные значения: 01 — без предпочтений; 02 — предпочтительно не выполнять; 03 — предпочтительно выполнять; 04 — обязательно выполнять; 05 — не выполнять, анализ рисков выполнен на стороне мерчанта; 06 — не выполнять, применить сценарий Data Only; 07 — не выполнять, Strong Customer Authentication уже выполнена иным способом; 08 — не выполнять, мерчант включен в список доверенных для этого пользователя; 09 — обязательно выполнять, предпочтительно предложить пользователю добавить мерчанта в список доверенных
   challenge_window	string	Размер окна для открытия страницы аутентификации. Возможные значения: 01 — 250 x 400 пикселей, 02 — 390 x 400 пикселей, 03 — 500 x 600 пикселей, 04 — 600 x 400 пикселей, 05 — полноэкранный режим
   preorder_date	string	Планируемая дата поступления товара или услуги в формате ДД-ММ-ГГГГ
   preorder_purchase	string	Индикатор предварительного заказа. Возможные значения: 01 — не является предварительным заказом, 02 — является предварительным заказом
   reorder	string	Индикатор первичной или повторной покупки данного товара или услуги пользователем. Возможные значения: 01 — первичная покупка, 02 — повторная покупка
   gift_card — объект с информацией об оплате предоплаченными или подарочными картами
   amount	integer	Общая сумма оплаты предоплаченными или подарочными картами в дробых единицах валюты
   currency	string	Код валюты оплаты предоплаченными или подарочными картами в формате ISO 4217 alpha-3 (например, GBP)
   count	integer	Количество предоплаченных или подарочных карт, использованных для оплаты

2. Закодировать JSON-объект с применением алгоритма Base64.

   Рис.: Пример строки

   eyAKICAicGF5bWVudCI6eyAKICAgICJyZW9yZGVyIjoiMDEiLAogICAgInByZW9yZGVyX3B1cmNoYXNlIjoiMDEiLAogICAgInByZW9yZGVyX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICJjaGFsbGVuZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgImNoYWxsZW5nZV93aW5kb3ciOiIwMSIsCiAgICAiZ2lmdF9jYXJkIjp7IAogICAgICAiYW1vdW50IjoxMjM0NSwKICAgICAgImN1cnJlbmN5IjoiVVNEIiwKICAgICAgImNvdW50IjoxCiAgICB9CiAgfQp9Cg==

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

Новый параметр customer_account_info

Параметр customer_account_info используется при работе через Payment Page и представляет собой строку, полученную в результате кодирования с применением алгоритма Base64, с информацией об учетной записи пользователя на стороне веб-сервиса и о контактных данных пользователя. Для получения такой строки необходимо:

1. Сформировать JSON-объект customer с необходимыми объектами и параметрами, в качестве которых можно использовать любые параметры из представленных в примере.

   Рис.: Пример JSON-объекта

   { 
     "customer":{ 
       "address_match":Y,
       "home_phone":"79105211111",
       "work_phone":"74955211111",
       "account":{ 
         "additional":"gamer12345",
         "age_indicator":"01",
         "date":"01-10-2019",
         "change_indicator":"01",
         "change_date":"01-10-2019",
         "pass_change_indicator":"01",
         "pass_change_date":"01-10-2019",
         "purchase_number":12,
         "provision_attempts":16,
         "activity_day":22,
         "activity_year":222,
         "payment_age_indicator":"01",
         "payment_age":"01-10-2019",
         "suspicious_activity":"01",
         "auth_method":"01",
         "auth_time":"01-10-201913:12",
         "auth_data":"login_0102"
       }
     }
   }

   Табл. 2. Описание параметров

   ПАРАМЕТР	ТИП	ОПИСАНИЕ
   address_match	string	Указатель совпадения платежного адреса пользователя с адресом доставки, указанным в объекте shipping. Возможные значения: Y — совпадает, N — не совпадает
   home_phone	string	Номер домашнего телефона пользователя, может содержать только цифры, от четырех до двадцати четырех (например, 44991234567)
   work_phone	string	Номер рабочего телефона пользователя, может содержать только цифры, от четырех до двадцати четырех (например, 44997654321)
   account — объект, содержащий информацию об учетной записи пользователя на стороне мерчанта
   additional	string	Дополнительная информация об учетной записи пользователя, например ее идентификатор; в произвольном формате с использованием до шестидесяти четырех символов
   activity_day	integer	Количество попыток проведения оплаты за последние 24 часа, не более трех символов (999)
   activity_year	integer	Количество попыток проведения оплаты за последние 365 дней, не более трех символов (999)
   age_indicator	string	Количество дней с момента создания учетной записи пользователя. Возможные значения: 01 — платеж проводится без аутентификации в учетной записи, 02 — учетная запись создана в день проведения платежа, 03 — менее 30 дней, 04 — от 30 до 60 дней, 05 — более 60 дней
   auth_data	string	Дополнительная информация об аутентификации на стороне веб-сервиса в произвольном формате. Параметр может содержать не более 255 символов
   auth_method	string	Указатель способа последней аутентификации пользователя на стороне веб-сервиса. Возможные значения: 01 — доступ без аутентификации; 02 — аутентификация с использованием данных, сохраненных на стороне мерчанта; 03 — аутентификация с использованием Federated ID (например, Google Account или Facebook); 04 — аутентификация с использованием аутентификатора, соответствующего стандартам Fast IDentity Online (FIDO)
   auth_time	string	Дата и время последней аутентификации пользователя на стороне веб-сервиса в формате ДД-ММ-ГГГГчч:мм
   date	string	Дата создания учетной записи в формате ДД-ММ-ГГГГ
   change_date	string	Дата последних изменений в учетной записи, за исключением изменения или сброса пароля, в формате ДД-ММ-ГГГГ
   change_indicator	string	Количество дней с момента последних изменений в учетной записи, за исключением изменения или сброса пароля. Возможные значения: 01 — изменения в день проведения платежа, 02 — менее 30 дней, 03 — от 30 до 60 дней, 04 — более 60 дней
   pass_change_date	string	Дата последнего изменения или сброса пароля в формате ДД-ММ-ГГГГ
   pass_change_indicator	string	Количество дней с момента последнего изменения или сброса пароля. Возможные значения: 01 — пароль не был изменен или сброшен, 02 — пароль был изменен или сброшен в день проведения платежа, 03 — менее 30 дней, 04 — от 30 до 60 дней, 05 — более 60 дней
   payment_age	string	Дата добавления платежных данных карты в формате ДД-ММ-ГГГГ
   payment_age_indicator	string	Количество дней с момента сохранения данных платежной карты, используемой для проведения платежа, в учетной записи пользователя. Возможные значения: 01 — платеж проводится без аутентификации в учетной записи, 02 — данные карты сохранены в день проведения платежа, 03 — менее 30 дней, 04 — от 30 до 60 дней, 05 — более 60 дней
   provision_attempts	integer	Количество попыток сохранения новых платежных данных карты за последние 24 часа, не более трех символов (999)
   purchase_number	integer	Количество покупок, совершенных через эту учетную запись за последние 6 месяцев, не более четырех символов (9999)
   suspicious_activity	string	Индикатор подозрительной активности. Возможные значения: 01 — без подозрений, 02 — с подозрительной активностью

2. Закодировать JSON-объект с применением алгоритма Base64.

   Рис.: Пример строки

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAiYWRkcmVzc19tYXRjaCI6dHJ1ZSwKICAgICJob21lX3Bob25lIjoiNzkxMDUyMTExMTEiLAogICAgIndvcmtfcGhvbmUiOiI3NDk1NTIxMTExMSIsCiAgICAiYWNjb3VudCI6eyAKICAgICAgImFkZGl0aW9uYWwiOiJnYW1lcjEyMzQ1IiwKICAgICAgImFnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJkYXRlIjoiMDEtMTAtMjAxOSIsCiAgICAgICJjaGFuZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgICAiY2hhbmdlX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICAgInBhc3NfY2hhbmdlX2luZGljYXRvciI6IjAxIiwKICAgICAgInBhc3NfY2hhbmdlX2RhdGUiOiIwMS0xMC0yMDE5IiwKICAgICAgInB1cmNoYXNlX251bWJlciI6MTIsCiAgICAgICJwcm92aXNpb25fYXR0ZW1wdHMiOjE2LAogICAgICAiYWN0aXZpdHlfZGF5IjoyMiwKICAgICAgImFjdGl2aXR5X3llYXIiOjIyMjIsCiAgICAgICJwYXltZW50X2FnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJwYXltZW50X2FnZSI6IjAxLTEwLTIwMTkiLAogICAgICAic3VzcGljaW91c19hY3Rpdml0eSI6IjAxIiwKICAgICAgImF1dGhfbWV0aG9kIjoiMDEiLAogICAgICAiYXV0aF90aW1lIjoiMDEtMTAtMjAxOTEzOjEyIiwKICAgICAgImF1dGhfZGF0YSI6ImxvZ2luXzAxMDIiCiAgICB9CiAgfQp9

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

Новый параметр customer_shipping

Параметр customer_shipping используется при работе через Payment Page и представляет собой строку, полученную в результате кодирования с применением алгоритма Base64, с информацией о доставке товара или услуги пользователю. Для получения такой строки необходимо:

1. Сформировать JSON-объект customer с объектом shipping и необходимыми параметрами, в качестве которых можно использовать любые параметры из представленных в примере.

   Рис.: Пример JSON-объекта

   { 
     "customer":{ 
       "shipping":{ 
         "type":"01",
         "delivery_time":"01",
         "delivery_email":"johndoe@example.com",
         "address_usage_indicator":"01",
         "address_usage":"01-10-2019",
         "city":"Moscow",
         "country":"RU",
         "address":"Main street 12",
         "postal":"109111",
         "region_code":"RU",
         "name_indicator":"01"
       }
     }
   }

   Табл. 3. Описание параметров

   ПАРАМЕТР	ТИП	ОПИСАНИЕ
   shipping — объект, содержащий информацию о доставке
   address	string	Адрес доставки, не более 150 символов
   address_usage	string	Дата первого использования адреса доставки, указанного в параметрах этого объекта, в формате ДД-ММ-ГГГГ
   address_usage_indicator	string	Количество дней с момента первого использования адреса доставки, указанного в параметрах этого объекта. Возможные значения: 01 — указанный адрес используется впервые, 02 — менее 30 дней назад, 03 — от 30 до 60 дней назад, 04 — более 60 дней назад
   city	string	Название города доставки, не более 50 символов
   country	string	Код страны доставки в формате ISO 3166-1 alpha-2, например GB для Великобритания
   delivery_email	string	Адрес электронной почты в случае доставки на этот адрес. Может содержать не более 255 символов
   delivery_time	string	Срок доставки. Возможные значения: 01 — электронная доставка в день покупки, 02 — доставка в день покупки, 03 — доставка на следующий день после покупки, 04 — доставка более чем через один день после покупки
   name_indicator	string	Индикатор совпадения имени пользователя с именем получателя. Возможные значения: 01 — имена совпадают, 02 — имена не совпадают
   postal	string	Почтовый индекс доставки, не более 16 символов
   region_code	string	Код штата, провинции или региона страны в формате ISO 3166-2, например SPE для Санкт-Петербурга. При указании значения этого параметра также необходимо указать значение параметра country в объекте shipping
   type	string	Способ доставки, выбранный пользователем. Возможные значения: 01 — доставка на платежный адрес держателя карты; 02 — доставка на другой подтвержденный адрес; 03 — доставка на адрес, не совпадающий с платежным и не являющийся подтвержденным; 04 — доставка в магазин; 05 — электронная доставка; 06 — без доставки (например, в случае покупки билетов на мероприятие); 07 — другое

2. Закодировать JSON-объект с применением алгоритма Base64.

   Рис.: Пример строки

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAic2hpcHBpbmciOnsgCiAgICAgICJ0eXBlIjoiMDEiLAogICAgICAiZGVsaXZlcnlfdGltZSI6IjAxIiwKICAgICAgImRlbGl2ZXJ5X2VtYWlsIjoidGVzdEBnbWFpbC5jb20iLAogICAgICAiYWRkcmVzc191c2FnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJhZGRyZXNzX3VzYWdlIjoiMDEtMTAtMjAxOSIsCiAgICAgICJjaXR5IjoiTW9zY293IiwKICAgICAgImNvdW50cnkiOiJSVSIsCiAgICAgICJhZGRyZXNzIjoiTGVuaW5hIHN0cmVldCAxMiIsCiAgICAgICJwb3N0YWwiOiIxMDkxMTEiLAogICAgICAicmVnaW9uX2NvZGUiOiJSVSIsCiAgICAgICJuYW1lX2luZGljYXRvciI6IjAxIgogICAgfQogIH0KfQ==

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

Новый параметр customer_mpi_result

Параметр customer_mpi_result используется при работе через Payment Page и представляет собой строку, полученную в результате кодирования с применением алгоритма Base64, с данными о предыдущей аутентификации пользователя. Для получения такой строки необходимо:

1. Сформировать JSON-объект customer с объектом mpi_result и необходимыми параметрами, в качестве которых можно использовать любые параметры из представленных в примере.

   Рис.: Пример JSON-объекта

   { 
     "customer":{ 
       "mpi_result":{ 
         "acs_operation_id":"00000000-0005-5a5a-8000-016d3ea31d54",
         "authentication_flow":"01",
         "authentication_timestamp":"201812141050"
       }
     }
   }

   Табл. 4. Описание параметров

   ПАРАМЕТР	ТИП	ОПИСАНИЕ
   mpi_result — объект с данными о предыдущей аутентификации пользователя
   acs_operation_id	string	Идентификатор предыдущей операции пользователя на стороне эмитента, не более 36 символов. В качестве этого идентификатора необходимо использовать значение, полученное в параметре acs_operation_id оповещения о результате проведения предыдущего платежа
   authentication_flow	string	Указатель варианта предыдущего прохождения аутентификации пользователем, полученное в параметре authentication_flow оповещения о результате проведения предыдущего платежа. Возможные значения: 01 — frictionless flow, 02 — challenge flow
   authentication_timestamp	string	Дата и время предыдущей успешной аутентификации пользователя. В качестве значения необходимо использовать данные, полученные в параметре mpi_timestamp оповещения о результате проведения предыдущего платежа

2. Закодировать JSON-объект с применением алгоритма Base64.

   Рис.: Пример строки

   eyAKICAiY3VzdG9tZXIiOnsgCiAgICAibXBpX3Jlc3VsdCI6eyAKICAgICAgImFjc19vcGVyYXRpb25faWQiOiIwMDAwMDAwMC0wMDA1LTVhNWEtODAwMC0wMTZkM2VhMzFkNTQiLAogICAgICAiYXV0aGVudGljYXRpb25fZmxvdyI6IjAxIiwKICAgICAgImF1dGhlbnRpY2F0aW9uX3RpbWVzdGFtcCI6IjIwMTgxMjE0MTA1MCIKICAgIH0KICB9Cn0=

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

Ранее поддержанные параметры

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

Описание этих параметров также представлено в разделе Параметры открытия платежной страницы Payment Page.

Информация о результате платежа передается от платежной платформы в веб-сервис в оповещении стандартного формата, описание которого представлено в разделе Оповещения (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...=="
}