И 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:
