Оплата с помощью собственного MPI/3DS Server

Merchant Plugin Interface (MPI)/3DS Server — это компонент технологии 3D Secure, который может быть реализован в платежном шлюзе или на вашей стороне. Если у вас есть собственный MPI/3DS Server, вы можете использовать его для самостоятельной авторизации 3D Secure, а в API-запросах лишь указывать факт проведения такой авторизации. Чтобы включить эту функциональность, обратитесь в службу технической поддержки.

Если вы используете собственный MPI/3DS Server, то в платежных запросах (например, paymentOrder.do, paymentOrderBinding.do или instantPayment.do) передавайте дополнительные параметры в блоке jsonParams: eci, cavv, xid, threeDSProtocolVersion, и authenticationTypeIndicator. Эти параметры описаны ниже.

Параметры для собственного MPI/3DS Server

eci

eci — индикатор электронной коммерции (ECI), полученный от вашего сервера 3-D Secure. Показывает уровень безопасности, используемый при оплате. Выставляется DS-сервером по полученным результатам аутентификации и в соответствии с особенностями процесса проверки магазина.

Коды ECI могут отличаться в зависимости от платежной системы. Ниже приводится расшифровка наиболее часто используемых ECI-кодов:

cavv, xid

Если значение ECI отличается от тех, которые используются для SSL-авторизации, также необходимо передать следующие параметры:

• cavv — значение аутентификации держателя карты;
• xid — идентификатор транзакции 3DS-аутентификации владельца карты на 3DS сервере (значение ARes.dsTransID, полученное от ACS).

threeDSProtocolVersion

Кроме того, вы можете передать в платежном запросе параметр threeDSProtocolVersion (версия протокола 3DS). Он может принимать следующие значения:

• 1.0.2 — для 3DS 1

• 2.1.0 — для 3DS 2 (поддержка на стороне МПС прекращена)

• 2.2.0 — для 3DS 2

Если в запросе не передается threeDSProtocolVersion, то по умолчанию его значение принимается равным 1.0.2 - для 3DS 1 или 2.1.0 - для 3DS 2.

authenticationTypeIndicator

Параметр authenticationTypeIndicator (тип аутентификации платежа) необходим для оплаты через ваш MPI/3DS Server с 3DS 2.

Для платежей с 3DS 1 или SSL этот параметр является необязательным и определяется автоматически в зависимости от значения ECI.

Пример запроса

curl --request POST --url 'https://api.router.rbsuat.com/v1/paymentOrder.do' \
--header 'Content-Type: application/json' \
--data-raw '{
    "userName": "test_user",
    "password": "test_user_password",
    "cardholderName": "TEST CARDHOLDER",
    "cvc": "123",
    "seToken": "RJ7Pzbt...",
    "mdOrder": "2dc811e7-8d1c-407a-bd25-a4f41f96cc60",
    "jsonParams": {
        "eci": "02",
        "cavv": "AkZO5XQAA0rhBxoaufa+MAABAAA=",
        "xid": "5010857f-8d3f-74e1-9c5a-54a000cc4110",
        "threeDSProtocolVersion": "2.2.0",
        "authenticationTypeIndicator": "5"
    }
}'

Если вы используете собственный MPI/3DS Server, ответ на соответствующий API-запрос оплаты не содержит параметров, связанных с 3D Secure, таких как redirect, termUrl, acsUrl и paReq.

Пример ответа

{
    "errorCode": 0,
    "info": "Ваш платёж обработан, происходит переадресация...",
    "is3DSVer2": false,
    "mdOrder": "d0b8ad07-0601-4afb-b5dc-605d4b9db863",
    "redirect": "https://mybestmerchanturl.com/success?orderId=d0b8ad07-0601-4afb-b5dc-605d4b9db863&lang=ru",
    "transactionState": "DEPOSITED"
}

Маршрутизация при использовании собственного MPI/3DS Server

При использовании собственного MPI/3DS Server недопустимо использование балансировки платежей между несколькими банками в заданном процентном отношении. Это ограничение связано с тем, что данный метод маршрутизации не позволяет заранее узнать, в какой банк будет направлен заказ.

Для того чтобы корректно пройти 3D Secure таким образом, чтобы данные аутентификации не расходились с данными авторизации, Партнеру нужно заранее знать, в какой банк будет маршрутизирован заказ. В запросе на аутентификацию (AReq / PAReq) содержится идентификатор мерчанта (acquirerMerchantID), который в каждом банке у Партнера разный. Если передавать один и тот же идентификатор, то платежные системы зафиксируют несоответствие, что может привести к отказу в авторизации.

Когда используются правила маршрутизации без балансировки, Партнер может узнать, в какой банк будет направлен заказ согласно правилам маршрутизации, возвращаемым в запросе /settings/getRouterParams.do. Это позволит использовать правильный acquirerMerchantID при прохождении 3DS.