Обзор протокола

Типы операций

В Протоколе доступны следующие операции:

Платеж токеном СБП

Пример платежа токеном СБП

Flower for my girlfriend

Выплаты

Для тестирования различных вариантов выплаты и ответов в тестовом режиме указывайте разные суммы платежа (поле amount.value):

Платежный токен

Использование платежного токена в запросе платежа

Платежные токены используются для списаний с карт или QIWI кошельков без ввода реквизитов карты или номера кошелька. Метод оплаты платежным токеном по умолчанию отключен. Чтобы подключить его, обратитесь к вашему сопровождающему менеджеру.

При оплате платёжным токеном покупатель не будет указывать свои карточные данные и проходить проверку 3-D Secure.

О выпуске платежного токена см. подробнее в этом разделе.

Чтобы инициировать платёж с оплатой платежным токеном, передайте в запросе API Платеж:

Если карта, для которой выпущен платежный токен, была уже ранее сохранена (токенизирована) на вашей стороне, должны быть добавлены дополнительные параметры в объекте paymentMethod:

Акты

Акт по принятым платежам формируется ежемесячно во второй рабочий день месяца.

Акт сначала отправляется на email, указанный при регистрации в сервисе. После подтверждения со стороны партнера, уполномоченное лицо КИВИ Банка подписывает Акт в системе документооборота электронной подписью. Подписанный Акт отправляется на юридический адрес партнера.

Формат уведомления CHECK_CARD

Пример тела уведомления CHECK_CARD

checkPaymentMethod.cardInfo.paymentSystem Тип платежной системы String
checkPaymentMethod.cardInfo.fundingSource Тип карты String
checkPaymentMethod.cardInfo.paymentSystemProduct Категория карты String
checkPaymentMethod.createdToken Объект с информацией о платежном токене, выпущенном вместе с проверкой карты Object
checkPaymentMethod.createdToken.token Строка платежного токена String
checkPaymentMethod.createdToken.name Маскированный PAN карты, для которой выпущен платежный токен String
checkPaymentMethod.createdToken.expiredDate Дата окончания срока действия платежного токена. Формат даты соответствует стандарту ISO-8601:ГГГГ-ММ-ДДTчч:мм:сс±чч:мм String
checkPaymentMethod.createdToken.account Идентификатор покупателя, указанный при выпуске платежного токена String
checkPaymentMethod.merchantSiteUid Строковый идентификатор сайта ТСП в QIWI Кассе String
type Тип уведомления — только CHECK_CARD String
version Версия уведомлений String
## Завершение аутентификации при проверке карты
Пример завершения аутентификации при проверке карты
## Сплитование платежей
Сплитование платежей — решение, разработанное специально для маркетплейсов. Сплитование платежей позволяет рассчитываться с несколькими поставщиками товаров/услуг, производя одно списание с карты покупателя.
Чтобы подключить сплитование платежей, обратитесь к вашему сопровождающему менеджеру и запросите подключение решения.
## Получение QR-кода СБП
Пример получения QR-кода СБП (метод POST) Flower for my girlfriend
### Метод PUT
Пример получения QR-кода СБП (метод PUT) Flower for my girlfriend
## Как использовать сервис через API
Пример запроса проверки карты
Пример тела успешного ответа
Пример тела ответа с проверкой 3DS
Some string pareq
Пример тела ответа с ошибкой проверки
Пример запроса завершения 3DS при проверке карты
Some string pares
Чтобы убедиться, что номер карты ввел именно держатель карты, можно использовать дополнительную аутентификацию покупателя 3-D Secure. Включение/отключение 3DS производится на стороне QIWI через Службу поддержки. Если 3DS включен, то в ответе на запрос проверки карты вы получите объект requirements с ACS URL для перенаправления покупателя (в поле status будет значение WAITING_3DS).
Сценарий дополнительной аутентификации аналогичен операции покупки:
После завершения проверки вам придет уведомление CHECK_CARD с результатом. Также вы можете всегда запросить текущий статус проверки.
## Статусы операций
Статус операции отражает ее текущее состояние.
### Ответы API
API возвращает синхронный статус операции в поле status.value.
В таблице перечислены возможные статусы и типы операций, в которых эти статусы используются.
Тип операции Статус операции Описание статуса
PAYMENT WAITING Ожидание 3DS авторизации
PAYMENT DECLINED Запрос авторизации отклонен (в синхронном ответе)
PAYMENT DECLINE Запрос авторизации отклонен (в асинхронном ответе)
PAYMENT COMPLETED Запрос авторизации успешно обработан
CAPTURE DECLINE Запрос подтверждения отклонен

## CAPTURE DECLINED
Запрос подтверждения отклонен (в ответе API на запрос статуса)
## CAPTURE COMPLETED
Запрос подтверждения успешно обработан
## REFUND DECLINE
Запрос возврата отклонен
## REFUND COMPLETED
Запрос возврата успешно обработан
## PAYOUT WAITING
Выплата принята в обработку
## PAYOUT INIT
Инициализация выплаты при двушаговом сценарии
## PAYOUT DECLINED
Выплата отклонена
## PAYOUT COMPLETED
Выплата успешно проведена
## PAYMENT SUCCESS
Запрос авторизации успешно обработан
## CAPTURE SUCCESS
Запрос подтверждения успешно обработан
## REFUND SUCCESS
Запрос возврата успешно обработан
## PAYOUT SUCCESS
Выплата успешно проведена
## Оплата через СБП
Протокол приема платежей поддерживает списание средств с покупателя через Систему быстрых платежей (СБП). Через СБП можно выполнять платежи в пользу юридических лиц, в том числе с использованием QR-кодов.
По умолчанию прием оплаты через СБП отключен. Чтобы подключить этот способ оплаты, обратитесь к вашему сопровождающему менеджеру.
Пример тела запроса для платежа через СБП
Пример ответа с QR-кодом
При оплате через СБП покупатель сканирует QR-код и получает ссылку на платеж, которую можно открыть в приложении своего банка.
Для выпуска QR-кода СБП отправьте запрос API Получение QR-кода СБП. В запросе укажите:
В ответе на запрос в объекте qrCode содержатся данные QR-кода:
### Статус платежа через СБП
После перехода платежа в финальный статус вы получите уведомление с указанным в исходном запросе идентификатором выпуска QR-кода в поле qrCodeUid. Актуальный статус платежа по идентификатору платежа paymentId из уведомления можно получить через API.
### Статус QR-кода
Пример ответа на запрос статуса QR-кода
Используйте запрос Статус QR-кода СБП. В ответе возвращается информация о QR-коде, в том числе его текущий статус. Так вы можете определить действует ли QR-код.
### Оплата токеном через СБП
Пример тела запроса оплаты токеном СБП
О выпуске платежного токена читайте подробнее в этом разделе.
Воспользуйтесь методом API Платеж токеном СБП и передайте в запросе:
### Тестирование оплаты СБП
См. информацию в этом разделе.
## Возвраты по оплаченным счетам
Чтобы сделать возврат средств по оплаченному счету, используйте запрос API Возврат по платежу.
## Интеграция с Платёжной формой мерчанта
Чтобы отправить платёж со сплитованием, передайте в запросе API Платёж JSON-массив paymentSplits с данными поставщиков.
Пример платежа со сплитованием
Пример ответа на платеж со сплитованием
Товар из корзины
**Формат массива paymentSplits в запросе:**
| Название | Тип | Описание |
| ------------ | ------ | ---------------------------------------- |
| paymentSplits| Array | Массив данных о поставщиках |
| type | String | Тип передаваемых данных. Доступные значения: MERCHANT_DETAILS (данные поставщика) |
| siteUid | String | ID поставщика |
| splitAmount | Object | Возмещение поставщику |
| value | Number | Сумма возмещения, округленная в меньшую сторону до 2 десятичных знаков |
| currency | String | Буквенный код валюты возмещения по ISO. Доступен только RUB |
| orderId | String | Номер заказа (необязательный) |
В объекте paymentSplits ответа содержатся данные о принятых платежах и комиссиях:
Поле ответа | Тип | Описание
-------------|--------|---------
пример | данных | о платежах и комиссиях

paymentSplits Array Массив с данными о принятых платежах
type String Тип передаваемых данных. Всегда возвращается строка MERCHANT_DETAILS
splitAmount Object Данные о возмещении поставщику
value String Сумма возмещения
splitCommissions Object Данные о комиссии (необязательный)
merchantCms Object Данные о комиссии с поставщика
value String Сумма комиссии
currency String(3) Буквенный код валюты комиссии по ISO
## Операция возврата
Пример возврата по платежу
## Формат реестра
Пример фрагмента реестра
Файл реестра формируется в формате CSV.
Поле реестра Описание
BANK_DATA_DOC Дата документа, влияющего на баланс банковского счета, по этой дате составляется Акт в конце месяца
BANK_VALUE_DOC Дата фактического изменения баланса счета в банке
BANK_AGR_CODE Банковский код, уникальный номер документа
SUM_BANK Сумма документа
TRANS_DATE Дата создания операции
TRANSACTION_ID Номер операции
SUM Сумма операции
COMMISSION Комиссия за проведение операции с мерчанта
ID Номер операции paymentId на стороне мерчанта
MERCH ID мерчанта
MERCH_SITE siteId мерчанта
PARENT_TRANSACTION_ID Для возвратов указывается номер исходной операции платежа
BILL ID выставленного счета
PURPOSE Тип проводки CHARGEBACK/ REVERT_CHARGEBACK/ Оплата/ Возврат/ OPERATION+/ OPERATION-/ SETTLEMENT
MERCHANT_SITE_NAME URL сайта мерчанта
PAYMENT_METHOD_TYPE Метод оплаты: Bank card/ QIWI_WALLET/ SBP
ММВБ Курс ММВБ на момент оплаты для валютных операций
CLIENT_AMOUNT Сумма списания с покупателя
CLIENT_CUR_CODE Валюта списания с покупателя
SETTLEMENT_AMOUNT Сумма платежного поручения, отправленного на расчетный счет партнера
PAYMENTDETAILS Назначение платежного поручения, отправленного на расчетный счет партнера (Пример: Перевод принятых денежных средств по Договору **** от ***. *** НДС не облагается/облагается)
## Коды ошибок
Протокол приема платежей использует для запросов API следующие HTTP-коды ошибок:
Код ошибки Описание
400 Bad Request — Ваш запрос некорректен (ошибка в данных или в формате запроса).
401 Unauthorized — Неправильный ключ доступа к API.
403 Forbidden — Доступ к API запрещен.
404 Not Found — Указанный ресурс не найден.
405 Method Not Allowed — Для создания платежа использовался неправильный метод.
406 Not Acceptable — Формат данных отличается от JSON.
410 Gone — Запрашиваемый ресурс удален.
429 Too Many Requests — Слишком много запросов.
500 Internal Server Error — Внутренняя ошибка сервиса. Если тело ответа пустое, повторите запрос с теми же параметрами. Если тело ответа не пустое, выполните запрос статуса платежа или статуса счета.
502 Bad Gateway — Нет связи с сервисом
503 Service Unavailable — Сервер временно недоступен по техническим причинам, попробуйте позже.
## Выплата
some comment for payout operation
Incorrect payout amount
## Проверка карты
Пример проверки карты
## Реестры
Реестр операций отправляется после 14:00 МСК по рабочим дням, содержит информацию только об успешных платежах, обработанных банком. Реестр полностью соответствует Акту.

Реестр отправляется на email, указанный при регистрации в сервисе, во вложенном в письме zip-архиве.

Платеж через форму мерчанта

При подключении платежей через собственную платежную форму по умолчанию доступен только способ оплаты Банковские карты. Другие способы оплаты доступны по запросу:

Подтверждение платежа

Пример подтверждения платежа

Обзор протокола

Протокол приема платежей предоставляет быстрые и безопасные решения для приема и отправки платежей в интернете. Протокол дает вашим покупателям возможность использовать разнообразные методы платежей, включая:

Формат взаимодействия

API Протокола приема платежей основано на принципах REST-архитектуры. Данные и методы считаются ресурсами, которые доступны через вызов универсальных идентификаторов ресурсов (URI).

Методы API вызываются через HTTP-запросы. Постоянная часть URL-адреса для вызова методов API:

Параметры методов помещаются в JSON-тело запроса. В GET-запросах параметры помещаются в query запроса.

Необходимо указывать Accept: application/json в заголовках запроса — API всегда возвращает ответ в формате JSON.

Методы API обеспечивают логическую идемпотентность, т. е. многократный вызов метода эквивалентен однократному. Однако ответ сервера может меняться (например, состояние счёта может измениться между запросами).

Статус счета

Пример запроса статуса счета

"Детская футбольная школа «Тигры»""Детская футбольная школа «Тигры»""Детская футбольная школа «Тигры»"

Банковская карта

Протокол приема платежей поддерживает как двухшаговый платеж с холдированием средств на карте покупателя, так и одношаговый платеж без авторизации покупателя.

Создание платежа

Пример платежа с холдированием (двухшаговый платеж)

Пример платежа с немедленной оплатой (одношаговый платеж)

Чтобы инициировать платеж с предварительным холдированием средств на карте (двухшаговый платеж), передайте в запросе API Платеж:

Если карта, указанная клиентом, была ранее сохранена (токенизирована) на вашей стороне, должны быть добавлены дополнительные параметры в объекте paymentMethod:

В двухшаговом платеже возмещение формируется только после подтверждения платежа.

Ожидание аутентификации покупателя (3-D Secure)

Пример ответа с требованием аутентификации покупателя

Перенаправление для аутентификации 3-D Secure

Завершение аутентификации покупателя

Если требуется 3-D Secure аутентификация покупателя, в ответе на запрос платежа добавляется объект requirements.threeDS с полями:

Для дополнительной проверки покупателя у эмитента выполните POST-запрос на URL сервера аутентификации 3-D Secure с параметрами:

Чтобы сохранять обратную совместимость, использование протокола 3-D Secure 1.0 или 3-D Secure 2.0 не влияет на вашу интеграцию с API.

Далее информация о покупателе передаётся в платежную систему карты. Банк-эмитент либо предоставляет разрешение на списание средств без аутентификации (frictionless flow), либо принимает решение о необходимости аутентификации с помощью одноразового пароля (challenge flow). После прохождения проверки покупатель перенаправляется по адресу TermUrl с зашифрованным результатом проверки в параметре PaRes.

Чтобы завершить аутентификацию покупателя, передайте в запросе API Завершение аутентификации клиента:

Это действие требуется только для двухшагового платежа с холдированием.

Чтобы подтвердить платеж:

Интеграция c Платежной формой QIWI без использования API

Для мерчантов доступна интеграция без использования методов платежного API.

Параметры счета необходимо передать в ссылке на Платежную форму — см. ниже примеры и список параметров. Когда покупатель открывает ссылку, ему автоматически выставляется счет и отображается Платежная форма.

При оплате счета, выставленного таким способом, аутентификация покупателя и ее завершение выполняются автоматически (без участия мерчанта). Так как используется двухшаговая схема (авторизация платежа и подтверждение), то платеж необходимо подтвердить через Личный кабинет. Сервис QIWI ожидает подтверждения платежа в течение 72 часов. По истечении срока выполняется автоматическое подтверждение платежа.

Ссылка на форму с передачей суммы платежа

Ссылка на форму без указания суммы платежа (сумму заполняет покупатель)

Параметр ссылки Описание Тип

publicKey Обязательный параметр. Ключ идентификации мерчанта, уникальный для каждого siteId. Ключ можно получить в Личном кабинете в разделе Настройки. String

billId Уникальный идентификатор счета в системе мерчанта. Генерируется на вашей стороне любым способом как уникальная последовательность букв, цифр и символов _, -. Если не указан, то при каждом переходе по ссылке создается новый счет. URL-закодированная строка String(200)

amount Сумма покупки, округленная в меньшую сторону до 2 десятичных знаков (всегда в рублях) Number(6.2)

currency Код валюты покупки. Возможные значения: RUB, EUR, USD. По умолчанию RUB String(3)

phone Номер телефона покупателя (в международном формате) URL-закодированная строка

email E-mail покупателя URL-закодированная строка

successUrl URL для возврата на сайт мерчанта в случае успешной оплаты. Ссылку необходимо указывать в кодировке UTF-8. URL-закодированная строка

paymentMethod Платежный метод, предлагаемый покупателю по умолчанию на платежной форме. Возможные значения: CARD, SBP, QIWI_WALLET. Если указанный метод недоступен мерчанту, отображается другой доступный. По умолчанию — CARD. String

readonly_extras Список дополнительных полей, которые должны быть недоступны для изменения покупателем на платежной форме Строка, разделитель имен полей ,. Пример: cf1,cf3

Платеж через форму QIWI

При подключении платежей через форму QIWI покупателю доступен только способ оплаты банковскими картами. Другие способы оплаты включаются по запросу:

Чтобы выполнить платеж через форму QIWI, выставите счет покупателю. Воспользуйтесь выставлением счета через API или перенаправьте покупателя на форму QIWI по прямой ссылке с параметрами счета.

Выпуск платежного токена карты

Пример запроса выставления счета с выпуском платежного токена

Пример запроса платежа с выпуском платежного токена

Пример тела ответа с платежным токеном

Для выпуска платежного токена карты вы можете использовать два способа:

Подробнее о том, как использовать платежный токен, см. ссылки:

Процесс платежа

Чтобы создать платеж, передайте в запросе API Платеж:

Статусы проверки карты

Статус Описание

INIT Сгенерирована ссылка на проверку карты, но клиент еще ей не воспользовался

SUCCESS Проверка выполнена успешно

ERROR Ошибка во время проверки

WAITING_3DS Ожидание завершения проверки 3-D Secure

Статус выплаты

Пример запроса статуса выплаты

Передача чека (54-ФЗ)

Для работы по 54-ФЗ Протокол приема платежей предоставляет инструмент для взаимодействия с вашей онлайн-кассой. Информация для формирования фискального чека передается в JSON-объекте cheque в операциях API выставления счета, платежа и возврата.

Для активации сервиса формирования фискального чека сообщите вашему сопровождающему менеджеру номер ИНН, с которым ваша организация зарегистрирована в сервисе по аренде онлайн-касс.

Если используется Атол, то дополнительно предоставьте сведения:

Фискальный чек по успешной операции отправляется в синхронном ответе на указанные запросы API и в уведомлении об операции в объекте chequeData.

Статус проверки карты

Пример запроса статуса проверки карты

Формат уведомления CAPTURE

Пример тела уведомления CAPTURE

capture Описание операции подтверждения Object

capture.type Тип операции — только CAPTURE String(200)

capture.paymentId Идентификатор платежа в системе ТСП String(200)

capture.captureId Идентификатор подтверждения в системе ТСП String(200)

capture.createdDateTime Дата создания операции URL-закодированная строкаГГГГ-ММ-ДДTчч:мм:ссZ

capture.amount Информация о сумме операции Object

capture.amount.value Сумма операции, округленная до двух десятичных знаков в меньшую сторону Number(6.2)

capture.amount.currency Идентификатор валюты операции (Alpha-3 ISO 4217 код) String(3)

capture.billId ID счета, соответствующего операции String(200)

capture.status Информация о статусе операции Object

capture.status.value Строковое значение статуса String

capture.status.changedDateTime Дата обновления статуса URL-закодированная строкаГГГГ-ММ-ДДTчч:мм:ссZ

capture.status.reasonCode Код причины отклонения String(200)

capture.status.reasonMessage Описание причины отклонения String(200)

capture.status.errorCode Код ошибки Number

capture.paymentMethod Информация о средстве платежа Object

capture.paymentMethod.type Тип метода оплаты String

capture.paymentMethod.maskedPan Маскированный PAN карты String

capture.paymentMethod.rrn RRN платежа (по ISO 8583) Number

capture.paymentMethod.authCode Auth-code платежа Number

capture.merchantSiteUid Строковый идентификатор сайта ТСП в QIWI Кассе String

capture.customer Информация о покупателе Object

capture.customer.phone Номер телефона покупателя String

capture.customer.email E-mail покупателя String

capture.customer.account Идентификатор покупателя в системе ТСП String

capture.customer.ip IP адрес покупателя String

capture.customer.country Страна адреса покупателя String

capture.customFields Поля с произвольной информацией, дополняющей данные по операции Object

capture.customFields.cf1 Поле с произвольной информацией, дополняющей данные по операции String(256)

capture.customFields.cf2 Поле с произвольной информацией, дополняющей данные по операции String(256)

capture.customFields.cf3 Поле с произвольной информацией, дополняющей данные по операции String(256)

capture.customFields.cf4 Поле с произвольной информацией, дополняющей данные по операции String(256)

capture.customFields.cf5 Поле с произвольной информацией, дополняющей данные по операции String(256)

capture.flags Дополнительные команды, переданные в API Array(Strings). Возможные элементы: SALE, REVERSAL

capture.settlementAmount Сведения о сумме расчёта с мерчантом Object Если валюта платежа и расчёта с мерчантом различаются

capture.settlementAmount.value Сумма расчёта с мерчантом Number(6.2) Если валюта платежа и расчёта с мерчантом различаются

capture.settlementAmount.currency Идентификатор валюты расчёта с мерчантом (Alpha-3 ISO 4217 код) String(3) Если валюта платежа и расчёта с мерчантом различаются

type Тип уведомления — только CAPTURE String

Настройка Платежной формы

Внешний вид Платежной формы можно настроить в соответствии с вашим стилем, включая лого, фон и цвет кнопок. Для этого обратитесь в Службу поддержки и предоставьте следующую информацию:

Необязательные данные для настройки:

Пример передачи параметра стиля при выставлении счета через API

Чтобы применить ваш стиль на Платежной форме:

Название псевдонима стиля регистрозависимое.

Пример применения настройки к Платежной форме:

Получение списка платежей по счету

Пример запроса на получение списка платежей по счету

Тестирование проведения операций

При подключении идентификатор сайта партнёра siteId находится в тестовом режиме. В этом режиме партнёр может проводить операции без списания средств с банковской карты. Также можно запросить переключение в режим тестирования любого siteId партнёра, либо добавление нового siteId в режиме тестирования через сопровождающего менеджера.

Для операций в тестовом режиме используются стандартные URL API Протокола.

Тестовый режим для метода оплаты с баланса КИВИ Кошелька не предусмотрен.

Когда интеграция на вашей стороне закончена, служба поддержки QIWI переводит siteId в производственный режим. В этом режиме выполняются реальные списания денежных средств с карт.

При переходе в производственный режим перевыпускать ключ доступа к API не нужно.

При необходимости измените постоянный URL для обработки уведомлений с тестового (например, https://your-shop-test.ru/callbacks) на производственный (например, https://your-shop-prod.ru/callbacks) в Личном кабинете.

Возмещение

По умолчанию, возмещение по проведенным операциям производится раз в 2 дня и минимальным порогом 10.000 рублей. Если вам необходимо особое расписание, обратитесь к вашему сопровождающему менеджеру.

КИВИ взимает комиссию за каждую подтвержденную операцию. Если отмена операции была произведена до подтверждения, комиссия не взимается. Если была произведена частичная отмена до подтверждения операции, комиссия будет пересчитана.

Возвраты и отмены

Операции возврата и отмены доступны не для всех способов платежей:

При возврате платежа комиссия QIWI за проведение платежа не возвращается. Исключение — если при возврате платежа выполнена операция отмены. В этом случае финансовой операции (списания средств со счета покупателя) не происходит и комиссия не взимается.

Уведомления по сплитованным операциям

Уведомления по сплитованным платежам и по возвратам сплитованных платежей формируются аналогично описанным выше ответам на запросы API:

Способы подключения

Протокол приема платежей поддерживает несколько вариантов взаимодействия:

ChequeData

Информация о фискальном чеке по операции.

Имя Описание Тип

id Идентификатор чека String

url Информация о чеке (URL-ссылка) String

Серверные уведомления

Уведомление от QIWI — это входящий POST-запрос с информацией о событии. Тело запроса содержит JSON-сериализованные данные платежа/счета (кодировка UTF-8).

Протокол поддерживает следующие типы уведомлений о событиях API:

Адрес вашего сервера для обработки уведомлений указывается в Личном кабинете в разделе Настройки.

Чтобы указать URL сервера обработки уведомлений для отдельной операции, используйте параметры:

URL для уведомлений должен начинаться с https, так как уведомления отправляются по протоколу HTTPS на порт 443. URL должен быть доступен из Интернета.

Сертификат сайта должен быть выпущен доверенным центром сертификации (например Comodo, Verisign, Thawte и т.п.).

Уведомление считается успешно доставленным, если ваш сервер ответил HTTP кодом состояния 200 OK.

Термины и сокращения

Ключ доступа к API — Символьная строка для авторизации мерчанта в API согласно стандарту OAuth 2.0 RFC 6749 RFC 6750.

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

API: Application Programming Interface — набор готовых методов, предоставляемых приложением (системой) для использования во внешних программных продуктах.

REST: Representational State Transfer — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

JSON: JavaScript Object Notation — текстовый формат обмена данными, основанный на JavaScript RFC 7159.

3DS: 3-D Secure — протокол защиты карточных данных, используемый для аутентификации держателя банковской карты во время совершения платежной операции через интернет. QIWI поддерживает как версию 3DS 1.0, так и версию 3DS 2.0 протокола.

ТСП, Мерчант — Торгово-сервисное предприятие.

MPI: Merchant Plug-In — модуль, выполняющий 3DS аутентификацию покупателя.

PCI DSS: Payment Card Industry Data Security Standard — стандарт безопасности данных индустрии платёжных карт, учреждённым международными платёжными системами Visa, MasterCard, American Express, JCB и Discover.