И 3DS1, и 3DS2 доступны для сквозной интеграции резервирования в Центре действий. Вы можете реализовать любой из них (или оба) для своей интеграции.
Либо 3DS1, либо 3DS2 будут соответствовать требованиям строгой аутентификации клиентов PSD2, но есть некоторые ключевые различия:
- 3DS1 : вы можете активировать 3DS1 для транзакции, когда у вас есть сигналы о том, что списание является мошенническим.
- Внедрение 3DS1 требует изменений на вашем сервере бронирования .
- 3DS2 : 3DS2 будет использоваться только для транзакций, в которых применяется PSD2 (банк-эквайер и банк клиента находятся в ЕЭЗ).
- Внедрение 3DS2 требует внесения изменений в ваш фид продавца .
Реализация 3DS2
Реализация 3DS2 требует от вас добавления дополнительных полей в фид продавца в сообщении TokenizationConfig
. Если все платежи поступают на один и тот же счет, вы будете повторять значение в каждой записи продавца. Если платежи поступают на разные счета, значения в каждой записи продавца должны относиться к счету, получающему средства в рамках транзакции.
Изменения в фиде продавцов
-
merchant_of_record_name
: Имя зарегистрированного продавца (MOR). Это видимое пользователю имя будет отображаться в испытаниях 3DS2. -
payment_country_code
: Страна, в которой будет обработана транзакция, в форме ISO 3166-1 альфа-2. - Сообщение
CardNetworkParameters
: это сообщение повторяется со значениями, специфичными для разных сетей (требуется только для Visa и American Express).-
card_network
: сеть (Visa, American Express), к которой применяются эти значения. -
acquirer_bin
: банковский идентификационный номер банка-эквайера, используемого для обработки карты. -
acquirer_merchant_id
: идентификатор продавца, назначенный эквайером продавцу для использования при авторизации транзакции (для транзакций Visa и American Express).
-
Добавив эти поля в свой фид продавца, вы получите криптограмму 3DS2 в unparsed_payment_method_token
, полученном вашим сервером бронирования всякий раз, когда PSD2 применяется к транзакции. Вы должны передать unparsed_payment_method_token
и встроенную в него криптограмму своему партнеру по обработке в соответствии с его спецификацией.
Внедрение 3DS1
Изменения на сервере бронирования
Мы отправим запрос CreateBooking
, и если вы определите, что для транзакции необходим 3DS1, вернем Booking Failure
из вашего метода CreateBooking
и укажем PAYMENT_REQUIRES_3DS1
в качестве причины. В этом ответе об ошибке вам также необходимо будет указать сообщение ThreeDS1Parameters
в сообщении PaymentFailureInformation
:
-
acs_url
= URL-адрес, с которого можно загрузить форму, которая будет предоставлена пользователю для аутентификации. -
pa_req
= Запрос аутентификации платежа. Будет опубликовано в форме ACSUrl. -
transaction_id
= идентификатор, используемый поставщиком ACS. Будет опубликовано в форме ACSUrl. -
md_merchant_data
= Данные для Центра действий, которыми можно поделиться с поставщиком ACS, если они предоставлены.
Затем мы повторно отправим исходный запрос CreateBooking
с pa_response
, расположенным в сообщении PaymentInformation . Поле pa_response
будет содержать полезную нагрузку, возвращаемую нам от поставщика ACS, и вы должны использовать его для авторизации транзакции с вашим процессором.
Вот диаграмма, описывающая поток 3DS1:
![Рисунок 1: Схема процесса 3DS1](https://google-developers.gonglchuangl.net/static/actions-center/images/guides/payments_3ds1.png?authuser=0&hl=ru)