Создание инстанса Т-Кассы

Метод инициирует привязку счета клиента к магазину и возвращает информацию о нем

Для Мерчантов с PCI DSS
Метод инициирует привязку карты к клиенту. В случае успешной привязки переадресует клиента на Success Add Card URL, в противном случае на Fail Add Card URL. Можно использовать форму Т‑Кассы, возможно заменить на кастомную форму.

Регистрирует клиента в связке с терминалом

Возможна автоматическая привязка клиента и карты, по которой был совершен платеж, при передаче параметра CustomerKey в методе Init. Это можно использовать для сохранения и последующего отображения клиенту замаскированного номера карты, по которой будет совершен рекуррентный платеж

Для Мерчантов с PCI DSS
Завершает привязку карты к клиенту. В случае успешной привязки переадресует клиента на Success Add Card URL в противном случае на Fail Add Card URL. Для прохождения 3DS второй версии перед вызовом метода должен быть вызван /v2/check3dsVersion и выполнен 3DS Method, который является обязательным при прохождении 3DS по протоколу версии 2.0.

Отменяет платежную сессию. В зависимости от статуса платежа переводит его в следующие состояния:

• NEW — CANCELED
• AUTHORIZED — PARTIAL_REVERSED — если отмена не на полную сумму;
• AUTHORIZED — REVERSED — если отмена на полную сумму;
• CONFIRMED — PARTIAL_REFUNDED — если отмена не на полную сумму;
• CONFIRMED — REFUNDED — если отмена на полную сумму.

Для платежей «в Рассрочку» отмена доступна только из статуса AUTHORIZED
Для платежей «Долями» если операция в статусе CONFIRMED или PARTIAL_REFUNDED будет осуществлен частичный либо полный возврат
Если платеж находился в статусе AUTHORIZED производится отмена холдирования средств на карте клиента. При переходе из статуса CONFIRMED — возврат денежных средств на карту клиента

Схема проведения рекуррентного платежа

Описание

Осуществляет рекуррентный (повторный) платеж — безакцептное списание денежных средств со счета банковской карты клиента. Для возможности его использования клиент должен совершить хотя бы один платеж в пользу Мерчанта, который должен быть указан как рекуррентный (см. параметр Recurrent методе Init), фактически являющийся первичным. По завершении оплаты в нотификации на AUTHORIZED или CONFIRMED будет передан параметр RebillId.
В дальнейшем для совершения рекуррентного платежа Мерчант должен вызвать метод Init, указать нужную сумму для списания в параметре Amount, а затем без переадресации на PaymentURL вызвать метод Charge для оплаты по тем же самым реквизитам и передать параметр RebillId, полученный при совершении первичного платежа.
Метод Charge работает по одностадийной и двухстадийной схеме оплаты. Чтобы перейти на двухстадийную схему нужно переключить терминал в Личном кабинете, а также написать обращение на acq_help@tinkoff.ru с просьбой переключить схему рекуррентов.

По умолчанию метод Charge отключен. Для его включения на DEMO-терминале нужно написать обращение на acq_help@tinkoff.ru, а на боевом терминале — обратиться к своему персональному менеджеру

При проведении рекуррентного платежа учитывать взаимосвязь атрибута RebillId в методе /Charge с:

• Значением атрибута OperationInitiatorType в методе /Init;
• Значением атрибута Reccurent в методе /Init;
• Типом терминала, используемом для проведения операций (ECOM/AFT).

Наглядно допустимые сценарии взаимосвязи описаны в таблице:

В случае передачи значений атрибутов не соответствующих таблице — MAPI вернет ошибку 1126 (Несопоставимые значения rebillId или Recurrent с переданным значением OperationInitiatorType)

Одностадийная оплата

1. Совершить родительский платеж путем вызова Init с указанием дополнительных параметров Recurrent=Y и CustomerKey.
2. Переадресовать клиента на PaymentUrl (только для Мерчантов без PCI DSS</span>).
3. После оплаты заказа клиентом в нотификации на статус AUTHORIZED или CONFIRMED будет передан параметр RebillId, который необходимо сохранить.
4. Спустя некоторое время для совершения рекуррентного платежа необходимо вызвать метод Init со стандартным набором параметров (параметры Recurrent и CustomerKey здесь не нужны).
5. Получить в ответ на Init параметр PaymentId.
6. Вызвать метод Charge с параметром RebillId, полученным в п.3, и параметром PaymentId, полученным в п.5. При успешном сценарии операция перейдет в статус CONFIRMED.

Двухстадийная оплата

1. Совершить родительский платеж путем вызова Init с указанием дополнительных параметров Recurrent=Y и CustomerKey.
2. Переадресовать клиента на PaymentUrl (только для Мерчантов без PCI DSS</span>).
3. После оплаты заказа клиентом в нотификации на статус AUTHORIZED или CONFIRMED будет передан параметр RebillId, который необходимо сохранить.
4. Спустя некоторое время для совершения рекуррентного платежа необходимо вызвать метод Init со стандартным набором параметров (параметр Recurrent и CustomerKey здесь не нужны).
5. Получить в ответ на Init параметр PaymentId.
6. Вызвать метод Charge с параметром RebillId, полученным в п.3, и параметром PaymentId, полученным в п.5. При успешном сценарии операция перейдет в статус AUTHORIZED. Денежные средства будут заблокированы на карте клиента.
7. Вызвать метод Confirm для подтверждения платежа.

Проведение платежа по привязанному счету по QR через СБП. Для возможности его использования клиент должен совершить успешную привязку счета с помощью метода AddAccountQr. После вызова метода будет отправлена нотификация на Notification URL о привязке счета , в которой будет указан AccountToken. Для совершения платежа по привязанному счету Мерчант должен вызвать метод Init, в котором поля Recurrent= Y и DATA= {“QR”:“true”}, а затем вызвать метод ChargeQr для оплаты по тем же самым реквизитам и передать параметр AccountToken, полученный после привязки счета по QR в нотификации.

Для Мерчантов с PCI DSS
Проверяет поддерживаемую версию 3DS протокола по карточным данным из входящих параметров

При определении второй версии, возможно в ответе получение данных для прохождения дополнительного метода 3DS Method, который позволяет эмитенту собрать данные браузера клиента — это может быть полезно при принятии решения в пользу Frictionless Flow (аутентификация клиента без редиректа на страницу ACS)

Метод возвращает статус заказа

Метод для списания заблокированных денежных средств. Используется при двухстадийном проведении платежа. Применим только к платежам в статусе AUTHORIZED. Статус транзакции перед разблокировкой выставляется в CONFIRMING. Сумма списания может быть меньше или равна сумме авторизации.

Подробнее про двухстадийный платеж можно прочитать в разделе Сценарии платежа — "Двухстадийный платеж"

Рассказать о пришедшем событии

Для Мерчантов с PCI DSS
Метод подтверждает платеж передачей реквизитов, а также списывает средства с карты клиента при одностадийной оплате и блокирует указанную сумму при двухстадийной. Используется, если у площадки есть сертификация PCI DSS и собственная платежная форма

Метод возвращает список привязанных счетов клиента по магазину

Метод возвращает статус привязки счета клиента по магазину

Для мерчантов с PCI DSS
Метод возвращает статус привязки карты

Возвращает список всех привязанных карт клиента, включая удаленные

Справку по конкретной операции можно получить на:
1. URL-сервиса, развернутого на своей стороне.
2. Электронную почту.
Для формирования токена необходимо использовать только PASSWORD</b> и TERMINAL_KEY</b>

Возвращает данные клиента, сохраненные в связке с терминалом

Получение deeplink с включенным подписанным JWT-токеном. Предназначен для запроса по API

Возвращает статус возврата платежа по СБП

Метод регистрирует QR и возвращает информацию о нем. Должен быть вызван после вызова метода Init

Метод возвращает статус платежа

Метод определяет доступность методов оплаты на терминале для SDK и API. Запрос не шифруется токеном

Метод инициирует платежную сессию

Метод получения Link для безусловного редиректа на мобильных устройствах

Слушатель webhook события (нотификации)

Метод получения QR для десктопов

Метод возвращает список участников куда может быть осуществлен возврат платежа, совершенного по QR

Метод удаляет привязанную карту клиента

Удаляет сохраненные данные клиента

Метод получения QR для десктопов

Получение ссылки

Тестовая платежная сессия с предопределенным статусом по СБП

Метод позволяет отправить закрывающий чек в кассу. Условия работы метода:

1. Закрывающий чек может быть отправлен если платежная сессия по первому чеку находится в статусе CONFIRMED.
2. В платежной сессии был передан объект Receipt.
3. В объекте Receipt был передан хотя бы один объект Receipt.Items.PaymentMethod = full_prepayment или prepayment или advance.

Метод определения возможности проведения платежа T‑Pay на терминале и устройстве

Для Мерчантов с PCI DSS
Осуществляет проверку результатов прохождения 3-D Secure и при успешном результате прохождения 3-D Secure подтверждает инициированный платеж. При использовании одностадийной оплаты осуществляет списание денежных средств с карты клиента.
При двухстадийной оплате осуществляет блокировку указанной суммы на карте клиента

Формат запроса: x-www-form-urlencoded

После получения на TermUrl мерчанта ответа ACS с результатами прохождения 3-D Secure необходимо сформировать запрос к методу Submit3DSAuthorization

Для Мерчантов с PCI DSS
Осуществляет проверку результатов прохождения 3-D Secure v2 и при успешном результате прохождения 3-D Secure v2 подтверждает инициированный платеж. При использовании одностадийной оплаты осуществляет списание денежных средств с карты клиента. При двухстадийной оплате осуществляет блокировку указанной суммы на карте клиента.

Формат запроса: x-www-form-urlencoded

После получения на cresCallbackUrl Мерчанта ответа ACS с результатами прохождения 3-D Secure необходимо сформировать запрос к методу Submit3DSAuthorizationV2

Метод предназначен для подтверждения карты путем блокировки случайной суммы

Передача уведомления о событии платежного виджета T‑Pay + T‑ID