В главное меню

API интерфейс


Введение

Документация описывает процесс интеграции с платежным шлюзом с использованием клиентских интерфейсов интернет-магазина.

Любая интеграция без использования клиентских интерфейсов Оплаты накладывает на вызывающую витрину продукта (сайта, мобильного приложения, их frontend и в некоторых случаях backend) требования по соблюдению стандарта PCI DSS. 

С требованиями стандарта можно ознакомится в статье от коллег из МТС Cloud - https://habr.com/en/company/cloud_mts/blog/279227/.

На практике к такому способу интеграции стоит прибегать только в крайних случаях, например, наличие уникальных витрин (не веб, не мобильное приложение).

Адреса сервисов

Для авторизации запросов вам потребуется сертификат авторизации backend-запросов (SSL-cert), который выдается в заявке на интеграцию.

Работа с Request-Id

В header запросах используется параметр Request-Id. Тип значения: guid.

Назначение

ID - который изменяется для каждого запроса. Если Request-id остается неизменным, относительно предыдущего и текущего запроса к одному и тому же endpoint's, то получатель гарантирует, что запрос не будет обработан более одного раза и ответ будет идентичным предыдущему.

Если по сценарию требуется выполнение одного итого же запроса более одного раза, то для выполнения данной операции - необходимо изменить Request-id.

Описание использования

Например, последовательность вызова методов, по сценарию платежа, следующая:

  1. payment/sessions/create (SecureGateway)
  2. payment/info (PublicGateway)
  3. payment/process (PublicGateway)
  4. payment/otp/resend (PublicGateway)
  5. payment/confirm (PublicGateway)
  • Если текущий запрос (набор данных) равен предыдущему, то request-id не меняется. Соответственно, если приложение вызвало payment/process, затем payment/confirm и снова вызвало payment/process, то request-id будет разный. 
  • Если приложение вызвало 2 раза подряд payment/process с разными данными, то request-id снова будет разный. А если 2 раза подряд вызвало payment/process с одинаковыми данными, то request-id будет одинаковый. Данная логика идентична для всех запросов.

Ограничение

Если в ответе предыдущего запроса был http-code = 200, то текущий запрос, даже с тем же набором параметров и значениями в них, должен быть с новым request-id.