diff --git a/modern-openapi.json b/modern-openapi.json index b1f1e47..c88ba76 100644 --- a/modern-openapi.json +++ b/modern-openapi.json @@ -13,7 +13,7 @@ "x-logo": { "url": "/kassa/dev/assets/img/logo.svg" }, - "description": "# Введение\n\n## Подключение интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг помогает принимать онлайн-платежи так, как удобно вам и покупателю: на сайте, в мобильном приложении, соцсетях, мессенджерах, по e-mail или СМС. Вы можете принимать оплату разными способами, возвращать и замораживать выплаты, настраивать рекуррентные платежи\n\nЧтобы подключить интернет-эквайринг, оставьте [заявку на сайте Т‑Банка](https://www.tbank.ru/kassa/) и заполните анкету компании или ИП. Подробности подключения можете узнать [в Т-Помощи](https://www.tbank.ru/business/help/business-payments/internet-acquiring/how-involve/connect/?card=q1) или у персонального менеджера\n\n## Способы интеграции интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг нужно интегрировать — настроить оплату на сайте или в приложении. Есть четыре способа интеграции:\n\n* Платежный модуль — для сайтов на CMS,\n* Платежный виджет — для самописного сайта,\n* SDK — для мобильного приложения,\n* API — для разработки своей интеграции.\n\nИнтеграцию можно выполнить самостоятельно или с помощью разработчика\n\n### Платежный модуль\n\nСпособ интеграции интернет-эквайринга с сайтом, созданным на основе CMS. Вы устанавливаете модуль — на странице сайта появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nМодуль подходит, если ваш сайт собран на CMS — например, 1С-Битрикс, WordPress или Taplink. Т‑Касса поддерживает многие популярные CMS, в некоторые уже встроены модули — их устанавливать не нужно\n\n[Инструкции по интеграции с помощью платежного модуля](https://www.tbank.ru/kassa/dev/cms/)\n\n### Платежный виджет\n\nСпособ интеграции интернет-эквайринга с самописным сайтом. Вы вставляете готовый код на страницу сайта — на этом месте появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nВиджет подходит в двух случаях:\n* ваш сайт самописный или на CMS, для которой в Т‑Банке нет платежного модуля;\n* вы не планируете принимать автоплатежи.\n\nДля интеграции виджета потребуется помощь программиста\n\n[Инструкция по интеграции с помощью виджета](https://www.tbank.ru/kassa/dev/widget/)\n\n### Мобильный SDK\nСпособ интеграции интернет-эквайринга с мобильным приложением. Покупатель оплачивает товар без перехода в мобильный браузер, оставаясь внутри вашего приложения\n\nС помощью SDK вы можете разместить платежную форму Т‑Кассы — со всеми или некоторыми способами оплаты. Также с помощью SDK вы можете отдельно встраивать способы оплаты — например, T‑Pay или СБП — в вашу платежную форму\n\nSDK подходит, если принимаете оплату в приложении на Android начиная с версии 7.0 или iOS начиная с версии 12.3. С инструкцией по подключению SDK в ЛК можно ознакомиться по ссылкам ниже:\n\n[Инструкция для Android начиная с версии 7.0](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-android)\n\n[Инструкция для iOS начиная с версии 12.3](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-ios)\n\n### API\nСамый гибкий и сложный способ интеграции интернет-эквайринга. Например, API подходит, если у вас самописный сайт и вы хотите настроить оплату под запросы бизнеса: совмещать в платежной форме разные способы оплаты, принимать рекуррентные платежи или подключать другие сервисы Т‑Кассы\n\nДля интеграции потребуется помощь программиста\n\n[Документация по API](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Rekomendacii-pri-integracii)\n\n## Платежная форма\nПлатежная форма — это готовый интерфейс с встроенными способами оплаты, который позволяет принимать платежи онлайн\n\nДля использования платежной формы необходимо подключить интернет-эквайринг, настроить терминал и интегрировать платежную форму на ваш сайт одним из способов выше(кроме SDK)\n### Платежная форма в webview\nНекоторые webview не умеют обрабатывать DeepLink ссылки. Из-за этого способы оплаты, которые осуществляют переход в мобильное приложение во время платежа (СБП, Mir Pay, T‑Pay), могут работать некорректно\n\nВ случае использования платежной формы в webview необходимо учесть особенности вашей интеграции и сделать необходимые доработки для поддержки DeepLink\n\nПо результатам доработок необходимо дополнительно протестировать корректную работу всех способов оплат. В случае обнаружения проблем, требуется связаться с разработчиками webview модуля для их устранения, либо рекомендуется отключить неработающие способы оплаты\n**Ссылки с примерами решений**:\n1. [Первое решение(java,kotlin)](https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/webview/upi-intent-android/#13-handle-deep-links-in-shouldoverrideurlloading-),\n2. [Второе решение(java)](https://stackoverflow.com/questions/25672330/how-to-enable-deep-linking-in-webview-on-android-app).\n\n#### Рекомендации по интеграции\nПлатформа IOS:\nЧтобы deeplink работал в web — есть 2 варианта решения:\n1. Использовать SFSafariViewController, он умеет открывать диплинки, дополнительная настройка не нужна.\n2. Если используете WKWebView он не умеет открывать диплинки из коробки, чтобы его научить, надо обработать открытие диплинка Т‑Банка, пример описан ниже.\n\n**Пример реализации обработки открытия диплинка Т‑Банка** \n```\nnavigationDelegate = self\nfunc webView(\n _ webView: WKWebView,\n decidePolicyFor navigationAction: WKNavigationAction,\n decisionHandler: @escaping (WKNavigationActionPolicy) -> Void\n) {\n if let url = navigationAction.request.url, let scheme = url.scheme {\n if scheme != \"https\" && scheme != \"http\" {\n UIApplication.shared.open(url)\n }\n }\n decisionHandler(.allow)\n}\n```\n\n### Платежная форма в iframe\nНе рекомендуется использовать платежную форму в iframe для мобильных версий сайтов, так как у кнопочных способов оплаты могут возникать проблемы с открытием DeepLink и переходов в мобильное приложение для оплаты (СБП, Mir Pay, T‑Pay). Это связано с тем, что Iframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe\n\nЕсли в мобильной версии сайта использование iframe обязательно, вам необходимо сделать доработки согласно инструкции ниже, чтобы вы могли использовать кнопочные способы оплаты. Она позволит произвести переход в стороннее приложение. Доработки представляют собой скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице.\n\nПосле реализации доработок необходимо протестировать корректную работу всех способов оплат. В случае проблем и вопросов вы можете обратиться в нашу поддержку acq_help@tbank.ru\n\nВ десктопной версии iframe кнопочные способы оплаты будут работать без специальных доработок\n\n
Инструкция по доработкам для mobile iframe\n
\nIframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe (переход будет внутри iframe). Чтобы произвести переход в стороннее приложение требуется скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице\n\nВ случае если у вас подключены способы оплаты, использующие deeplink, а именно: T‑Pay, СБП или Mir Pay, то в процессе оплаты может возникать ошибка\n\n##### Информация\nСкрипт общается с фреймом по средствам *window.postMessage()*\n\nДобавление скрипта решает проблему передачи ссылки на ресурс платежного сервиса, для способов оплаты использующих DeepLink. Данная проблема может возникнуть при попытке передачи ссылки в браузер Клиента, из контейнера Платежной формы расположенного в теге ``\n \n\n\n```\nДинамическая интеграция (Если iframe генерируется динамически):\n```\n
\n \n\n```\n##### Настройка\nКласс Integration принимает 2 аргумента:\n1. HTMLIFrameElement — iframe DOM элемент.\n2. config — необязательный аргумент с конфигурацией PaymentFormIntegrationConfig.\n\nPaymentFormIntegrationConfig: \n```\ninterface PaymentFormIntegrationConfig {\n iframe: {\n element: HTMLIFrameElement;\n /**\n * Используется если скрипт встраивается в промежуточный iframe\n */\n proxy?: true;\n /**\n * Вызывается в момент получения deepLink из ПФ\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n deepLinkRedirectCallback?: (url: string) => void;\n /**\n * Вызывается в момент получения exit из ПФ\n * Например при нажатии кнопки \"Вернуться в магазин\"\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n exitRedirectCallback?: (url: string) => void;\n };\n}\n```\nЕсли Вам не требуется перенаправлять родительскую страницу на возврат в магазин, а требуется просто закрыть модальное окно с платежной формой — замените этот параметр конфигурации\n\nПример инициализации скрипта с конфигурацией: \n```\nvar paymentForm = new PaymentForm.Integration({\n iframe: {\n element: document.getElementById('payment-form'),\n exitRedirectCallback: (url) => {\n // Вызов закрытия модального окна\n }\n }\n});\n```\n##### Iframe внутри iframe\nБываю случаи когда приложение используется внутри iframe, который находится внутри другого iframe. В таком случае необходимо встроить скрипт с ключом proxy: true во все промежуточные iframe.\nПример инициализации скрипта для основной страницы: \n```\n\n \n\n\n```\nПример инициализации скрипта для вложенного iframe: \n```\n\n \n\n\n```\n\"Промежуточный\" скрипт, будет перенаправлять сообщения в каждый следующий iframe\n\nКоллбеки событий будут отрабатывать вызываться в \"промежуточных\" iframe только в случае их переопределения в config\n##### Как работает скрипт\nОбщение между формой и родителем, происходит через *window.postMessage()*\n\n1. После успешной загрузки, платежная форма внутри iframe отправляет сообщение loaded родителю.\n2. После получения loaded из ПФ, скрипт отправляет сообщение ready на Платежную форму, таким образом происходит рукопожатие и платежная форма определяет что может отобразить кнопочные методы оплаты.\n3. Действиями Клиента на Платежной форме вызывается способ оплаты возвращающий DeepLink на ресурс платежного сервиса.\n4. Платежная форма, передает DeepLink в целевое окно клиента, с помощью события deepLink.\n5. Целевое окно выполняет редирект Клиента, по ссылке полученной в DeepLink, с помощью вызова *deepLinkRedirectCallback*.\n6. Аналогично передаются и другие сообщения.\n\n
\n\n### Кастомизация на платежной форме\nНа платежной форме доступна функция кастомизации, которая позволяет настроить форму под себя и своих клиентов. Для установки кастомизации обратитесь к вашему персональному менеджеру и передайте пожелания по настройкам \n\n#### Список доступных настроек кастомизации: \n|**Возможности кастомизации** | **Доп. описание**|\n|--- | ---|\n|Брендирование UI платежной формы |
  • добавлять лого своей компании на ПФ (логотип отобразится рядом с суммой заказа) 
  • управлять цветами кнопок (кнопка \"Оплатить\" и другие кнопки со страниц статусов и модальных окон)
  • |\n|Управление блоком детализации (информация о заказе и магазине) |
  • делать блок свернутым и развернутым по-умолчанию
  •  скрывать  блок с детализацией на ПФ
  • менять порядок строк в детализации
  • |\n|Управление светлой и темной темой |
  • показывать темную или светлую тему по-умолчанию
  • отключать темной/светлой темы
  • |\n\n\n\n\n## Инструкции по безопасности при интеграции\nУбедитесь, что вы используете последнюю версию интеграции, а также [генерируете и передаете корректный токен](https://www.tbank.ru/kassa/dev/payments/#section/Podpis-zaprosa) независимо от способа интеграции.
    Если ваш сайт собран на CMS, то необходимо использовать новейшую версию платежного модуля, доступную на [сайте Т‑Кассы](https://www.tbank.ru/kassa/dev/cms/) — это доступный источник актуальных версий. Современные модули для популярных CMS генерируют корректный токен автоматически\n\nТакже мы расписали несколько дополнительных обязательных мер, которые необходимо соблюдать при интеграции с MAPI, а именно: \n\n1. Наиболее безопасный способ передачи данных от Мерчанта в MAPI — прямая интеграция бэкенда Мерчанта с бэкендом Т‑Кассы. В этом случае злоумышленник сможет перехватить запрос только если окажется в локальной сети Мерчанта.\n\n2. При любых способах интеграции с MAPI (в том числе и с помощью нашего платежного виджета) необходимо сверять параметры созданных заказов. В случае выявления расхождений между суммой операции, инициированной клиентом, и суммой совершенной операции, не осуществляйте доставку товара клиенту и незамедлительно уведомите Т‑Банк об этом. Для сверки параметров есть несколько способов:\n\t
    2.1. Получение нотификаций:\n\t\n\t- **По e-mail**: на указанную почту придет письмо при переходе платежа в статус «CONFIRMED»;\n\t\n\t- **По http**: MAPI будет отправлять POST-запрос при каждом изменении статуса платежа на URL, указанный в настройках терминала.\n\t\n\t
    2.2. Вызов метода GetState, который возвращает основные параметры и текущий статус платежа. Рекомендуется сверять/валидировать дополнительные данные заказа — `PaymentId` и `Amount`.\n\n3. Обновляйте модули для CMS. Современные модули для популярных CMS сверяют суммы заказов автоматически.\n\nЕсли на вашем сайте не применены описанные выше меры безопасности или используете программное обеспечение для интеграции, полученное не с [сайта Т‑Кассы](https://www.tbank.ru/kassa/develop/), вы самостоятельно отвечаете за возможные риски и неблагоприятные последствия, связанные с использованием такого программного обеспечения\n\n## Обработка карточных данных\nПлатежные системы разработали требования к безопасности карточных данных клиентов — **Payment Card Industry Data Security Standard** (PCI DSS). Компания должна пройти сертификацию, чтобы подтвердить надежность управления карточной информацией\n\nЕсли у вас нет сертификации PCI DSS, вы можете использовать платежную форму Т‑Кассы. В этом случае, все операции, связанные с обработкой критичных данных производятся на стороне Т‑Кассы. Мерчанту достаточно настроить интеграцию с MerchantAPI и инициализировать платеж. Клиент будет перенаправлен на платежную форму, в которую он сможет ввести данные карты. Когда платеж завершится, клиент снова увидит сайт Мерчанта. Подробную информацию о подключении эквайринга смотрите в разделе Non PCI DSS. \n\nЕсли ваш ресурс соответствует требованиям PCI DSS, то вы можете собирать и хранить карточные данные клиентов. В таком случае, MerchantAPI получает зашифрованные карточные данные от Мерчанта. Подробную информацию о подключении такого способа смотрите в разделе PCI DSS.\n\n# Передача признака инициатора операции\nПлатежные системы хотят понимать, кем была инициирована карточная операция. Особенно остро эта необходимость проявляется в случае проведения операций без 3ds и по сохраненным реквизитам\n\nДля выполнения требования регулятора мы добавили в метод /Init новый атрибут OperationInitiatorType. В значении этого атрибута ожидаем получать признак того, кем была инициирована операция и какой способ предоставления реквизитов был использован\n\nПодробное описание сценариев проведения операций, значений OperationInitiatorType, взаимосвязь с другими атрибутами и типами терминалов:\n|Тип операции и инициатор|Описание|Сценарий карточной операции|OperationInitiatorType|RebillId в /Charge|Recurrent в /Init|AFT терминал|ECOM терминал|\n|---|---|---|---|---|---|---|---|\n|Сustomer Initiated Credential-Not-Captured (CIT CNC)|Инициированная покупателем оплата без сохранения реквизитов карты для последующего использования|Стандартный платеж|0|null|N|Разрешено|Разрешено|\n|Сustomer Initiated Credential-Captured (CIT CC)|Инициированная покупателем оплата c сохранением реквизитов карты для последующего использования|Стандартный платеж с созданием родительского рекуррентного платежа|1|null|Y|Разрешено|Разрешено|\n|Сustomer Initiated Credential-on-File (CIT COF)|Инициированная покупателем оплата по сохраненным реквизитам карты (ранее была проведена операция с сохранением реквизитов CIT CC)|Рекуррентный платеж, инициированный покупателем|2|not null|N|Запрещено|Разрешено|\n|Merchant Initiated Credential-on-File, Recurring (CIT COF R)|Инициированные торговым предприятием повторяющиеся платежи **без графика** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяются для оплаты коммунальных услуг, платежей за услуги связи, кабельное/спутниковое телевидение и прочее. Сумма может быть определена заранее или становится известна непосредственно перед оплатой|Рекуррентный платеж, инициированный торговым предприятием|R|not null|N|Запрещено|Разрешено|\n|Merchant Credential-on-File, Installment (CIT COF I)|Инициированные торговым предприятием повторяющиеся платежи **по графику** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяется для платежей в рассрочку по товарному кредиту, для оплаты страховки в рассрочку, для погашения кредита в соответствии с графиком платежей. График платежей может быть изменен по соглашению сторон, т.е. суммы и даты платежей должны быть известны плательщику (держателю карты) до момента проведения операции.|Рекуррентный платеж, инициированный торговым предприятием|I|not null|N|Разрешено|Запрещено|\n\n# Какими терминами пользуемся в документации?\n| **Термин** | Определение |\n| ------ | -------- |\n| **Клиент** | Физлицо, производящее перевод с использованием банковской карты на сайте Мерчанта |\n| **Мерчант** | Бизнес, принимающий и осуществляющий переводы по банковским картам на своем сайте |\n| **Т‑Касса** | Сервис, помогающий проводить выплату клиенту-физлицу |\n| **Эмитент** | Банк, выпустивший карту клиента-физлица |\n| **PCI DSS**| Международный стандарт безопасности, созданный для защиты данных банковских карт |\n| **3-D Secure** | Протокол, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт. 3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей |\n| **Терминал** | Точка приема платежей Мерчанта (в общем случае привязывается к сайту, на котором осуществляется прием платежей). Далее в этой документации описан протокол для терминала мерчанта.
    Для проведения тестов используются данные тестового терминала TinkoffBankTest (пароль аналогичен) |\n| **ККМ** | Контрольно-кассовая машина|\n|**Личный кабинет Мерчанта**|[Веб-приложение](https://business.tbank.ru/oplata/main), в котором Мерчант управляет интернет-эквайрингом - настраивает параметры терминалов, подтверждает или отменяет платежи, анализирует статистику|\n\n\n# Параметры терминала\nКаждый терминал обладает свойствами, которые влияют на те или иные аспекты приёма платежей. Эти свойства настраиваются при подключении интернет-эквайринга и могут быть изменены в Личном кабинете Мерчанта\n\nВ таблице ниже перечислены основые параметры приёма платежей для терминала\n\n|Название параметра|Формат|Описание|\n|---|---|---|\n|TerminalKey|20 символов (чувствительно к регистру)|Уникальный символьный ключ терминала. Устанавливается Т‑Кассой|\n|Success URL|250 символов(чувствительно к регистру)| URL на веб-сайте Мерчанта, куда будет переведен клиент в случае успешной оплаты
    — true - платеж завершился успешно
    — false — платеж не завершился *\n|Fail URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент в случае неуспешной оплаты *\n|Success Add Card URL| 250 символов (чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после успешной привязки карты *|\n|Fail Add Card URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после неуспешной привязки карты *|\n|Notification URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет отправлен POST запрос о статусе выполнения вызываемых методов. Только для методов **Authorize**, **FinishAuthorize**, **Confirm**, **Cancel**|\n|Валюта терминала|3 символа| Валюта, в которой будут происходить списания по данному терминалу, если иное не передано в запросе|\n|Активность терминала|Рабочий /Неактивный /Тестовый|Определяет режим работы данного терминала|\n|Password |20 символов(чувствительно к регистру)|Используется для подписи запросов/ответов. Является секретной информацией, известной только Мерчанту и Т‑Кассе. Пароль находится в [личном кабинете](https://business.tbank.ru/oplata/main) мерчанта\n|Отправлять нотификацию на FinishAuthorize|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **FinishAuthorize** (по умолчанию да)|\n|Отправлять нотификацию на Completed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **AttachCard** (по умолчанию Да)|\n|Отправлять нотификацию на Reversed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **Cancel** (по умолчанию Да)|\n\n\\* *в URL можно указать необходимые параметры в виде ${<параметр>}, которые будут переданы на URL\nметодом GET*\n\n# Подпись запроса\nПеред выполнением запроса MAPI проверяет, можно ли доверять его инициатору. Для этого сервер проверяет подпись запроса. В MAPI используется механизм подписи с помощью токена. Мерчант должен добавлять токен к каждому запросу, где это требуется. \n\n> В описании входных параметров для каждого метода мы указали, нужно подписывать запрос или нет. Токен формируется на основании тех полей, которые присутствуют в запросе, поэтому токены для каждого запроса уникальные, и не совпадают никогда\n\n**Токен** в MAPI — это строка, в которой Мерчант зашифровал данные своего запроса с помощью пароля. Для создания токена Мерчант использует пароль из Личного кабинета мерчанта\n\nРассмотрим на примере процесс шифрования тела запроса для метода Init:\n```json\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"Token\": \"68711168852240a2f34b6a8b19d2cfbd296c7d2a6dff8b23eda6278985959346\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 3500,\n \"Quantity\": 2,\n \"Amount\": 7000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 550,\n \"Quantity\": 4,\n \"Amount\": 4200,\n \"Tax\": \"vat10\"\n }\n ]\n }\n}\n```\n\nЧтобы зашифровать данные запроса Мерчант должен выполнить следующие шаги:\n1. Собрать массив передаваемых данных в виде пар Ключ-Значения. В массив нужно добавить только параметры корневого объекта. Вложенные объекты и массивы не участвуют в расчете токена. В примере ниже в массив включены параметры `TerminalKey`, `Amount`, `OrderId`, `Description` и исключен объект `Receipt` и `DATA`.\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"}]\n```\n\n2. Добавить в массив пару {`Password`, Значение пароля}. Пароль можно найти в личном кабинете Мерчанта\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"Password\": \"usaf8fw8fsw21g\"}]\n```\n\n3. Отсортировать массив по алфавиту по ключу.\n```JSON\n[{\"Amount\": \"19200\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"OrderId\": \"21090\"},{\"Password\": \"usaf8fw8fsw21g\"},{\"TerminalKey\": \"MerchantTerminalKey\"}]\n```\n\n4. Конкатенировать только **значения** пар в одну строку.\n```JSON\n\"19200Подарочная карта на 1000 рублей21090usaf8fw8fsw21gMerchantTerminalKey\"\n```\n\n5. Применить к строке хеш-функцию SHA-256 (с поддержкой UTF-8).\n```JSON\n\"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n```\n\n6. Добавить получившийся результат в значение параметра `Token` в тело запроса и отправить запрос.\n```JSON\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 20000,\n \"Quantity\": 2,\n \"Amount\": 40000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 30000,\n \"Quantity\": 3,\n \"Amount\": 90000,\n \"Tax\": \"vat10\"\n }\n ]\n },\n \"Token\": \"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n}\n```\nПроверить корректность формирования токена можно сервисом https://tokentcs.web.app\n\n> Помимо этого информацию о корректности токена можно проверить в ЛК ИЭ в разделе \"Операции\".\nВыберите нужный заказ, затем \"Дополнительная информация о заказе\", поле \"inittokenisvalid\". Если значение в этом поле будет \"true\", это означает, что токен валидный. Если \"false\", то токен передан некорректный.\n" + "description": "# Введение\n\n## Подключение интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг помогает принимать онлайн-платежи так, как удобно вам и покупателю: на сайте, в мобильном приложении, соцсетях, мессенджерах, по e-mail или СМС. Вы можете принимать оплату разными способами, возвращать и замораживать выплаты, настраивать рекуррентные платежи\n\nЧтобы подключить интернет-эквайринг, оставьте [заявку на сайте Т‑Банка](https://www.tbank.ru/kassa/) и заполните анкету компании или ИП. Подробности подключения можете узнать [в Т-Помощи](https://www.tbank.ru/business/help/business-payments/internet-acquiring/how-involve/connect/?card=q1) или у персонального менеджера\n\n## Способы интеграции интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг нужно интегрировать — настроить оплату на сайте или в приложении. Есть четыре способа интеграции:\n\n* Платежный модуль — для сайтов на CMS,\n* Платежный виджет — для самописного сайта,\n* SDK — для мобильного приложения,\n* API — для разработки своей интеграции.\n\nИнтеграцию можно выполнить самостоятельно или с помощью разработчика\n\n### Платежный модуль\n\nСпособ интеграции интернет-эквайринга с сайтом, созданным на основе CMS. Вы устанавливаете модуль — на странице сайта появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nМодуль подходит, если ваш сайт собран на CMS — например, 1С-Битрикс, WordPress или Taplink. Т‑Касса поддерживает многие популярные CMS, в некоторые уже встроены модули — их устанавливать не нужно\n\n[Инструкции по интеграции с помощью платежного модуля](https://www.tbank.ru/kassa/dev/cms/)\n\n### Платежный виджет\n\nСпособ интеграции интернет-эквайринга с самописным сайтом. Вы вставляете готовый код на страницу сайта — на этом месте появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nВиджет подходит в двух случаях:\n* ваш сайт самописный или на CMS, для которой в Т‑Банке нет платежного модуля;\n* вы не планируете принимать автоплатежи.\n\nДля интеграции виджета потребуется помощь программиста\n\n[Инструкция по интеграции с помощью виджета](https://www.tbank.ru/kassa/dev/widget/)\n\n### Мобильный SDK\nСпособ интеграции интернет-эквайринга с мобильным приложением. Покупатель оплачивает товар без перехода в мобильный браузер, оставаясь внутри вашего приложения\n\nС помощью SDK вы можете разместить платежную форму Т‑Кассы — со всеми или некоторыми способами оплаты. Также с помощью SDK вы можете отдельно встраивать способы оплаты — например, T‑Pay или СБП — в вашу платежную форму\n\nSDK подходит, если принимаете оплату в приложении на Android начиная с версии 7.0 или iOS начиная с версии 12.3. С инструкцией по подключению SDK в ЛК можно ознакомиться по ссылкам ниже:\n\n[Инструкция для Android начиная с версии 7.0](https://opensource.tbank.ru/mobile-tech/asdk-android)\n\n[Инструкция для iOS начиная с версии 12.3](https://opensource.tbank.ru/mobile-tech/asdk-ios)\n\n### API\nСамый гибкий и сложный способ интеграции интернет-эквайринга. Например, API подходит, если у вас самописный сайт и вы хотите настроить оплату под запросы бизнеса: совмещать в платежной форме разные способы оплаты, принимать рекуррентные платежи или подключать другие сервисы Т‑Кассы\n\nДля интеграции потребуется помощь программиста\n\n[Документация по API](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Rekomendacii-pri-integracii)\n\n## Платежная форма\nПлатежная форма — это готовый интерфейс с встроенными способами оплаты, который позволяет принимать платежи онлайн\n\nДля использования платежной формы необходимо подключить интернет-эквайринг, настроить терминал и интегрировать платежную форму на ваш сайт одним из способов выше(кроме SDK)\n### Платежная форма в webview\nНекоторые webview не умеют обрабатывать DeepLink ссылки. Из-за этого способы оплаты, которые осуществляют переход в мобильное приложение во время платежа (СБП, Mir Pay, T‑Pay), могут работать некорректно\n\nВ случае использования платежной формы в webview необходимо учесть особенности вашей интеграции и сделать необходимые доработки для поддержки DeepLink\n\nПо результатам доработок необходимо дополнительно протестировать корректную работу всех способов оплат. В случае обнаружения проблем, требуется связаться с разработчиками webview модуля для их устранения, либо рекомендуется отключить неработающие способы оплаты\n**Ссылки с примерами решений**:\n1. [Первое решение(java,kotlin)](https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/webview/upi-intent-android/#13-handle-deep-links-in-shouldoverrideurlloading-),\n2. [Второе решение(java)](https://stackoverflow.com/questions/25672330/how-to-enable-deep-linking-in-webview-on-android-app).\n\n#### Рекомендации по интеграции\nПлатформа IOS:\nЧтобы deeplink работал в web — есть 2 варианта решения:\n1. Использовать SFSafariViewController, он умеет открывать диплинки, дополнительная настройка не нужна.\n2. Если используете WKWebView он не умеет открывать диплинки из коробки, чтобы его научить, надо обработать открытие диплинка Т‑Банка, пример описан ниже.\n\n**Пример реализации обработки открытия диплинка Т‑Банка** \n```\nnavigationDelegate = self\nfunc webView(\n _ webView: WKWebView,\n decidePolicyFor navigationAction: WKNavigationAction,\n decisionHandler: @escaping (WKNavigationActionPolicy) -> Void\n) {\n if let url = navigationAction.request.url, let scheme = url.scheme {\n if scheme != \"https\" && scheme != \"http\" {\n UIApplication.shared.open(url)\n }\n }\n decisionHandler(.allow)\n}\n```\n\n### Платежная форма в iframe\nНе рекомендуется использовать платежную форму в iframe для мобильных версий сайтов, так как у кнопочных способов оплаты могут возникать проблемы с открытием DeepLink и переходов в мобильное приложение для оплаты (СБП, Mir Pay, T‑Pay). Это связано с тем, что Iframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe\n\nЕсли в мобильной версии сайта использование iframe обязательно, вам необходимо сделать доработки согласно инструкции ниже, чтобы вы могли использовать кнопочные способы оплаты. Она позволит произвести переход в стороннее приложение. Доработки представляют собой скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице.\n\nПосле реализации доработок необходимо протестировать корректную работу всех способов оплат. В случае проблем и вопросов вы можете обратиться в нашу поддержку acq_help@tbank.ru\n\nВ десктопной версии iframe кнопочные способы оплаты будут работать без специальных доработок\n\n
    Инструкция по доработкам для mobile iframe\n
    \nIframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe (переход будет внутри iframe). Чтобы произвести переход в стороннее приложение требуется скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице\n\nВ случае если у вас подключены способы оплаты, использующие deeplink, а именно: T‑Pay, СБП или Mir Pay, то в процессе оплаты может возникать ошибка\n\n##### Информация\nСкрипт общается с фреймом по средствам *window.postMessage()*\n\nДобавление скрипта решает проблему передачи ссылки на ресурс платежного сервиса, для способов оплаты использующих DeepLink. Данная проблема может возникнуть при попытке передачи ссылки в браузер Клиента, из контейнера Платежной формы расположенного в теге ``\n \n\n\n```\nДинамическая интеграция (Если iframe генерируется динамически):\n```\n
    \n \n\n```\n##### Настройка\nКласс Integration принимает 2 аргумента:\n1. HTMLIFrameElement — iframe DOM элемент.\n2. config — необязательный аргумент с конфигурацией PaymentFormIntegrationConfig.\n\nPaymentFormIntegrationConfig: \n```\ninterface PaymentFormIntegrationConfig {\n iframe: {\n element: HTMLIFrameElement;\n /**\n * Используется если скрипт встраивается в промежуточный iframe\n */\n proxy?: true;\n /**\n * Вызывается в момент получения deepLink из ПФ\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n deepLinkRedirectCallback?: (url: string) => void;\n /**\n * Вызывается в момент получения exit из ПФ\n * Например при нажатии кнопки \"Вернуться в магазин\"\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n exitRedirectCallback?: (url: string) => void;\n };\n}\n```\nЕсли Вам не требуется перенаправлять родительскую страницу на возврат в магазин, а требуется просто закрыть модальное окно с платежной формой — замените этот параметр конфигурации\n\nПример инициализации скрипта с конфигурацией: \n```\nvar paymentForm = new PaymentForm.Integration({\n iframe: {\n element: document.getElementById('payment-form'),\n exitRedirectCallback: (url) => {\n // Вызов закрытия модального окна\n }\n }\n});\n```\n##### Iframe внутри iframe\nБываю случаи когда приложение используется внутри iframe, который находится внутри другого iframe. В таком случае необходимо встроить скрипт с ключом proxy: true во все промежуточные iframe.\nПример инициализации скрипта для основной страницы: \n```\n\n \n\n\n```\nПример инициализации скрипта для вложенного iframe: \n```\n\n \n\n\n```\n\"Промежуточный\" скрипт, будет перенаправлять сообщения в каждый следующий iframe\n\nКоллбеки событий будут отрабатывать вызываться в \"промежуточных\" iframe только в случае их переопределения в config\n##### Как работает скрипт\nОбщение между формой и родителем, происходит через *window.postMessage()*\n\n1. После успешной загрузки, платежная форма внутри iframe отправляет сообщение loaded родителю.\n2. После получения loaded из ПФ, скрипт отправляет сообщение ready на Платежную форму, таким образом происходит рукопожатие и платежная форма определяет что может отобразить кнопочные методы оплаты.\n3. Действиями Клиента на Платежной форме вызывается способ оплаты возвращающий DeepLink на ресурс платежного сервиса.\n4. Платежная форма, передает DeepLink в целевое окно клиента, с помощью события deepLink.\n5. Целевое окно выполняет редирект Клиента, по ссылке полученной в DeepLink, с помощью вызова *deepLinkRedirectCallback*.\n6. Аналогично передаются и другие сообщения.\n\n
    \n\n### Кастомизация на платежной форме\nНа платежной форме доступна функция кастомизации, которая позволяет настроить форму под себя и своих клиентов. Для установки кастомизации обратитесь к вашему персональному менеджеру и передайте пожелания по настройкам \n\n#### Список доступных настроек кастомизации: \n|**Возможности кастомизации** | **Доп. описание**|\n|--- | ---|\n|Брендирование UI платежной формы |
  • добавлять лого своей компании на ПФ (логотип отобразится рядом с суммой заказа) 
  • управлять цветами кнопок (кнопка \"Оплатить\" и другие кнопки со страниц статусов и модальных окон)
  • |\n|Управление блоком детализации (информация о заказе и магазине) |
  • делать блок свернутым и развернутым по-умолчанию
  •  скрывать  блок с детализацией на ПФ
  • менять порядок строк в детализации
  • |\n|Управление светлой и темной темой |
  • показывать темную или светлую тему по-умолчанию
  • отключать темной/светлой темы
  • |\n\n\n\n\n## Инструкции по безопасности при интеграции\nУбедитесь, что вы используете последнюю версию интеграции, а также [генерируете и передаете корректный токен](https://www.tbank.ru/kassa/dev/payments/#section/Podpis-zaprosa) независимо от способа интеграции.
    Если ваш сайт собран на CMS, то необходимо использовать новейшую версию платежного модуля, доступную на [сайте Т‑Кассы](https://www.tbank.ru/kassa/dev/cms/) — это доступный источник актуальных версий. Современные модули для популярных CMS генерируют корректный токен автоматически\n\nТакже мы расписали несколько дополнительных обязательных мер, которые необходимо соблюдать при интеграции с MAPI, а именно: \n\n1. Наиболее безопасный способ передачи данных от Мерчанта в MAPI — прямая интеграция бэкенда Мерчанта с бэкендом Т‑Кассы. В этом случае злоумышленник сможет перехватить запрос только если окажется в локальной сети Мерчанта.\n\n2. При любых способах интеграции с MAPI (в том числе и с помощью нашего платежного виджета) необходимо сверять параметры созданных заказов. В случае выявления расхождений между суммой операции, инициированной клиентом, и суммой совершенной операции, не осуществляйте доставку товара клиенту и незамедлительно уведомите Т‑Банк об этом. Для сверки параметров есть несколько способов:\n\t
    2.1. Получение нотификаций:\n\t\n\t- **По e-mail**: на указанную почту придет письмо при переходе платежа в статус «CONFIRMED»;\n\t\n\t- **По http**: MAPI будет отправлять POST-запрос при каждом изменении статуса платежа на URL, указанный в настройках терминала.\n\t\n\t
    2.2. Вызов метода GetState, который возвращает основные параметры и текущий статус платежа. Рекомендуется сверять/валидировать дополнительные данные заказа — `PaymentId` и `Amount`.\n\n3. Обновляйте модули для CMS. Современные модули для популярных CMS сверяют суммы заказов автоматически.\n\nЕсли на вашем сайте не применены описанные выше меры безопасности или используете программное обеспечение для интеграции, полученное не с [сайта Т‑Кассы](https://www.tbank.ru/kassa/develop/), вы самостоятельно отвечаете за возможные риски и неблагоприятные последствия, связанные с использованием такого программного обеспечения\n\n## Обработка карточных данных\nПлатежные системы разработали требования к безопасности карточных данных клиентов — **Payment Card Industry Data Security Standard** (PCI DSS). Компания должна пройти сертификацию, чтобы подтвердить надежность управления карточной информацией\n\nЕсли у вас нет сертификации PCI DSS, вы можете использовать платежную форму Т‑Кассы. В этом случае, все операции, связанные с обработкой критичных данных производятся на стороне Т‑Кассы. Мерчанту достаточно настроить интеграцию с MerchantAPI и инициализировать платеж. Клиент будет перенаправлен на платежную форму, в которую он сможет ввести данные карты. Когда платеж завершится, клиент снова увидит сайт Мерчанта. Подробную информацию о подключении эквайринга смотрите в разделе Non PCI DSS. \n\nЕсли ваш ресурс соответствует требованиям PCI DSS, то вы можете собирать и хранить карточные данные клиентов. В таком случае, MerchantAPI получает зашифрованные карточные данные от Мерчанта. Подробную информацию о подключении такого способа смотрите в разделе PCI DSS.\n\n# Передача признака инициатора операции\nПлатежные системы хотят понимать, кем была инициирована карточная операция. Особенно остро эта необходимость проявляется в случае проведения операций без 3ds и по сохраненным реквизитам\n\nДля выполнения требования регулятора мы добавили в метод /Init новый атрибут OperationInitiatorType. В значении этого атрибута ожидаем получать признак того, кем была инициирована операция и какой способ предоставления реквизитов был использован\n\nПодробное описание сценариев проведения операций, значений OperationInitiatorType, взаимосвязь с другими атрибутами и типами терминалов:\n|Тип операции и инициатор|Описание|Сценарий карточной операции|OperationInitiatorType|RebillId в /Charge|Recurrent в /Init|AFT терминал|ECOM терминал|\n|---|---|---|---|---|---|---|---|\n|Сustomer Initiated Credential-Not-Captured (CIT CNC)|Инициированная покупателем оплата без сохранения реквизитов карты для последующего использования|Стандартный платеж|0|null|N|Разрешено|Разрешено|\n|Сustomer Initiated Credential-Captured (CIT CC)|Инициированная покупателем оплата c сохранением реквизитов карты для последующего использования|Стандартный платеж с созданием родительского рекуррентного платежа|1|null|Y|Разрешено|Разрешено|\n|Сustomer Initiated Credential-on-File (CIT COF)|Инициированная покупателем оплата по сохраненным реквизитам карты (ранее была проведена операция с сохранением реквизитов CIT CC)|Рекуррентный платеж, инициированный покупателем|2|not null|N|Запрещено|Разрешено|\n|Merchant Initiated Credential-on-File, Recurring (CIT COF R)|Инициированные торговым предприятием повторяющиеся платежи **без графика** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяются для оплаты коммунальных услуг, платежей за услуги связи, кабельное/спутниковое телевидение и прочее. Сумма может быть определена заранее или становится известна непосредственно перед оплатой|Рекуррентный платеж, инициированный торговым предприятием|R|not null|N|Запрещено|Разрешено|\n|Merchant Credential-on-File, Installment (CIT COF I)|Инициированные торговым предприятием повторяющиеся платежи **по графику** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяется для платежей в рассрочку по товарному кредиту, для оплаты страховки в рассрочку, для погашения кредита в соответствии с графиком платежей. График платежей может быть изменен по соглашению сторон, т.е. суммы и даты платежей должны быть известны плательщику (держателю карты) до момента проведения операции.|Рекуррентный платеж, инициированный торговым предприятием|I|not null|N|Разрешено|Запрещено|\n\n# Какими терминами пользуемся в документации?\n| **Термин** | Определение |\n| ------ | -------- |\n| **Клиент** | Физлицо, производящее перевод с использованием банковской карты на сайте Мерчанта |\n| **Мерчант** | Бизнес, принимающий и осуществляющий переводы по банковским картам на своем сайте |\n| **Т‑Касса** | Сервис, помогающий проводить выплату клиенту-физлицу |\n| **Эмитент** | Банк, выпустивший карту клиента-физлица |\n| **PCI DSS**| Международный стандарт безопасности, созданный для защиты данных банковских карт |\n| **3-D Secure** | Протокол, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт. 3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей |\n| **Терминал** | Точка приема платежей Мерчанта (в общем случае привязывается к сайту, на котором осуществляется прием платежей). Далее в этой документации описан протокол для терминала мерчанта.
    Для проведения тестов используются данные тестового терминала TinkoffBankTest (пароль аналогичен) |\n| **ККМ** | Контрольно-кассовая машина|\n|**Личный кабинет Мерчанта**|[Веб-приложение](https://business.tbank.ru/oplata/main), в котором Мерчант управляет интернет-эквайрингом - настраивает параметры терминалов, подтверждает или отменяет платежи, анализирует статистику|\n\n\n# Параметры терминала\nКаждый терминал обладает свойствами, которые влияют на те или иные аспекты приёма платежей. Эти свойства настраиваются при подключении интернет-эквайринга и могут быть изменены в Личном кабинете Мерчанта\n\nВ таблице ниже перечислены основые параметры приёма платежей для терминала\n\n|Название параметра|Формат|Описание|\n|---|---|---|\n|TerminalKey|20 символов (чувствительно к регистру)|Уникальный символьный ключ терминала. Устанавливается Т‑Кассой|\n|Success URL|250 символов(чувствительно к регистру)| URL на веб-сайте Мерчанта, куда будет переведен клиент в случае успешной оплаты
    — true - платеж завершился успешно
    — false — платеж не завершился *\n|Fail URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент в случае неуспешной оплаты *\n|Success Add Card URL| 250 символов (чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после успешной привязки карты *|\n|Fail Add Card URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после неуспешной привязки карты *|\n|Notification URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет отправлен POST запрос о статусе выполнения вызываемых методов. Только для методов **Authorize**, **FinishAuthorize**, **Confirm**, **Cancel**|\n|Валюта терминала|3 символа| Валюта, в которой будут происходить списания по данному терминалу, если иное не передано в запросе|\n|Активность терминала|Рабочий /Неактивный /Тестовый|Определяет режим работы данного терминала|\n|Password |20 символов(чувствительно к регистру)|Используется для подписи запросов/ответов. Является секретной информацией, известной только Мерчанту и Т‑Кассе. Пароль находится в [личном кабинете](https://business.tbank.ru/oplata/main) мерчанта\n|Отправлять нотификацию на FinishAuthorize|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **FinishAuthorize** (по умолчанию да)|\n|Отправлять нотификацию на Completed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **AttachCard** (по умолчанию Да)|\n|Отправлять нотификацию на Reversed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **Cancel** (по умолчанию Да)|\n\n\\* *в URL можно указать необходимые параметры в виде ${<параметр>}, которые будут переданы на URL\nметодом GET*\n\n# Подпись запроса\nПеред выполнением запроса MAPI проверяет, можно ли доверять его инициатору. Для этого сервер проверяет подпись запроса. В MAPI используется механизм подписи с помощью токена. Мерчант должен добавлять токен к каждому запросу, где это требуется. \n\n> В описании входных параметров для каждого метода мы указали, нужно подписывать запрос или нет. Токен формируется на основании тех полей, которые присутствуют в запросе, поэтому токены для каждого запроса уникальные, и не совпадают никогда\n\n**Токен** в MAPI — это строка, в которой Мерчант зашифровал данные своего запроса с помощью пароля. Для создания токена Мерчант использует пароль из Личного кабинета мерчанта\n\nРассмотрим на примере процесс шифрования тела запроса для метода Init:\n```json\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"Token\": \"68711168852240a2f34b6a8b19d2cfbd296c7d2a6dff8b23eda6278985959346\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 3500,\n \"Quantity\": 2,\n \"Amount\": 7000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 550,\n \"Quantity\": 4,\n \"Amount\": 4200,\n \"Tax\": \"vat10\"\n }\n ]\n }\n}\n```\n\nЧтобы зашифровать данные запроса Мерчант должен выполнить следующие шаги:\n1. Собрать массив передаваемых данных в виде пар Ключ-Значения. В массив нужно добавить только параметры корневого объекта. Вложенные объекты и массивы не участвуют в расчете токена. В примере ниже в массив включены параметры `TerminalKey`, `Amount`, `OrderId`, `Description` и исключен объект `Receipt` и `DATA`.\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"}]\n```\n\n2. Добавить в массив пару {`Password`, Значение пароля}. Пароль можно найти в личном кабинете Мерчанта\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"Password\": \"usaf8fw8fsw21g\"}]\n```\n\n3. Отсортировать массив по алфавиту по ключу.\n```JSON\n[{\"Amount\": \"19200\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"OrderId\": \"21090\"},{\"Password\": \"usaf8fw8fsw21g\"},{\"TerminalKey\": \"MerchantTerminalKey\"}]\n```\n\n4. Конкатенировать только **значения** пар в одну строку.\n```JSON\n\"19200Подарочная карта на 1000 рублей21090usaf8fw8fsw21gMerchantTerminalKey\"\n```\n\n5. Применить к строке хеш-функцию SHA-256 (с поддержкой UTF-8).\n```JSON\n\"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n```\n\n6. Добавить получившийся результат в значение параметра `Token` в тело запроса и отправить запрос.\n```JSON\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 20000,\n \"Quantity\": 2,\n \"Amount\": 40000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 30000,\n \"Quantity\": 3,\n \"Amount\": 90000,\n \"Tax\": \"vat10\"\n }\n ]\n },\n \"Token\": \"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n}\n```\nПроверить корректность формирования токена можно сервисом https://tokentcs.web.app\n\n> Помимо этого информацию о корректности токена можно проверить в ЛК ИЭ в разделе \"Операции\".\nВыберите нужный заказ, затем \"Дополнительная информация о заказе\", поле \"inittokenisvalid\". Если значение в этом поле будет \"true\", это означает, что токен валидный. Если \"false\", то токен передан некорректный.\n" }, "servers": [ { @@ -29,7 +29,7 @@ "tags": [ { "name": "Сценарии оплаты по карте", - "description": "## Правила работы\n\nПрием платежей осуществляется вызовом методов с передачей параметров методом POST в формате JSON. Все методы и передаваемые параметры являются чувствительными к регистру. \nДля нашего ИЭ оплата проходит только в рублях.\n> При необходимости оплаты в валюте, мерчант самостоятельно на своей стороне реализовывает логику конвертации суммы в запросе\n \nДля POST-запроса в заголовке должен присутствовать `Content Type: application/json`.\nURL: https://securepay.tinkoff.ru/v2/\n \n\n## Сценарии платежа\nОсновная сущность в интернет-эквайринге Т‑Кассы — это **платеж**. В зависимости от настроек терминала платеж может идти по разным сценариям\n\nЕсли Мерчант хочет получить деньги сразу после завершения оплаты, тогда терминал должен быть настроен на приём **одностадийных платежей**. Другой способ — **двухстадийный платеж**. После оплаты деньги заблокируются на карте клиента, а Мерчант затем подтверждает платёж в удобный ему момент. \n\n>Настроить способ приема на терминале можно в Личном кабинете Мерчанта, либо указать нужный тип при вызове метода `Init` в параметре `PayType`\n\n### Стандартный платеж для мерчантов с PCI DSS\n#### Инициализация платежа\nДля того, чтобы создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\nВ ответ MAPI создаст новый платеж в статусе **NEW** и вернёт обратно его идентификатор в параметре `PaymentId`\n\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\nЕсли в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка — закодированный в формате `base64` JSON-объект с параметрами:\n|Название параметра|Тип данных|Описание|\n|---|---|---|\n|threeDSMethodNotificationURL|string|Обратный адрес, на который будет >отправлен запрос после прохождения `3DS Method`|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n\nБраузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n\nПример запроса на `ThreeDSMethodURL`:\n\n``` html\n\n
    \n\n
    \n\n```\n\nПример декодированного значения `threeDSMethodData`:\n```json\n{\n\n\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n\n}\n```\n\n \n\n### Стандартный платеж\n\nЗа проведение платежа отвечает метод — `FinishAuthorize`. Через него Мерчант передает в MAPI карточные данные клиента, таким образом продолжая обработку платежа\n\n \n\n>Если платеж **одностадийный**, то после вызова метода деньги будут списаны с карты клиента\n>\n>Если платеж **двухстадийный**, то после вызова метода деньги будут заблокированы на карте клиента. Мерчант должен дополнительно подтвердить списание, вызвав метод `Confirm`\n\n \n\nВ ответ MAPI вернет один из возможных статусов:\n\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|AUTH_FAIL|Неуспешная авторизация|Провести платеж заново|\n|REJECTED|Платеж отклонен|Провести платеж заново|\n|CONFIRMED|Успешный одностадийный платеж|-|\n|AUTHORIZED|Успешный двухстадийный платеж|Подтвердить платеж|\n|3DS_CHECKING|Требуется подтверждение платежа по 3D-Secure||\n\n\n#### Без 3DS-подтверждения\n\nЕсли по платежу не требуется проходить подтверждение 3DS, то MAPI в ответе `FinishAuthorize` вернет один из трех конечных статусов платежа:\n\n- **CONFIRMED** (при одностадийном платеже),\n\n- **AUTHORIZED** (при двухстадийном платеже),\n\n- **REJECTED** (при отказе в проведении платежа).\n\n \n\n#### C 3DS-подтверждением\n\nЕсли в ответе метода `FinishAuthorize` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен сформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `FinishAuthorize` в параметре `ACSUrl`. Вместе с этим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n**Важно:** Проведение тестовых платежей возможно только на тестовом окружении\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `FinishAuthorize`|\n|PaReq| Запрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `FinishAuthorize`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента. Тип устройства передается в запросе `FinishAuthorize` в параметре `deviceChannel`. Возможны два варианта — браузер (BRW, код `02`) и приложение (APP, код `01`).\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n \nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `FinishAuthorize`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n### Стандартный платеж для Мерчантов без PCI DSS\n#### Инициализация платежа\nДля того, чтоды создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа. При успешном прохождении запроса в ответе на метод `Init` будет прислан параметр `PaymentURL`, на который необходимо переадресовать клиента. При переходе на `PaymentURL` клиенту откроется платежная форма Т‑Кассы, где необходимо ввести реквизиты карты, а дальше — этап прохождения 3DS.\n\n> Методы Authorize и FinishAuthorize вызываются системами Т‑Кассы при переадресации клиента на PaymentURL (возвращается в ответе на метод Init). Актуально для Мерчантов, использующих платежную форму Банка\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\n#### Метод Authorize\nВызов происходит автоматически при переадресации клиента на страницу PaymentURL, указанную в ответе на Init. Статус платежа выставляется в FORM_SHOWED\n\n#### Метод FinishAuthorize\nПодтверждает инициированный платеж передачей карточных данных и осуществляет списание денежных средств с карты клиента\n\n#### Осуществление платежа на платежной форме Т‑Кассы\nВызывается формой оплаты, доступной по адресу PaymentURL, при заполнении клиентом карточных данных и нажатии кнопки «Оплатить»\n\nСтатус перевода:\n* при успешном сценарии: CONFIRMED,\n* при неуспешном: REJECTED.\n\nПереадресация клиента:\n* в случае успешного перевода на Success URL;\n* в случае неуспешного перевода на Fail URL.\n\n\n#### Завершение платежа\nЕсли платёж завершился успешно, то клиент будет перенаправлен на страницу `Success URL` из настроек терминала\n\n### Двухстадийный платеж\n\nДвухстадийный платеж — платеж, состоящий из двух этапов. На первом этапе проверяется наличие средств у клиента и осуществляется их блокировка (холдирование средств). На втором этапе Мерчант должен либо подтвердить списание средств, либо отменить холдирование средств. \n\nКогда клиент оплачивает заказ, деньги за покупку замораживаются (холдируются) на его счете до семи дней.\nЕсли клиент за это время отказался от заказа, он автоматически получает деньги обратно, а компания избегает комиссии за эквайринг\n\nЕсли клиент не стал отказываться от товара и вы подтвердили продажу в течение семи дней, деньги на его счете размораживаются и поступают на счет компании. В этом случае Т‑Касса списывает комиссию\n\nЕсли Мерчант не подтвердит платеж вовремя, может столкнуться с негативом от клиента\n\nНапример, в случае, когда клиент может не вспомнить, за что списались деньги, и может обратиться в свой банк для возврата средств\n\n
    Про сроки холдирования\n
    \n\nХолдирование денежных средств на карте покупателя зависит от его банка эмитента и не всегда равно семи дням. Этот срок может быть другим. Например, покупатель оплатил товар, его банк заморозил средства на карте на 3 дня, они прошли, деньги разморозились и стали доступны на счете. Спустя день вы подтверждаете платеж, списывая сумму покупки. Фактически оплата прошла один раз.\n\n
    \n\n**Техническая реализация двухстадийных платежей:** \n\nЕсли терминал настроен на прием двухстадийный платежей, то после вызова метода `FinishAuthorize` деньги блокируются на карте клиента, и платеж переходит в статус **AUTHORIZED**\n\nКогда Мерчант захочет списать деньги, он должен вызвать метод `Confirm` и передать в запросе `PaymentId`. После успешного списания платеж перейдет в статус **CONFIRMED**. Если Мерчант хочет отменить заказ (например, данный товар закончился), он должен вызвать метод `Cancel`\n\n### Рекуррентные платежи\nМерчант может сохранять платежные данные клиента и использовать их для повторных списаний. Такие платежи называются **рекуррентными**. В этом случае клиент должен совершить хотя бы один платеж, который был настроен как рекуррентный. Для этого Мерчант должен передать параметр `Recurrent` в методе **Init**.\n\nПосле успешной оплаты MAPI отправит Мерчанту уведомление об изменении статуса платежа на **AUTHORIZED** или **CONFIRMED** и передаст параметр `RebillId`. Следующие платежи этого клиента будут рекуррентными, если Мерчант вызовет метод **Init**, а затем без переадресации на `PaymentURL` вызовет метод **Charge** и передаст параметр `RebillId`.\n \n>Метод `Charge` работает как по одностадийной, так и по двухстадийной схеме оплаты. Чтобы перейти на двухстадийную схему, нужно переключить терминал в [Личном кабинете](https://business.tbank.ru/oplata/main), а также написать обращение на с просьбой переключить схему рекуррентов\n\n## Возврат и отмена платежа\nМерчант может отменить успешный платеж. В таком случае, деньги вернутся на ту карту, которую клиент указывал при совершении платежа\n\nУспешный платеж — платеж, который находится в статусе **AUTHORIZED** или **CONFIRMED**. Если Мерчант отменяет платеж в статусе **AUTHORIZED**, то происходит разморозка заблокированной суммы на карте клиента. Если платеж в статусе **CONFIRMED**, то деньги списываются со счета Мерчанта и возвращаются на карту клиента.\n \n> Возврат может быть частичный или полный. Частичный возврат — отмена не на всю сумму платежа. Полный возврат — отмена на полную сумму платежа.\n\nЧтобы отменить платеж, Мерчант должен вызвать метод [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) и передать в запросе идентификатор платежа `PaymentId`. По умолчанию, MAPI сделает полный возврат. Если требуется частичная отмена, то во входящем запросе Мерчант должен передать сумму, которая вернется клиенту, в параметре `Amount`. \n\n
    Про частичный возврат при подключенной Онлайн-кассе\n
    \n\n1. Если при работе используется онлайн-касса, то возврат можно делать только по позициям в чеке. Если возврат нужно сделать на иную сумму, то сначала надо отключить онлайн-кассу и только потом провести возврат через API методом [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel), передавая в нем нужную сумму в параметре `Amount`\n\n2. Если у клиента подключена онлайн-касса, то в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать:\n* в `Amount` — сумму к частичному возврату\\анхолду;\n* в `Receipt` — передать параметры чека.\n\nВ `Items` — параметр `Amount` для частичного возврата\\анхолда должен рассчитываться следующим образом: Price * Quantity = Amount\n\nНапример, товар стоит 500.00 рублей и нужно вернуть 50.00 рублей, то в [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать Amount = 5000:\n\n```JSON\n{\n \"Name\": \"Item12\",\n \"Price\": 50000,\n \"Quantity\": 0.1,\n \"Amount\": 5000,\n \"Tax\": \"none\",\n \"PaymentObject\": \"service\"\n}\n```\nЕсли в чеке несколько позиций, то по каждой позиции в чеке нужно сделать аналогично\n\nБез активной онлайн-кассы достаточно передать нужную сумму в `Amount` в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel). В случае частичного анхолда остаток также остается в резерве и его нужно подтвердить\n\n## Получение данных о платеже\nМерчант может получить информацию об основных параметрах платежа в любой момент\n\nЕсли требуется получить данные по конкретному платежу, то Мерчант должен вызвать метод [`GetState`](#tag/Standartnyj-platyozh/paths/~1GetState/post) и передать в запросе `PaymentId`\n\nЕсли по одному заказу было несколько, то получить историю платежей и их текущий статус можно с помощью метода [`CheckOrder`](#tag/Standartnyj-platyozh/paths/~1CheckOrder/post). Мерчант должен передать в запросе `OrderId`\n\n*`OrderId` не является уникальным параметром. Рекомендуется сверять дополнительные данные заказа — `PaymentId` и `Amount`.*\n\n## Статусная модель платежа\nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL` и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**3DS_CHECKING**|Платеж проходит проверку 3D-Secure|\n|**3DS_CHECKED**|Платеж успешно прошел проверку 3D-Secure|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REVERSING**|Мерчант запросил отмену авторизованного, но еще не подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REVERSED**|Частичный возврат по авторизованному платежу завершился успешно|\n|**REVERSED**|Полный возврат по авторизованному платежу завершился успешно|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**СANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схеме ниже — полный жизненный цикл платежа\n[![scheme](https://acdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)](https://acdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)" + "description": "## Правила работы\n\nПрием платежей осуществляется вызовом методов с передачей параметров методом POST в формате JSON. Все методы и передаваемые параметры являются чувствительными к регистру. \nДля нашего ИЭ оплата проходит только в рублях.\n> При необходимости оплаты в валюте, мерчант самостоятельно на своей стороне реализовывает логику конвертации суммы в запросе\n \nДля POST-запроса в заголовке должен присутствовать `Content Type: application/json`.\nURL: https://securepay.tinkoff.ru/v2/\n \n\n## Сценарии платежа\nОсновная сущность в интернет-эквайринге Т‑Кассы — это **платеж**. В зависимости от настроек терминала платеж может идти по разным сценариям\n\nЕсли Мерчант хочет получить деньги сразу после завершения оплаты, тогда терминал должен быть настроен на приём **одностадийных платежей**. Другой способ — **двухстадийный платеж**. После оплаты деньги заблокируются на карте клиента, а Мерчант затем подтверждает платёж в удобный ему момент. \n\n>Настроить способ приема на терминале можно в Личном кабинете Мерчанта, либо указать нужный тип при вызове метода `Init` в параметре `PayType`\n\n### Стандартный платеж для мерчантов с PCI DSS\n#### Инициализация платежа\nДля того, чтобы создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\nВ ответ MAPI создаст новый платеж в статусе **NEW** и вернёт обратно его идентификатор в параметре `PaymentId`\n\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\nЕсли в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка — закодированный в формате `base64` JSON-объект с параметрами:\n|Название параметра|Тип данных|Описание|\n|---|---|---|\n|threeDSMethodNotificationURL|string|Обратный адрес, на который будет >отправлен запрос после прохождения `3DS Method`|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n\nБраузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n\nПример запроса на `ThreeDSMethodURL`:\n\n``` html\n\n
    \n\n
    \n\n```\n\nПример декодированного значения `threeDSMethodData`:\n```json\n{\n\n\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n\n}\n```\n\n \n\n### Стандартный платеж\n\nЗа проведение платежа отвечает метод — `FinishAuthorize`. Через него Мерчант передает в MAPI карточные данные клиента, таким образом продолжая обработку платежа\n\n \n\n>Если платеж **одностадийный**, то после вызова метода деньги будут списаны с карты клиента\n>\n>Если платеж **двухстадийный**, то после вызова метода деньги будут заблокированы на карте клиента. Мерчант должен дополнительно подтвердить списание, вызвав метод `Confirm`\n\n \n\nВ ответ MAPI вернет один из возможных статусов:\n\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|AUTH_FAIL|Неуспешная авторизация|Провести платеж заново|\n|REJECTED|Платеж отклонен|Провести платеж заново|\n|CONFIRMED|Успешный одностадийный платеж|-|\n|AUTHORIZED|Успешный двухстадийный платеж|Подтвердить платеж|\n|3DS_CHECKING|Требуется подтверждение платежа по 3D-Secure||\n\n\n#### Без 3DS-подтверждения\n\nЕсли по платежу не требуется проходить подтверждение 3DS, то MAPI в ответе `FinishAuthorize` вернет один из трех конечных статусов платежа:\n\n- **CONFIRMED** (при одностадийном платеже),\n\n- **AUTHORIZED** (при двухстадийном платеже),\n\n- **REJECTED** (при отказе в проведении платежа).\n\n \n\n#### C 3DS-подтверждением\n\nЕсли в ответе метода `FinishAuthorize` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен сформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `FinishAuthorize` в параметре `ACSUrl`. Вместе с этим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n**Важно:** Проведение тестовых платежей возможно только на тестовом окружении\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `FinishAuthorize`|\n|PaReq| Запрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `FinishAuthorize`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента. Тип устройства передается в запросе `FinishAuthorize` в параметре `deviceChannel`. Возможны два варианта — браузер (BRW, код `02`) и приложение (APP, код `01`).\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n \nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `FinishAuthorize`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n### Стандартный платеж для Мерчантов без PCI DSS\n#### Инициализация платежа\nДля того, чтоды создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа. При успешном прохождении запроса в ответе на метод `Init` будет прислан параметр `PaymentURL`, на который необходимо переадресовать клиента. При переходе на `PaymentURL` клиенту откроется платежная форма Т‑Кассы, где необходимо ввести реквизиты карты, а дальше — этап прохождения 3DS.\n\n> Методы Authorize и FinishAuthorize вызываются системами Т‑Кассы при переадресации клиента на PaymentURL (возвращается в ответе на метод Init). Актуально для Мерчантов, использующих платежную форму Банка\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\n#### Метод Authorize\nВызов происходит автоматически при переадресации клиента на страницу PaymentURL, указанную в ответе на Init. Статус платежа выставляется в FORM_SHOWED\n\n#### Метод FinishAuthorize\nПодтверждает инициированный платеж передачей карточных данных и осуществляет списание денежных средств с карты клиента\n\n#### Осуществление платежа на платежной форме Т‑Кассы\nВызывается формой оплаты, доступной по адресу PaymentURL, при заполнении клиентом карточных данных и нажатии кнопки «Оплатить»\n\nСтатус перевода:\n* при успешном сценарии: CONFIRMED,\n* при неуспешном: REJECTED.\n\nПереадресация клиента:\n* в случае успешного перевода на Success URL;\n* в случае неуспешного перевода на Fail URL.\n\n\n#### Завершение платежа\nЕсли платёж завершился успешно, то клиент будет перенаправлен на страницу `Success URL` из настроек терминала\n\n### Двухстадийный платеж\n\nДвухстадийный платеж — платеж, состоящий из двух этапов. На первом этапе проверяется наличие средств у клиента и осуществляется их блокировка (холдирование средств). На втором этапе Мерчант должен либо подтвердить списание средств, либо отменить холдирование средств. \n\nКогда клиент оплачивает заказ, деньги за покупку замораживаются (холдируются) на его счете до семи дней.\nЕсли клиент за это время отказался от заказа, он автоматически получает деньги обратно, а компания избегает комиссии за эквайринг\n\nЕсли клиент не стал отказываться от товара и вы подтвердили продажу в течение семи дней, деньги на его счете размораживаются и поступают на счет компании. В этом случае Т‑Касса списывает комиссию\n\nЕсли Мерчант не подтвердит платеж вовремя, может столкнуться с негативом от клиента\n\nНапример, в случае, когда клиент может не вспомнить, за что списались деньги, и может обратиться в свой банк для возврата средств\n\n
    Про сроки холдирования\n
    \n\nХолдирование денежных средств на карте покупателя зависит от его банка эмитента и не всегда равно семи дням. Этот срок может быть другим. Например, покупатель оплатил товар, его банк заморозил средства на карте на 3 дня, они прошли, деньги разморозились и стали доступны на счете. Спустя день вы подтверждаете платеж, списывая сумму покупки. Фактически оплата прошла один раз.\n\n
    \n\n**Техническая реализация двухстадийных платежей:** \n\nЕсли терминал настроен на прием двухстадийный платежей, то после вызова метода `FinishAuthorize` деньги блокируются на карте клиента, и платеж переходит в статус **AUTHORIZED**\n\nКогда Мерчант захочет списать деньги, он должен вызвать метод `Confirm` и передать в запросе `PaymentId`. После успешного списания платеж перейдет в статус **CONFIRMED**. Если Мерчант хочет отменить заказ (например, данный товар закончился), он должен вызвать метод `Cancel`\n\n### Рекуррентные платежи\nМерчант может сохранять платежные данные клиента и использовать их для повторных списаний. Такие платежи называются **рекуррентными**. В этом случае клиент должен совершить хотя бы один платеж, который был настроен как рекуррентный. Для этого Мерчант должен передать параметр `Recurrent` в методе **Init**.\n\nПосле успешной оплаты MAPI отправит Мерчанту уведомление об изменении статуса платежа на **AUTHORIZED** или **CONFIRMED** и передаст параметр `RebillId`. Следующие платежи этого клиента будут рекуррентными, если Мерчант вызовет метод **Init**, а затем без переадресации на `PaymentURL` вызовет метод **Charge** и передаст параметр `RebillId`.\n \n>Метод `Charge` работает как по одностадийной, так и по двухстадийной схеме оплаты. Чтобы перейти на двухстадийную схему, нужно переключить терминал в [Личном кабинете](https://business.tbank.ru/oplata/main), а также написать обращение на с просьбой переключить схему рекуррентов\n\n## Возврат и отмена платежа\nМерчант может отменить успешный платеж. В таком случае, деньги вернутся на ту карту, которую клиент указывал при совершении платежа\n\nУспешный платеж — платеж, который находится в статусе **AUTHORIZED** или **CONFIRMED**. Если Мерчант отменяет платеж в статусе **AUTHORIZED**, то происходит разморозка заблокированной суммы на карте клиента. Если платеж в статусе **CONFIRMED**, то деньги списываются со счета Мерчанта и возвращаются на карту клиента.\n \n> Возврат может быть частичный или полный. Частичный возврат — отмена не на всю сумму платежа. Полный возврат — отмена на полную сумму платежа.\n\nЧтобы отменить платеж, Мерчант должен вызвать метод [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) и передать в запросе идентификатор платежа `PaymentId`. По умолчанию, MAPI сделает полный возврат. Если требуется частичная отмена, то во входящем запросе Мерчант должен передать сумму, которая вернется клиенту, в параметре `Amount`. \n\n
    Про частичный возврат при подключенной Онлайн-кассе\n
    \n\n1. Если при работе используется онлайн-касса, то возврат можно делать только по позициям в чеке. Если возврат нужно сделать на иную сумму, то сначала надо отключить онлайн-кассу и только потом провести возврат через API методом [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel), передавая в нем нужную сумму в параметре `Amount`\n\n2. Если у клиента подключена онлайн-касса, то в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать:\n* в `Amount` — сумму к частичному возврату\\анхолду;\n* в `Receipt` — передать параметры чека.\n\nВ `Items` — параметр `Amount` для частичного возврата\\анхолда должен рассчитываться следующим образом: Price * Quantity = Amount\n\nНапример, товар стоит 500.00 рублей и нужно вернуть 50.00 рублей, то в [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать Amount = 5000:\n\n```JSON\n{\n \"Name\": \"Item12\",\n \"Price\": 50000,\n \"Quantity\": 0.1,\n \"Amount\": 5000,\n \"Tax\": \"none\",\n \"PaymentObject\": \"service\"\n}\n```\nЕсли в чеке несколько позиций, то по каждой позиции в чеке нужно сделать аналогично\n\nБез активной онлайн-кассы достаточно передать нужную сумму в `Amount` в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel). В случае частичного анхолда остаток также остается в резерве и его нужно подтвердить\n\n## Получение данных о платеже\nМерчант может получить информацию об основных параметрах платежа в любой момент\n\nЕсли требуется получить данные по конкретному платежу, то Мерчант должен вызвать метод [`GetState`](#tag/Standartnyj-platyozh/paths/~1GetState/post) и передать в запросе `PaymentId`\n\nЕсли по одному заказу было несколько, то получить историю платежей и их текущий статус можно с помощью метода [`CheckOrder`](#tag/Standartnyj-platyozh/paths/~1CheckOrder/post). Мерчант должен передать в запросе `OrderId`\n\n*`OrderId` не является уникальным параметром. Рекомендуется сверять дополнительные данные заказа — `PaymentId` и `Amount`.*\n\n## Статусная модель платежа\nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL` и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**3DS_CHECKING**|Платеж проходит проверку 3D-Secure|\n|**3DS_CHECKED**|Платеж успешно прошел проверку 3D-Secure|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REVERSING**|Мерчант запросил отмену авторизованного, но еще не подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REVERSED**|Частичный возврат по авторизованному платежу завершился успешно|\n|**REVERSED**|Полный возврат по авторизованному платежу завершился успешно|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**СANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схеме ниже — полный жизненный цикл платежа\n[![scheme](https://cdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)](https://cdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)" }, { "name": "Методы работы с клиентами", @@ -37,15 +37,15 @@ }, { "name": "Сценарии привязки карты", - "description": "## Общая информация\nМерчант может сохранить платежные данные клиента, чтобы при последующих оплатах ему не приходилось заполнять платежную форму. Для этого клиент привязывается к терминалу, через который будут проходить платежи. После, для этого клиенту можно сохранять карты. \n\nМерчант может выбрать способ привязки клиента — с проверкой 3D-Secure или без\n\nЕсли выбрана опция с проверкой, то клиент должен будет подтвердить операцию уже на этом этапе. Все дальнейшие платежи будут проходить по схеме рекуррентного платежа, то есть подтверждать каждое списание не нужно\n\nЕсли Мерчант выбрал опцию привязки без проверки 3D-Secure, то клиент и его карты будут сохранены без подтверждения. Однако, оно подтребуется при первом платеже по привязанной карте\n\nЗа способ привязки отвечает параметр `CheckType` в запросе метода `AddCard`. Если Мерчант не передаст этот параметр, то MAPI, по умолчанию, будет считать, что привязка прошла без подтверждения клиента\n\n> Для корректной работы методов Т‑Касса должна разрешить Мерчанту привязывать карты и клиентов к терминалу. В результате привязки карты к параметру `CustomerKey` будет привязана `CardId`\n\n## Сценарии работы с картами и клиентами\n### Добавление, получение и удаление клиента\nДля сохранения идентификатора клиента `CustomerKey` Мерчант должен вызвать метод `AddCustomer` и передать в запросе параметр `CustomerKey`\n\nДля удаления клиента из списка привязанных к терминалу Мерчант должен вызвать метод `RemoveCustomer`передать в запросе параметр `CustomerKey`\n\nДля получения сохраненных данных клиента Мерчант должен вызвать метод `GetCustomer` и передать в запросе параметр `CustomerKey`\n\n### Добавление, получение и удаление карты\nдля Мерчантов с PCI DSS\n\n#### Инициализация привязки\nПосле сохранения клиента в списке привязанных к терминалу Мерчант может добавить карту. Для этого он вызывает метод `AddCard` и передает в запросе параметр `CustomerKey`. В ответ MAPI пришлет идентификатор сессии привязки карты `PaymentId`.\n\n#### Проверка версии 3DS\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\n>Если в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка - закодированный в формате `base64` JSON-объект с параметрами:\n>|Название параметра|Тип данных|Описание|\n>|---|---|---|\n>|threeDSMethodNotificationURL|string|Обратный адрес, на который будет отправлен запрос после прохождения `3DS Method`|\n>|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n>\n>Браузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n>\n>Пример запроса на `ThreeDSMethodURL`:\n>\n>``` js\n>\n>
    \n> value=\"eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjU2ZTcxMmE1LTE5MGEtNDU4OC05MWJjLWUwODYyNmU3N2M0NCIsInRocm\n>VlRFNNZXRob2ROb3RpZmljYXRpb25VUkwiOiJodHRwczovL3Jlc3QtYXBpLXRlc3QudGlua29mZi5ydS92Mi9Db21wbGV0ZTNEU0\n>1ldGhvZHYyIn0\">\n>
    \n>\n>```\n>\n>Пример декодированного значения `threeDSMethodData`:\n>```json\n>{\n>\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n>\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n>}\n>```\n\n#### Завершение привязки\nДля завершения привязки карты Мерчант вызывает метод `AttachCard` и передает зашифрованные карточные данные, а также набор параметров для прохождения проверки 3D-Secure\n\nВ ответ MAPI вернет один из возможных статусов:\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|REJECTED|Привязка отклонена|Провести привязку заново|\n|COMPLETED|Успешная привязка карты|-|\n|3DS_CHECKING|Требуется подтверждение привязки по 3D-Secure|
    • Отменить привязку
    • Пройти подтверждение
    \n\nЕсли в ответе метода `AttachCard` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен\nсформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `AttachCard` в параметре `ACSUrl`. Вместе с\nэтим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `AttachCard`|\n|PaReq|\tЗапрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `AttachCard`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n\nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `AttachCard`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n#### Завершение привязки\nЕсли привязка завершилась успешно, то клиент будет перенаправлен на страницу `Success Add Card URL` из настроек терминала\n\n## Статусная модель привязки карты\nВ процессе обработки операция привязки меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n| Статус | Описание |\n| --- | --- |\n| NEW | Новая сессия |\n| FORM_SHOWED | Показ формы привязки карты |\n| 3DS_CHECKING | Отправка клиента на проверку 3DS |\n| 3DS_CHECKED | Клиент успешно прошел проверку 3DS |\n| AUTHORIZING | Отправка платежа на 0 руб |\n| AUTHORIZED | Платеж на 0 руб прошел успешно |\n| COMPLETED | Привязка успешно завершена |\n| REJECTED | Привязка отклонена |\n\n\nНа схеме ниже — полный жизненный цикл привязки карты\n\n[![scheme](https://acdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)](https://acdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)" + "description": "## Общая информация\nМерчант может сохранить платежные данные клиента, чтобы при последующих оплатах ему не приходилось заполнять платежную форму. Для этого клиент привязывается к терминалу, через который будут проходить платежи. После, для этого клиенту можно сохранять карты. \n\nМерчант может выбрать способ привязки клиента — с проверкой 3D-Secure или без\n\nЕсли выбрана опция с проверкой, то клиент должен будет подтвердить операцию уже на этом этапе. Все дальнейшие платежи будут проходить по схеме рекуррентного платежа, то есть подтверждать каждое списание не нужно\n\nЕсли Мерчант выбрал опцию привязки без проверки 3D-Secure, то клиент и его карты будут сохранены без подтверждения. Однако, оно подтребуется при первом платеже по привязанной карте\n\nЗа способ привязки отвечает параметр `CheckType` в запросе метода `AddCard`. Если Мерчант не передаст этот параметр, то MAPI, по умолчанию, будет считать, что привязка прошла без подтверждения клиента\n\n> Для корректной работы методов Т‑Касса должна разрешить Мерчанту привязывать карты и клиентов к терминалу. В результате привязки карты к параметру `CustomerKey` будет привязана `CardId`\n\n## Сценарии работы с картами и клиентами\n### Добавление, получение и удаление клиента\nДля сохранения идентификатора клиента `CustomerKey` Мерчант должен вызвать метод `AddCustomer` и передать в запросе параметр `CustomerKey`\n\nДля удаления клиента из списка привязанных к терминалу Мерчант должен вызвать метод `RemoveCustomer`передать в запросе параметр `CustomerKey`\n\nДля получения сохраненных данных клиента Мерчант должен вызвать метод `GetCustomer` и передать в запросе параметр `CustomerKey`\n\n### Добавление, получение и удаление карты\nдля Мерчантов с PCI DSS\n\n#### Инициализация привязки\nПосле сохранения клиента в списке привязанных к терминалу Мерчант может добавить карту. Для этого он вызывает метод `AddCard` и передает в запросе параметр `CustomerKey`. В ответ MAPI пришлет идентификатор сессии привязки карты `PaymentId`.\n\n#### Проверка версии 3DS\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\n>Если в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка - закодированный в формате `base64` JSON-объект с параметрами:\n>|Название параметра|Тип данных|Описание|\n>|---|---|---|\n>|threeDSMethodNotificationURL|string|Обратный адрес, на который будет отправлен запрос после прохождения `3DS Method`|\n>|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n>\n>Браузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n>\n>Пример запроса на `ThreeDSMethodURL`:\n>\n>``` js\n>\n>
    \n> value=\"eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjU2ZTcxMmE1LTE5MGEtNDU4OC05MWJjLWUwODYyNmU3N2M0NCIsInRocm\n>VlRFNNZXRob2ROb3RpZmljYXRpb25VUkwiOiJodHRwczovL3Jlc3QtYXBpLXRlc3QudGlua29mZi5ydS92Mi9Db21wbGV0ZTNEU0\n>1ldGhvZHYyIn0\">\n>
    \n>\n>```\n>\n>Пример декодированного значения `threeDSMethodData`:\n>```json\n>{\n>\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n>\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n>}\n>```\n\n#### Завершение привязки\nДля завершения привязки карты Мерчант вызывает метод `AttachCard` и передает зашифрованные карточные данные, а также набор параметров для прохождения проверки 3D-Secure\n\nВ ответ MAPI вернет один из возможных статусов:\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|REJECTED|Привязка отклонена|Провести привязку заново|\n|COMPLETED|Успешная привязка карты|-|\n|3DS_CHECKING|Требуется подтверждение привязки по 3D-Secure|
    • Отменить привязку
    • Пройти подтверждение
    \n\nЕсли в ответе метода `AttachCard` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен\nсформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `AttachCard` в параметре `ACSUrl`. Вместе с\nэтим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `AttachCard`|\n|PaReq|\tЗапрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `AttachCard`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n\nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `AttachCard`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n#### Завершение привязки\nЕсли привязка завершилась успешно, то клиент будет перенаправлен на страницу `Success Add Card URL` из настроек терминала\n\n## Статусная модель привязки карты\nВ процессе обработки операция привязки меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n| Статус | Описание |\n| --- | --- |\n| NEW | Новая сессия |\n| FORM_SHOWED | Показ формы привязки карты |\n| 3DS_CHECKING | Отправка клиента на проверку 3DS |\n| 3DS_CHECKED | Клиент успешно прошел проверку 3DS |\n| AUTHORIZING | Отправка платежа на 0 руб |\n| AUTHORIZED | Платеж на 0 руб прошел успешно |\n| COMPLETED | Привязка успешно завершена |\n| REJECTED | Привязка отклонена |\n\n\nНа схеме ниже — полный жизненный цикл привязки карты\n\n[![scheme](https://cdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)](https://cdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)" }, { "name": "Оплата через СБП", - "description": "## Общая информация для оплат по QR\n1. Банк по умолчанию покупатель выбирает на своём устройстве, через API это настроить невозможно\n2. Если оплата СБП отклоняется на стороне эмитента, эквайер на своей стороне не может повлиять на это \n3. На платежной форме банка при выборе способа оплаты СБП, отображается QR-код с надписью \"Отсканируйте в приложении Т‑Банка\", т.к. мы не можем отвечать, что у другого банка есть возможность сканирования QR-кода внутри приложения, поэтому мы указываем только информацию про Т‑Банк\n4. По СБП не предусмотрена двухстадийная оплата, соответственно холдирование невозможно даже при рекуррентном платеже\n5. Способ оплаты СБП не работает для маркетплейсов\n6. Внимание! Тестирование оплаты через Систему быстрых платежей возможно на prod окружении и только на demo терминале \n\nURL: https://securepay.tinkoff.ru/v2/\n\n## Статусная модель платежа \nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`.|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL`, и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**ASYNC_REFUNDING**|Обработка возврата денежных средств по QR|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**CANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**ATTEMPTS_EXPIRED**|Клиент превысил количество попыток открытия формы|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схемах ниже изображен полный жизненный цикл платежа\n[![scheme](https://acdn.t-static.ru/static/documents/schemaSBPPayments.png)](https://acdn.t-static.ru/static/documents/schemaSBPPayments.png)\n\n## Привязка счёта\n### Таблица статусов привязки счёта\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос AddAccountQr или GetQr для сессии с рекуррентным платежом|\n|**PROCESSING**|QR сформирован и отправлен мерчанту|\n|**ACTIVE**|Привяза счета прошла успешно|\n|**INACTIVE**|Банк отклонил привязку счета|\n### Схема привязки счёта \n[![scheme](https://acdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)](https://acdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)\n\nНа схеме ниже приведены переходы статуса привязки счета при оплате с одновременной привязкой. Переходы статуса платежа в данной операции показаны на схеме полного жизненного цикла платежа\n[![scheme](https://acdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)](https://acdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)\n\n## Рекуррентный платеж\n### Таблица статусов рекуррентного платежа\n|Статус | Правило перехода|\n|--- | ---|\n|NEW | MAPI получил запрос Init. После этого он создает новый платеж в статусе NEW и возвращает обратно его идентификатор в параметре PaymentId|\n|FORM_SHOWED | MAPI принял запрос на обработку платежа. Ожидается подтверждение от НСПК о проведении оплаты по привязке|\n|AUTHORIZING | MAPI принял запрос от НСПК на авторизацию платежа|\n|AUTHORIZED | Платеж авторизован, деньги заблокированы на карте клиента|\n|CONFIRMING | Подтверждение платежа обрабатывается MAPI и платежной системой|\n|CONFIRMED | Платеж подтвержден, деньги списаны с карты клиента|\n|REFUNDING | Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|ASYNC_REFUNDING | Обработка возврата денежных средств по QR|\n|PARTIAL_REFUNDED | Частичный возврат по подтвержденному платежу завершился успешно|\n|REFUNDED | Полный возврат по подтвержденному платежу завершился успешно|\n|CANCELED | Мерчант отменил платеж|\n|REJECTED | Банк отклонил платеж|\n\n### Схема проведения рекуррентого платежа\n[![scheme](https://acdn.t-static.ru/static/documents/schtmaSBPRecurrent.png)](https://acdn.t-static.ru/static/documents/schtmaSBPRecurrent.png) \n\n\n### Логика привязки при наличии нескольких терминалов\n[![scheme;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png)](https://acdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png) \nЕсли клиент привязывает счет к терминалу мерчанта, у которого есть несколько терминалов, то клиент имеет возможность выполнять рекуррентные платежи на всех терминалах Мерчанта\n\nПроцесс выглядит следующим образом:\n1. Мерчанту принадлежат терминалы \"А\" и \"Б\", покупатель ранее проводил оплату только по терминалу \"А\".\n2. Покупатель пропбует провести рекуррентный платеж по терминалу \"Б\".\n3. Система проверяет наличие привязки по терминалу \"Б\".\n4. Так как привязка по этому терминалу не проводилась, система с помощью идентификатора магазина проверяет наличие привязки на других терминалах мерчанта. \n5. Система успешно находит привязку по терминалу \"А\", в связи с чем разрешает проведение рекуррентного платежа.\n\n# Подключение СБП\n## Откройте расчетный счёт\nДля подключения СБП клиент должен быть резидентом. Если клиент нерезидент, СБП работать не будет\n\nЗаполните [заявку](https://www.tbank.ru/business/) и откройте расчетный счет в Т‑Банке\n\n## Подключите Интернет эквайринг\nПодайте [заявку](https://business.tbank.ru/oplata/main) на подключение интернет эквайринг и заполните данные об организации и магазине\n## Выберите доступные типы интеграций\nСБП доступен для следующих типов интеграций:\n* Платежный [виджет](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Vidzhet-SBP),\n* Платежный [API](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Obshaya-informaciya-dlya-oplat-po-QR),\n* Мобильный [SDK](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Sposoby-integracii),\n* Через Агента ТСП,\n* Стикер с QR-кодом для размещения на кассе.\n\nДалее, настройте интеграцию на сайте, в мобильном приложении или в любом другом интерфейсе\n\n## Включение СБП\n\n### Требования к подключению СБП\nРасчётный счёт в Т‑Банке установлен в магазине счётом для выплат\n\n### Подключение СБП в Личном Кабинете\nВойдите в свой личный кабинет и откройте страницу магазина, для которого вы хотите подключить оплату\nчерез СБП. Перейдите на вкладку “Способы оплаты“\n\n[![sposobioplati;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)](https://acdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)\n\nНажмите \"Настроить“ на плашке Система быстрых платежей.\nДалее выбираете тот способ интеграции, который планируете использовать\n\n#### Платежная форма Т‑Банка\nЕсли планируете использовать её, то выбираете данную вкладку и нажимаете \"Включить\"\n\n[![sbp_pf_tinkoff_off;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_tinkoff_on;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)\n\n#### Собственная платежная форма\nЕсли у вас уже есть собственная платежная форма или вы хотите подключить виджет СБП, то необходимо нажать \"Включить\" в данной вкладке. После включения останется настроить интеграцию по API \n\n[![sbp_pf_svoya_off;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_svoya_on;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)\n\n#### Приложение \nЕсли вы планируете использовать СБП в своём приложении, то включаете соответствующую настройку, после чего следуете инструкции размещенной в данном разделе \n\n[![app_sbp_off:block;margin:auto|](https://acdn.t-static.ru/static/documents/app_sbp_off.jpg)](https://acdn.t-static.ru/static/documents/app_sbp_off.jpg)\n\nПосле включения вкладка будет выглядить следующим образом\n\n[![app_sbp_on:block;margin:auto|](https://acdn.t-static.ru/static/documents/app_sbp_on.jpg)](https://acdn.t-static.ru/static/documents/app_sbp_on.jpg)\n\n#### Статический QR\nВне зависимости от того, какой способ интеграции вы используете, вы всегда можете скачать статический QR-код в данном разделе\n\n[![novii_static_qr:block;margin:auto|](https://acdn.t-static.ru/static/documents/novii_static_qr.png)](https://acdn.t-static.ru/static/documents/novii_static_qr.png)\n\n\n### Настройка интеграций при включении способа оплаты СБП\n#### Платежная форма Т‑Банка\nПосле подключения СБП в Личном кабинете, QR код автоматически отобразится на платежной форме, ничего\nдополнительно интегрировать не нужно.\n[Описание](https://www.tbank.ru/kassa/develop/widget/install/), как интегрировать Платежную форму на сайт.\nПлатёжные формы Т‑Банка:\nМобильная\n\n[![pfsbpmobile;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/pfsbpmobile.png)](https://acdn.t-static.ru/static/documents/pfsbpmobile.png)\n\nДесктопная\n[![pfsbpdesktop;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/pfsbpdesktop.png)](https://acdn.t-static.ru/static/documents/pfsbpdesktop.png)\n\nВнимание! Способ — Оплата Картой, является обязательным, отключить его нельзя, все остальные\nспособы — опциональные и их можно выключить в Личном кабинете\n\n#### API\nЕсли ваша интеграция по API, то вы самостоятельно отображаете полученный QR-код или кнопку на вашем\nсайте или любом другом интерфейсе\n\n#### SDK\nЕсли ваша интеграция предусматривает исопользование мобильного приложения, то в SDK необходимо\nпередать специальные параметры в [IOS](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-ios) и [Android](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-android) для отображения QR кода\n\n#### Агентская интеграция\nЕсли ваша интеграция настроена с Агентом ТСП, то необходимо\n1. Создать магазин типа – **Выставление счета**.\n2. Включить СБП в способах оплаты.\n3. Сообщить Агенту ТСП об успешном включении.\n\nИнтерфейс \"SDK Т‑Банка\": \n\n[![sbpsdk1;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbpsdk1.png)](https://acdn.t-static.ru/static/documents/sbpsdk1.png)\n\n[![sbpsdk2;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbpsdk2.png)](https://acdn.t-static.ru/static/documents/sbpsdk2.png)\n\n### Прием платежей с помощью стикеров с QR-кодом\nСтикер со статичным QR кодом – платежный QR код который размещается в кассовой зоне магазина.\nПосле создании магазина в Личном кабинете, его можно скачать в режиме онлайн\n\n#### Получение стикера\nДля получения стикера с QR кодом небходимо:\n1. Создать магазин с выставлением счета, если у вас уже есть магазин, то далее п.2.\n2. Зайдите в настройки СБП в разделе \"Способы оплаты\".\n3. Нажать на кнопку \"скачать\" в разделе Статический QR. \n4. Полученный QR код необходимо распечатать и разместить в кассовой зоне вашего магазина.\nСтикер \"QR Т‑Банка”:\n\n\n[![sbpqr;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/novii_static_qr_skrin.png)](https://acdn.t-static.ru/static/documents/novii_static_qr_skrin.png)\n\n\nПосле сканирования покупателем Стикера с QR кодом ему необходимо будет ввести сумму и\nподтвердить оплату\n\n**Внимание!** Фискализация по операциям с помощью Стикера с QR-кодом не происходит через онлайн\nкассы, даже если онлайн кассы подключенны в личном кабинете\n\n#### Нотификации об оплате\nПосле оплаты вам придет нотификация в зависимости от настроек, на email или по http на ваш сервер\n\n**Магазин — Выставление счетов** \nНастройка нотификаций происходит через acq_help@tbank.ru\n\n**Магазин — Интернет магазин** \nЕсли у вас уже есть интернет-магазин, то нотификации вы можете самостоятельно настроить в разделе\nТерминал\n\n\n[![nastroikiterminala;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/nastroikiterminala.png)](https://acdn.t-static.ru/static/documents/nastroikiterminala.png)\n\n### Настроить выбор банка при интеграции по API\nЕсли вы интегрировались по API, то можно настроить выбор банка при оплате по СБП.\nДля этого нужно создать прямую ссылку, которая существует для того, чтобы перенаправить\nклиента при клике на ссылку в конкретное приложение банка.\n1. Чтобы сформировать прямую ссылку на переход в приложение банка, необходимо заменить\nhttps из функциональной ссылки на значение параметра schema из списка банков.\n2. Список банков лежит по ссылке - https://qr.nspk.ru/proxyapp/c2bmembers.json.\n\nНапример:\nФункциональная ссылка https://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nЗаменить https на соответствующую schema Т‑Банка —\nbank100000000004://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nДля каждого из банков сделать прямую ссылку по логике указанной в п.1. На Вашей платёжной форме\nнеобходимо отобразить список банков из п. 2\n\n# Виджет СБП\nСБП можно интегрировать с помощью виджета, ниже будет описан порядок такой интеграции\n\n## Подключение платежного виджета\n\n### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка \"Оплатить СБП\"\n```\n\n \n \n \n \n \n \n\n
    \n
    \n \n \n \n \n \n \n \n
    \n\n```\nСумма заказа \"amount\" указывается в рублях, копейки через точку\n\n## Формирование чека\n\nДобавьте в код поле ввода receipt:\n```\n\n```\nВ значении атрибута value поля receipt нужно указывать параметры чека. Например, добавьте следующий код:\n```\n var form = document.forms.TinkoffPayForm;\n\n // Данные для чека\n Object.defineProperty(form.receipt, 'value', {\n get: function () {\n return JSON.stringify({\n Email: form.email.value,\n Phone: form.phone.value,\n EmailCompany: 'mail@mail.com',\n Taxation: 'patent',\n Items: [\n {\n Name: form.description.value || 'Оплата',\n Price: form.amount.value + '00',\n Quantity: 1.0,\n Amount: form.amount.value + '00',\n PaymentMethod: 'full_prepayment',\n PaymentObject: 'service',\n Tax: 'none',\n },\n ],\n });\n },\n });\n```\n## Подключение СБП\n## Подключение СБП в Личном Кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернетмагазина, для которого вы хотите подключить оплату через СБП на сайте. Перейдите на вкладку “Способы оплаты”. Для подключения СБП надо провести первый платеж любым доступным способом.\n2. Нажмите на плашку СБП для подключения оплаты через СБП на сайте.\n3. В случае успешного подключения СБП для интернет-магазина плашка должна стать активной. \n## Настройка оплаты товаров\nДля подключения оплаты СБП для одного и более товаров потребуется передавать в метод initPayments объект настроек, в котором определено поле paymentItems \n\nЗначением поля paymentItems является массив объектов, которые определяют размещение платёжных кнопок и информацию о платеже\n\nПример кода приведен ниже:\n \n```\n var terminalkey = document.forms.TinkoffPayForm.terminalkey;\n\n var widgetParameters = {\n terminalKey: terminalkey.value,\n paymentItems: [\n {\n container: document.getElementById(\"tinkoffWidgetContainer1\"),\n paymentInfo: function () {\n return {\n paymentData: document.forms.TinkoffPayForm,\n };\n },\n },\n ],\n paymentSystems: { TinkoffFps: {} },\n };\n\n window.addEventListener(\"load\", function () {\n initPayments(widgetParameters);\n });\n\n```\n## Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Информация о платеже| \n## Тесты по QR\n* Сценарий “Платеж-успех” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту. \n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId).\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом CONFIRMED.\n* Сценарий “Платеж — отказ по таймауту” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId) и параметр IsDeadlineExpired = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом DEADLINE_EXPIRED.\n* Сценарий “Платеж – отказ, отклонен Т‑Кассой” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии\nТ‑Кассы (PaymentId) и параметр IsRejected = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом REJECTED.\n* Сценарий “Возврат – успех \n1) Инициировать возврат (не отмену) методом Cancel тестового платежа по QR-коду СБП,\nвыполненного успешно в тесте “Платеж-успех”\n2) Запросить текущий статус платежа вызывая метод **GetState**.\n3) Получить ответ со статусом REFUNDED.\n\n## Настройка платежного виджета\nВставьте идентификатор магазина в код платежного виджета в значение параметра terminalkey. Идентификатор магазина выдаётся банком,\nего можно получить в личном кабинете (раздел «Магазины», вкладка \"Терминалы\"):\n\nЕсли необходимо изменить состав полей платежного виджета, укажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо поле, выставьте у этого поля параметр required:\n```\n\n```\nСтилизация платежного виджета производится магазином самостоятельно. Ограничений на стилизацию со стороны Т‑Банка нет:\n```\n \n \n \n \n\n```\nПроверить статус платежа можно в личном кабинете интернет-эквайринга, просмотрев операции по СБП, по API с помощью метода [GetState](https://www.tbank.ru/kassa/dev/payments/#tag/Standartnyj-platyozh/paths/~1GetState/post) или с помощью нотификации по http или на e-mail в разделе [Нотификации мерчанта об операциях](https://www.tinkoff.ru/kassa/dev/payments/index.html#tag/Notifikacii-Merchanta-ob-operaciyah)" + "description": "## Общая информация для оплат по QR\n1. Банк по умолчанию покупатель выбирает на своём устройстве, через API это настроить невозможно\n2. Если оплата СБП отклоняется на стороне эмитента, эквайер на своей стороне не может повлиять на это \n3. На платежной форме банка при выборе способа оплаты СБП, отображается QR-код с надписью \"Отсканируйте в приложении Т‑Банка\", т.к. мы не можем отвечать, что у другого банка есть возможность сканирования QR-кода внутри приложения, поэтому мы указываем только информацию про Т‑Банк\n4. По СБП не предусмотрена двухстадийная оплата, соответственно холдирование невозможно даже при рекуррентном платеже\n5. Способ оплаты СБП не работает для маркетплейсов\n6. Внимание! Тестирование оплаты через Систему быстрых платежей возможно на prod окружении и только на demo терминале \n\nURL: https://securepay.tinkoff.ru/v2/\n\n## Статусная модель платежа \nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`.|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL`, и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**ASYNC_REFUNDING**|Обработка возврата денежных средств по QR|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**CANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**ATTEMPTS_EXPIRED**|Клиент превысил количество попыток открытия формы|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схемах ниже изображен полный жизненный цикл платежа\n[![scheme](https://cdn.t-static.ru/static/documents/schemaSBPPayments.png)](https://cdn.t-static.ru/static/documents/schemaSBPPayments.png)\n\n## Привязка счёта\n### Таблица статусов привязки счёта\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос AddAccountQr или GetQr для сессии с рекуррентным платежом|\n|**PROCESSING**|QR сформирован и отправлен мерчанту|\n|**ACTIVE**|Привяза счета прошла успешно|\n|**INACTIVE**|Банк отклонил привязку счета|\n### Схема привязки счёта \n[![scheme](https://cdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)](https://cdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)\n\nНа схеме ниже приведены переходы статуса привязки счета при оплате с одновременной привязкой. Переходы статуса платежа в данной операции показаны на схеме полного жизненного цикла платежа\n[![scheme](https://cdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)](https://cdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)\n\n## Рекуррентный платеж\n### Таблица статусов рекуррентного платежа\n|Статус | Правило перехода|\n|--- | ---|\n|NEW | MAPI получил запрос Init. После этого он создает новый платеж в статусе NEW и возвращает обратно его идентификатор в параметре PaymentId|\n|FORM_SHOWED | MAPI принял запрос на обработку платежа. Ожидается подтверждение от НСПК о проведении оплаты по привязке|\n|AUTHORIZING | MAPI принял запрос от НСПК на авторизацию платежа|\n|AUTHORIZED | Платеж авторизован, деньги заблокированы на карте клиента|\n|CONFIRMING | Подтверждение платежа обрабатывается MAPI и платежной системой|\n|CONFIRMED | Платеж подтвержден, деньги списаны с карты клиента|\n|REFUNDING | Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|ASYNC_REFUNDING | Обработка возврата денежных средств по QR|\n|PARTIAL_REFUNDED | Частичный возврат по подтвержденному платежу завершился успешно|\n|REFUNDED | Полный возврат по подтвержденному платежу завершился успешно|\n|CANCELED | Мерчант отменил платеж|\n|REJECTED | Банк отклонил платеж|\n\n### Схема проведения рекуррентого платежа\n[![scheme](https://cdn.t-static.ru/static/documents/schtmaSBPRecurrent.png)](https://cdn.t-static.ru/static/documents/schtmaSBPRecurrent.png) \n\n\n### Логика привязки при наличии нескольких терминалов\n[![scheme;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png)](https://cdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png) \nЕсли клиент привязывает счет к терминалу мерчанта, у которого есть несколько терминалов, то клиент имеет возможность выполнять рекуррентные платежи на всех терминалах Мерчанта\n\nПроцесс выглядит следующим образом:\n1. Мерчанту принадлежат терминалы \"А\" и \"Б\", покупатель ранее проводил оплату только по терминалу \"А\".\n2. Покупатель пропбует провести рекуррентный платеж по терминалу \"Б\".\n3. Система проверяет наличие привязки по терминалу \"Б\".\n4. Так как привязка по этому терминалу не проводилась, система с помощью идентификатора магазина проверяет наличие привязки на других терминалах мерчанта. \n5. Система успешно находит привязку по терминалу \"А\", в связи с чем разрешает проведение рекуррентного платежа.\n\n# Подключение СБП\n## Откройте расчетный счёт\nДля подключения СБП клиент должен быть резидентом. Если клиент нерезидент, СБП работать не будет\n\nЗаполните [заявку](https://www.tbank.ru/business/) и откройте расчетный счет в Т‑Банке\n\n## Подключите Интернет эквайринг\nПодайте [заявку](https://business.tbank.ru/oplata/main) на подключение интернет эквайринг и заполните данные об организации и магазине\n## Выберите доступные типы интеграций\nСБП доступен для следующих типов интеграций:\n* Платежный [виджет](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Vidzhet-SBP),\n* Платежный [API](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Obshaya-informaciya-dlya-oplat-po-QR),\n* Мобильный [SDK](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Sposoby-integracii),\n* Через Агента ТСП,\n* Стикер с QR-кодом для размещения на кассе.\n\nДалее, настройте интеграцию на сайте, в мобильном приложении или в любом другом интерфейсе\n\n## Включение СБП\n\n### Требования к подключению СБП\nРасчётный счёт в Т‑Банке установлен в магазине счётом для выплат\n\n### Подключение СБП в Личном Кабинете\nВойдите в свой личный кабинет и откройте страницу магазина, для которого вы хотите подключить оплату\nчерез СБП. Перейдите на вкладку “Способы оплаты“\n\n[![sposobioplati;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)](https://cdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)\n\nНажмите \"Настроить“ на плашке Система быстрых платежей.\nДалее выбираете тот способ интеграции, который планируете использовать\n\n#### Платежная форма Т‑Банка\nЕсли планируете использовать её, то выбираете данную вкладку и нажимаете \"Включить\"\n\n[![sbp_pf_tinkoff_off;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_tinkoff_on;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)\n\n#### Собственная платежная форма\nЕсли у вас уже есть собственная платежная форма или вы хотите подключить виджет СБП, то необходимо нажать \"Включить\" в данной вкладке. После включения останется настроить интеграцию по API \n\n[![sbp_pf_svoya_off;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_svoya_on;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)\n\n#### Приложение \nЕсли вы планируете использовать СБП в своём приложении, то включаете соответствующую настройку, после чего следуете инструкции размещенной в данном разделе \n\n[![app_sbp_off:block;margin:auto|](https://cdn.t-static.ru/static/documents/app_sbp_off.jpg)](https://cdn.t-static.ru/static/documents/app_sbp_off.jpg)\n\nПосле включения вкладка будет выглядить следующим образом\n\n[![app_sbp_on:block;margin:auto|](https://cdn.t-static.ru/static/documents/app_sbp_on.jpg)](https://cdn.t-static.ru/static/documents/app_sbp_on.jpg)\n\n#### Статический QR\nВне зависимости от того, какой способ интеграции вы используете, вы всегда можете скачать статический QR-код в данном разделе\n\n[![novii_static_qr:block;margin:auto|](https://cdn.t-static.ru/static/documents/novii_static_qr.png)](https://cdn.t-static.ru/static/documents/novii_static_qr.png)\n\n\n### Настройка интеграций при включении способа оплаты СБП\n#### Платежная форма Т‑Банка\nПосле подключения СБП в Личном кабинете, QR код автоматически отобразится на платежной форме, ничего\nдополнительно интегрировать не нужно.\n[Описание](https://www.tbank.ru/kassa/develop/widget/install/), как интегрировать Платежную форму на сайт.\nПлатёжные формы Т‑Банка:\nМобильная\n\n[![pfsbpmobile;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/pfsbpmobile.png)](https://cdn.t-static.ru/static/documents/pfsbpmobile.png)\n\nДесктопная\n[![pfsbpdesktop;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/pfsbpdesktop.png)](https://cdn.t-static.ru/static/documents/pfsbpdesktop.png)\n\nВнимание! Способ — Оплата Картой, является обязательным, отключить его нельзя, все остальные\nспособы — опциональные и их можно выключить в Личном кабинете\n\n#### API\nЕсли ваша интеграция по API, то вы самостоятельно отображаете полученный QR-код или кнопку на вашем\nсайте или любом другом интерфейсе\n\n#### SDK\nЕсли ваша интеграция предусматривает исопользование мобильного приложения, то в SDK необходимо\nпередать специальные параметры в [IOS](https://opensource.tbank.ru/mobile-tech/asdk-ios) и [Android](https://opensource.tbank.ru/mobile-tech/asdk-android) для отображения QR кода\n\n#### Агентская интеграция\nЕсли ваша интеграция настроена с Агентом ТСП, то необходимо\n1. Создать магазин типа – **Выставление счета**.\n2. Включить СБП в способах оплаты.\n3. Сообщить Агенту ТСП об успешном включении.\n\nИнтерфейс \"SDK Т‑Банка\": \n\n[![sbpsdk1;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbpsdk1.png)](https://cdn.t-static.ru/static/documents/sbpsdk1.png)\n\n[![sbpsdk2;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbpsdk2.png)](https://cdn.t-static.ru/static/documents/sbpsdk2.png)\n\n### Прием платежей с помощью стикеров с QR-кодом\nСтикер со статичным QR кодом – платежный QR код который размещается в кассовой зоне магазина.\nПосле создании магазина в Личном кабинете, его можно скачать в режиме онлайн\n\n#### Получение стикера\nДля получения стикера с QR кодом небходимо:\n1. Создать магазин с выставлением счета, если у вас уже есть магазин, то далее п.2.\n2. Зайдите в настройки СБП в разделе \"Способы оплаты\".\n3. Нажать на кнопку \"скачать\" в разделе Статический QR. \n4. Полученный QR код необходимо распечатать и разместить в кассовой зоне вашего магазина.\nСтикер \"QR Т‑Банка”:\n\n\n[![sbpqr;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/novii_static_qr_skrin.png)](https://cdn.t-static.ru/static/documents/novii_static_qr_skrin.png)\n\n\nПосле сканирования покупателем Стикера с QR кодом ему необходимо будет ввести сумму и\nподтвердить оплату\n\n**Внимание!** Фискализация по операциям с помощью Стикера с QR-кодом не происходит через онлайн\nкассы, даже если онлайн кассы подключенны в личном кабинете\n\n#### Нотификации об оплате\nПосле оплаты вам придет нотификация в зависимости от настроек, на email или по http на ваш сервер\n\n**Магазин — Выставление счетов** \nНастройка нотификаций происходит через acq_help@tbank.ru\n\n**Магазин — Интернет магазин** \nЕсли у вас уже есть интернет-магазин, то нотификации вы можете самостоятельно настроить в разделе\nТерминал\n\n\n[![nastroikiterminala;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/nastroikiterminala.png)](https://cdn.t-static.ru/static/documents/nastroikiterminala.png)\n\n### Настроить выбор банка при интеграции по API\nЕсли вы интегрировались по API, то можно настроить выбор банка при оплате по СБП.\nДля этого нужно создать прямую ссылку, которая существует для того, чтобы перенаправить\nклиента при клике на ссылку в конкретное приложение банка.\n1. Чтобы сформировать прямую ссылку на переход в приложение банка, необходимо заменить\nhttps из функциональной ссылки на значение параметра schema из списка банков.\n2. Список банков лежит по ссылке - https://qr.nspk.ru/proxyapp/c2bmembers.json.\n\nНапример:\nФункциональная ссылка https://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nЗаменить https на соответствующую schema Т‑Банка —\nbank100000000004://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nДля каждого из банков сделать прямую ссылку по логике указанной в п.1. На Вашей платёжной форме\nнеобходимо отобразить список банков из п. 2\n\n# Виджет СБП\nСБП можно интегрировать с помощью виджета, ниже будет описан порядок такой интеграции\n\n## Подключение платежного виджета\n\n### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка \"Оплатить СБП\"\n```\n\n \n \n \n \n \n \n\n
    \n
    \n \n \n \n \n \n \n \n
    \n\n```\nСумма заказа \"amount\" указывается в рублях, копейки через точку\n\n## Формирование чека\n\nДобавьте в код поле ввода receipt:\n```\n\n```\nВ значении атрибута value поля receipt нужно указывать параметры чека. Например, добавьте следующий код:\n```\n var form = document.forms.TinkoffPayForm;\n\n // Данные для чека\n Object.defineProperty(form.receipt, 'value', {\n get: function () {\n return JSON.stringify({\n Email: form.email.value,\n Phone: form.phone.value,\n EmailCompany: 'mail@mail.com',\n Taxation: 'patent',\n Items: [\n {\n Name: form.description.value || 'Оплата',\n Price: form.amount.value + '00',\n Quantity: 1.0,\n Amount: form.amount.value + '00',\n PaymentMethod: 'full_prepayment',\n PaymentObject: 'service',\n Tax: 'none',\n },\n ],\n });\n },\n });\n```\n## Подключение СБП\n## Подключение СБП в Личном Кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернетмагазина, для которого вы хотите подключить оплату через СБП на сайте. Перейдите на вкладку “Способы оплаты”. Для подключения СБП надо провести первый платеж любым доступным способом.\n2. Нажмите на плашку СБП для подключения оплаты через СБП на сайте.\n3. В случае успешного подключения СБП для интернет-магазина плашка должна стать активной. \n## Настройка оплаты товаров\nДля подключения оплаты СБП для одного и более товаров потребуется передавать в метод initPayments объект настроек, в котором определено поле paymentItems \n\nЗначением поля paymentItems является массив объектов, которые определяют размещение платёжных кнопок и информацию о платеже\n\nПример кода приведен ниже:\n \n```\n var terminalkey = document.forms.TinkoffPayForm.terminalkey;\n\n var widgetParameters = {\n terminalKey: terminalkey.value,\n paymentItems: [\n {\n container: document.getElementById(\"tinkoffWidgetContainer1\"),\n paymentInfo: function () {\n return {\n paymentData: document.forms.TinkoffPayForm,\n };\n },\n },\n ],\n paymentSystems: { TinkoffFps: {} },\n };\n\n window.addEventListener(\"load\", function () {\n initPayments(widgetParameters);\n });\n\n```\n## Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Информация о платеже| \n## Тесты по QR\n* Сценарий “Платеж-успех” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту. \n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId).\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом CONFIRMED.\n* Сценарий “Платеж — отказ по таймауту” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId) и параметр IsDeadlineExpired = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом DEADLINE_EXPIRED.\n* Сценарий “Платеж – отказ, отклонен Т‑Кассой” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии\nТ‑Кассы (PaymentId) и параметр IsRejected = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом REJECTED.\n* Сценарий “Возврат – успех \n1) Инициировать возврат (не отмену) методом Cancel тестового платежа по QR-коду СБП,\nвыполненного успешно в тесте “Платеж-успех”\n2) Запросить текущий статус платежа вызывая метод **GetState**.\n3) Получить ответ со статусом REFUNDED.\n\n## Настройка платежного виджета\nВставьте идентификатор магазина в код платежного виджета в значение параметра terminalkey. Идентификатор магазина выдаётся банком,\nего можно получить в личном кабинете (раздел «Магазины», вкладка \"Терминалы\"):\n\nЕсли необходимо изменить состав полей платежного виджета, укажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо поле, выставьте у этого поля параметр required:\n```\n\n```\nСтилизация платежного виджета производится магазином самостоятельно. Ограничений на стилизацию со стороны Т‑Банка нет:\n```\n \n \n \n \n\n```\nПроверить статус платежа можно в личном кабинете интернет-эквайринга, просмотрев операции по СБП, по API с помощью метода [GetState](https://www.tbank.ru/kassa/dev/payments/#tag/Standartnyj-platyozh/paths/~1GetState/post) или с помощью нотификации по http или на e-mail в разделе [Нотификации мерчанта об операциях](https://www.tinkoff.ru/kassa/dev/payments/index.html#tag/Notifikacii-Merchanta-ob-operaciyah)" }, { "name": "Оплата через T‑Pay", - "description": "## Общая информация\nОплата доступна на мобильных устройствах и десктопах, проводится последовательным вызовом\nметодов:\n\n- `/TinkoffPay/terminals/{terminalKey}/status`,\n- `/Init`,\n- `/TinkoffPay/transactions/{paymentId}/versions/{version}/link` либо `/TinkoffPay/{paymentId}/QR`.\n\n# Другие способы интеграции \n\n## T‑Pay SDK\nT‑Pay SDK — интеграция способа оплаты в приложение. Документация по SDK активно поддерживается на GitHub. \nАдреса: \n* [SDK Android](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-android),\n* [SDK IOS](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-ios).\n\n## T‑Pay web\nT‑Pay web — способ интеграции через установку виджета на сайт\n\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n\n\n
    \n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n
    \n```\n#### Настройка платежного виджета\nВставьте идентификатор мерчанта в код платежного виджета в значение параметра terminalkey. Идентификатор мерчанта выдается Т‑Кассой,\nего можно получить в личном кабинете (раздел «Магазины»).\nЕсли необходимо изменить состав полей платежного виджета,\nукажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо\nполе, выставьте у этого поля параметр required:\n```\n \n```\nЕсли требуется открывать платежную форму в текущем окне,\nукажите у данного атрибута значение true:\n```\n \n```\nСтилизация платежного виджета производится мерчантом\nсамостоятельно. Ограничений на стилизацию со стороны Т‑Кассы нет:\n```\n \n```\n### Подключение T‑Pay\n#### Подключение T‑Pay в личном кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернет-магазина, для которого вы хотите подключить оплату через T‑Pay на сайте. Перейдите на вкладку «Способы оплаты».\n2. Нажмите кнопку «Настроить» на плашке T‑Pay, перейдите в подраздел «Своя платежная\nформа» и нажмите «Включить».\n3. В случае успешного подключения T‑Pay для интернет-магазина должна отобразиться\nстраница активного статуса подключения T‑Pay на сайте.\n\n\n#### Подключение T‑Pay на страницах интернет-магазина\nВставьте приведенный ниже код на страницу вашего сайта сразу после кода платежного виджета:\n```\n\n\n```\n\n\nМетод initPayments запускает инициализацию платежных кнопок T‑Pay.\nВходным параметром метода является объект с данными о настройках проведения платежей\n##### Структура объекта T‑Pay\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n\n### Настройка оплаты множества товаров\nДля подключения оплаты T‑Pay на одной странице для нескольких товаров потребуется передавать в метод initPayments объект\nнастроек, в котором определено поле paymentItems.\nЗначением поля paymentItems является массив объектов, которые определяют размещение платежных кнопок и информацию о платеже.\nПример кода страницы приведен ниже:\n```\n
    \n\n
    \n\n\n```\n\n#### Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n## T‑Pay + T‑ID.\nДля интеграции T‑Pay + T‑ID, предварительно требуется настроить интеграцию с ID. Ознакомиться с его API можно по ссылке https://developer.tbank.ru/products/scenarios/TID/w2w\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n\n\n
    \n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n
    \n```\n#### Настройка платежного виджета\nВставьте идентификатор мерчанта в код платежного виджета в значение параметра terminalkey. Идентификатор мерчанта выдается Т‑Кассой,\nего можно получить в личном кабинете (раздел «Магазины»).\nЕсли необходимо изменить состав полей платежного виджета,\nукажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо\nполе, выставьте у этого поля параметр required:\n```\n \n```\nЕсли требуется открывать платежную форму в текущем окне,\nукажите у данного атрибута значение true:\n```\n \n```\nСтилизация платежного виджета производится мерчантом\nсамостоятельно. Ограничений на стилизацию со стороны Т‑Кассы нет:\n```\n \n```\n### Подключение T‑Pay\n#### Подключение T‑Pay в личном кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернет-магазина, для которого вы хотите подключить оплату через T‑Pay на сайте. Перейдите на вкладку «Способы оплаты».\n2. Нажмите кнопку «Настроить» на плашке T‑Pay, перейдите в подраздел «Своя платежная\nформа» и нажмите «Включить».\n3. В случае успешного подключения T‑Pay для интернет-магазина должна отобразиться\nстраница активного статуса подключения T‑Pay на сайте.\n\n\n#### Подключение T‑Pay на страницах интернет-магазина\nВставьте приведенный ниже код на страницу вашего сайта сразу после кода платежного виджета:\n```\n\n\n```\n\n\nМетод initPayments запускает инициализацию платежных кнопок T‑Pay.\nВходным параметром метода является объект с данными о настройках проведения платежей\n##### Структура объекта T‑Pay\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n\n### Настройка оплаты множества товаров\nДля подключения оплаты T‑Pay на одной странице для нескольких товаров потребуется передавать в метод initPayments объект\nнастроек, в котором определено поле paymentItems.\nЗначением поля paymentItems является массив объектов, которые определяют размещение платежных кнопок и информацию о платеже.\nПример кода страницы приведен ниже:\n```\n
    \n\n
    \n\n\n```\n\n#### Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n## T‑Pay + T‑ID.\nДля интеграции T‑Pay + T‑ID, предварительно требуется настроить интеграцию с ID. Ознакомиться с его API можно по ссылке https://developer.tbank.ru/products/scenarios/TID/w2w\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n\n\n```\nДинамическая интеграция (Если iframe генерируется динамически):\n```\n
    \n \n\n```\n##### Настройка\nКласс Integration принимает 2 аргумента:\n1. HTMLIFrameElement — iframe DOM элемент.\n2. config — необязательный аргумент с конфигурацией PaymentFormIntegrationConfig.\n\nPaymentFormIntegrationConfig: \n```\ninterface PaymentFormIntegrationConfig {\n iframe: {\n element: HTMLIFrameElement;\n /**\n * Используется если скрипт встраивается в промежуточный iframe\n */\n proxy?: true;\n /**\n * Вызывается в момент получения deepLink из ПФ\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n deepLinkRedirectCallback?: (url: string) => void;\n /**\n * Вызывается в момент получения exit из ПФ\n * Например при нажатии кнопки \"Вернуться в магазин\"\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n exitRedirectCallback?: (url: string) => void;\n };\n}\n```\nЕсли Вам не требуется перенаправлять родительскую страницу на возврат в магазин, а требуется просто закрыть модальное окно с платежной формой — замените этот параметр конфигурации\n\nПример инициализации скрипта с конфигурацией: \n```\nvar paymentForm = new PaymentForm.Integration({\n iframe: {\n element: document.getElementById('payment-form'),\n exitRedirectCallback: (url) => {\n // Вызов закрытия модального окна\n }\n }\n});\n```\n##### Iframe внутри iframe\nБываю случаи когда приложение используется внутри iframe, который находится внутри другого iframe. В таком случае необходимо встроить скрипт с ключом proxy: true во все промежуточные iframe.\nПример инициализации скрипта для основной страницы: \n```\n\n \n\n\n```\nПример инициализации скрипта для вложенного iframe: \n```\n\n \n\n\n```\n\"Промежуточный\" скрипт, будет перенаправлять сообщения в каждый следующий iframe\n\nКоллбеки событий будут отрабатывать вызываться в \"промежуточных\" iframe только в случае их переопределения в config\n##### Как работает скрипт\nОбщение между формой и родителем, происходит через *window.postMessage()*\n\n1. После успешной загрузки, платежная форма внутри iframe отправляет сообщение loaded родителю.\n2. После получения loaded из ПФ, скрипт отправляет сообщение ready на Платежную форму, таким образом происходит рукопожатие и платежная форма определяет что может отобразить кнопочные методы оплаты.\n3. Действиями Клиента на Платежной форме вызывается способ оплаты возвращающий DeepLink на ресурс платежного сервиса.\n4. Платежная форма, передает DeepLink в целевое окно клиента, с помощью события deepLink.\n5. Целевое окно выполняет редирект Клиента, по ссылке полученной в DeepLink, с помощью вызова *deepLinkRedirectCallback*.\n6. Аналогично передаются и другие сообщения.\n\n
    \n\n### Кастомизация на платежной форме\nНа платежной форме доступна функция кастомизации, которая позволяет настроить форму под себя и своих клиентов. Для установки кастомизации обратитесь к вашему персональному менеджеру и передайте пожелания по настройкам \n\n#### Список доступных настроек кастомизации: \n|**Возможности кастомизации** | **Доп. описание**|\n|--- | ---|\n|Брендирование UI платежной формы |
  • добавлять лого своей компании на ПФ (логотип отобразится рядом с суммой заказа) 
  • управлять цветами кнопок (кнопка \"Оплатить\" и другие кнопки со страниц статусов и модальных окон)
  • |\n|Управление блоком детализации (информация о заказе и магазине) |
  • делать блок свернутым и развернутым по-умолчанию
  •  скрывать  блок с детализацией на ПФ
  • менять порядок строк в детализации
  • |\n|Управление светлой и темной темой |
  • показывать темную или светлую тему по-умолчанию
  • отключать темной/светлой темы
  • |\n\n\n\n\n## Инструкции по безопасности при интеграции\nУбедитесь, что вы используете последнюю версию интеграции, а также [генерируете и передаете корректный токен](https://www.tbank.ru/kassa/dev/payments/#section/Podpis-zaprosa) независимо от способа интеграции.
    Если ваш сайт собран на CMS, то необходимо использовать новейшую версию платежного модуля, доступную на [сайте Т‑Кассы](https://www.tbank.ru/kassa/dev/cms/) — это доступный источник актуальных версий. Современные модули для популярных CMS генерируют корректный токен автоматически\n\nТакже мы расписали несколько дополнительных обязательных мер, которые необходимо соблюдать при интеграции с MAPI, а именно: \n\n1. Наиболее безопасный способ передачи данных от Мерчанта в MAPI — прямая интеграция бэкенда Мерчанта с бэкендом Т‑Кассы. В этом случае злоумышленник сможет перехватить запрос только если окажется в локальной сети Мерчанта.\n\n2. При любых способах интеграции с MAPI (в том числе и с помощью нашего платежного виджета) необходимо сверять параметры созданных заказов. В случае выявления расхождений между суммой операции, инициированной клиентом, и суммой совершенной операции, не осуществляйте доставку товара клиенту и незамедлительно уведомите Т‑Банк об этом. Для сверки параметров есть несколько способов:\n\t
    2.1. Получение нотификаций:\n\t\n\t- **По e-mail**: на указанную почту придет письмо при переходе платежа в статус «CONFIRMED»;\n\t\n\t- **По http**: MAPI будет отправлять POST-запрос при каждом изменении статуса платежа на URL, указанный в настройках терминала.\n\t\n\t
    2.2. Вызов метода GetState, который возвращает основные параметры и текущий статус платежа. Рекомендуется сверять/валидировать дополнительные данные заказа — `PaymentId` и `Amount`.\n\n3. Обновляйте модули для CMS. Современные модули для популярных CMS сверяют суммы заказов автоматически.\n\nЕсли на вашем сайте не применены описанные выше меры безопасности или используете программное обеспечение для интеграции, полученное не с [сайта Т‑Кассы](https://www.tbank.ru/kassa/develop/), вы самостоятельно отвечаете за возможные риски и неблагоприятные последствия, связанные с использованием такого программного обеспечения\n\n## Обработка карточных данных\nПлатежные системы разработали требования к безопасности карточных данных клиентов — **Payment Card Industry Data Security Standard** (PCI DSS). Компания должна пройти сертификацию, чтобы подтвердить надежность управления карточной информацией\n\nЕсли у вас нет сертификации PCI DSS, вы можете использовать платежную форму Т‑Кассы. В этом случае, все операции, связанные с обработкой критичных данных производятся на стороне Т‑Кассы. Мерчанту достаточно настроить интеграцию с MerchantAPI и инициализировать платеж. Клиент будет перенаправлен на платежную форму, в которую он сможет ввести данные карты. Когда платеж завершится, клиент снова увидит сайт Мерчанта. Подробную информацию о подключении эквайринга смотрите в разделе Non PCI DSS. \n\nЕсли ваш ресурс соответствует требованиям PCI DSS, то вы можете собирать и хранить карточные данные клиентов. В таком случае, MerchantAPI получает зашифрованные карточные данные от Мерчанта. Подробную информацию о подключении такого способа смотрите в разделе PCI DSS.\n\n# Передача признака инициатора операции\nПлатежные системы хотят понимать, кем была инициирована карточная операция. Особенно остро эта необходимость проявляется в случае проведения операций без 3ds и по сохраненным реквизитам\n\nДля выполнения требования регулятора мы добавили в метод /Init новый атрибут OperationInitiatorType. В значении этого атрибута ожидаем получать признак того, кем была инициирована операция и какой способ предоставления реквизитов был использован\n\nПодробное описание сценариев проведения операций, значений OperationInitiatorType, взаимосвязь с другими атрибутами и типами терминалов:\n|Тип операции и инициатор|Описание|Сценарий карточной операции|OperationInitiatorType|RebillId в /Charge|Recurrent в /Init|AFT терминал|ECOM терминал|\n|---|---|---|---|---|---|---|---|\n|Сustomer Initiated Credential-Not-Captured (CIT CNC)|Инициированная покупателем оплата без сохранения реквизитов карты для последующего использования|Стандартный платеж|0|null|N|Разрешено|Разрешено|\n|Сustomer Initiated Credential-Captured (CIT CC)|Инициированная покупателем оплата c сохранением реквизитов карты для последующего использования|Стандартный платеж с созданием родительского рекуррентного платежа|1|null|Y|Разрешено|Разрешено|\n|Сustomer Initiated Credential-on-File (CIT COF)|Инициированная покупателем оплата по сохраненным реквизитам карты (ранее была проведена операция с сохранением реквизитов CIT CC)|Рекуррентный платеж, инициированный покупателем|2|not null|N|Запрещено|Разрешено|\n|Merchant Initiated Credential-on-File, Recurring (CIT COF R)|Инициированные торговым предприятием повторяющиеся платежи **без графика** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяются для оплаты коммунальных услуг, платежей за услуги связи, кабельное/спутниковое телевидение и прочее. Сумма может быть определена заранее или становится известна непосредственно перед оплатой|Рекуррентный платеж, инициированный торговым предприятием|R|not null|N|Запрещено|Разрешено|\n|Merchant Credential-on-File, Installment (CIT COF I)|Инициированные торговым предприятием повторяющиеся платежи **по графику** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяется для платежей в рассрочку по товарному кредиту, для оплаты страховки в рассрочку, для погашения кредита в соответствии с графиком платежей. График платежей может быть изменен по соглашению сторон, т.е. суммы и даты платежей должны быть известны плательщику (держателю карты) до момента проведения операции.|Рекуррентный платеж, инициированный торговым предприятием|I|not null|N|Разрешено|Запрещено|\n\n# Какими терминами пользуемся в документации?\n| **Термин** | Определение |\n| ------ | -------- |\n| **Клиент** | Физлицо, производящее перевод с использованием банковской карты на сайте Мерчанта |\n| **Мерчант** | Бизнес, принимающий и осуществляющий переводы по банковским картам на своем сайте |\n| **Т‑Касса** | Сервис, помогающий проводить выплату клиенту-физлицу |\n| **Эмитент** | Банк, выпустивший карту клиента-физлица |\n| **PCI DSS**| Международный стандарт безопасности, созданный для защиты данных банковских карт |\n| **3-D Secure** | Протокол, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт. 3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей |\n| **Терминал** | Точка приема платежей Мерчанта (в общем случае привязывается к сайту, на котором осуществляется прием платежей). Далее в этой документации описан протокол для терминала мерчанта.
    Для проведения тестов используются данные тестового терминала TinkoffBankTest (пароль аналогичен) |\n| **ККМ** | Контрольно-кассовая машина|\n|**Личный кабинет Мерчанта**|[Веб-приложение](https://business.tbank.ru/oplata/main), в котором Мерчант управляет интернет-эквайрингом - настраивает параметры терминалов, подтверждает или отменяет платежи, анализирует статистику|\n\n\n# Параметры терминала\nКаждый терминал обладает свойствами, которые влияют на те или иные аспекты приёма платежей. Эти свойства настраиваются при подключении интернет-эквайринга и могут быть изменены в Личном кабинете Мерчанта\n\nВ таблице ниже перечислены основые параметры приёма платежей для терминала\n\n|Название параметра|Формат|Описание|\n|---|---|---|\n|TerminalKey|20 символов (чувствительно к регистру)|Уникальный символьный ключ терминала. Устанавливается Т‑Кассой|\n|Success URL|250 символов(чувствительно к регистру)| URL на веб-сайте Мерчанта, куда будет переведен клиент в случае успешной оплаты
    — true - платеж завершился успешно
    — false — платеж не завершился *\n|Fail URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент в случае неуспешной оплаты *\n|Success Add Card URL| 250 символов (чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после успешной привязки карты *|\n|Fail Add Card URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после неуспешной привязки карты *|\n|Notification URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет отправлен POST запрос о статусе выполнения вызываемых методов. Только для методов **Authorize**, **FinishAuthorize**, **Confirm**, **Cancel**|\n|Валюта терминала|3 символа| Валюта, в которой будут происходить списания по данному терминалу, если иное не передано в запросе|\n|Активность терминала|Рабочий /Неактивный /Тестовый|Определяет режим работы данного терминала|\n|Password |20 символов(чувствительно к регистру)|Используется для подписи запросов/ответов. Является секретной информацией, известной только Мерчанту и Т‑Кассе. Пароль находится в [личном кабинете](https://business.tbank.ru/oplata/main) мерчанта\n|Отправлять нотификацию на FinishAuthorize|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **FinishAuthorize** (по умолчанию да)|\n|Отправлять нотификацию на Completed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **AttachCard** (по умолчанию Да)|\n|Отправлять нотификацию на Reversed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **Cancel** (по умолчанию Да)|\n\n\\* *в URL можно указать необходимые параметры в виде ${<параметр>}, которые будут переданы на URL\nметодом GET*\n\n# Подпись запроса\nПеред выполнением запроса MAPI проверяет, можно ли доверять его инициатору. Для этого сервер проверяет подпись запроса. В MAPI используется механизм подписи с помощью токена. Мерчант должен добавлять токен к каждому запросу, где это требуется. \n\n> В описании входных параметров для каждого метода мы указали, нужно подписывать запрос или нет. Токен формируется на основании тех полей, которые присутствуют в запросе, поэтому токены для каждого запроса уникальные, и не совпадают никогда\n\n**Токен** в MAPI — это строка, в которой Мерчант зашифровал данные своего запроса с помощью пароля. Для создания токена Мерчант использует пароль из Личного кабинета мерчанта\n\nРассмотрим на примере процесс шифрования тела запроса для метода Init:\n```json\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"Token\": \"68711168852240a2f34b6a8b19d2cfbd296c7d2a6dff8b23eda6278985959346\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 3500,\n \"Quantity\": 2,\n \"Amount\": 7000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 550,\n \"Quantity\": 4,\n \"Amount\": 4200,\n \"Tax\": \"vat10\"\n }\n ]\n }\n}\n```\n\nЧтобы зашифровать данные запроса Мерчант должен выполнить следующие шаги:\n1. Собрать массив передаваемых данных в виде пар Ключ-Значения. В массив нужно добавить только параметры корневого объекта. Вложенные объекты и массивы не участвуют в расчете токена. В примере ниже в массив включены параметры `TerminalKey`, `Amount`, `OrderId`, `Description` и исключен объект `Receipt` и `DATA`.\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"}]\n```\n\n2. Добавить в массив пару {`Password`, Значение пароля}. Пароль можно найти в личном кабинете Мерчанта\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"Password\": \"usaf8fw8fsw21g\"}]\n```\n\n3. Отсортировать массив по алфавиту по ключу.\n```JSON\n[{\"Amount\": \"19200\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"OrderId\": \"21090\"},{\"Password\": \"usaf8fw8fsw21g\"},{\"TerminalKey\": \"MerchantTerminalKey\"}]\n```\n\n4. Конкатенировать только **значения** пар в одну строку.\n```JSON\n\"19200Подарочная карта на 1000 рублей21090usaf8fw8fsw21gMerchantTerminalKey\"\n```\n\n5. Применить к строке хеш-функцию SHA-256 (с поддержкой UTF-8).\n```JSON\n\"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n```\n\n6. Добавить получившийся результат в значение параметра `Token` в тело запроса и отправить запрос.\n```JSON\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 20000,\n \"Quantity\": 2,\n \"Amount\": 40000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 30000,\n \"Quantity\": 3,\n \"Amount\": 90000,\n \"Tax\": \"vat10\"\n }\n ]\n },\n \"Token\": \"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n}\n```\nПроверить корректность формирования токена можно сервисом https://tokentcs.web.app\n\n> Помимо этого информацию о корректности токена можно проверить в ЛК ИЭ в разделе \"Операции\".\nВыберите нужный заказ, затем \"Дополнительная информация о заказе\", поле \"inittokenisvalid\". Если значение в этом поле будет \"true\", это означает, что токен валидный. Если \"false\", то токен передан некорректный.\n" + "description": "# Введение\n\n## Подключение интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг помогает принимать онлайн-платежи так, как удобно вам и покупателю: на сайте, в мобильном приложении, соцсетях, мессенджерах, по e-mail или СМС. Вы можете принимать оплату разными способами, возвращать и замораживать выплаты, настраивать рекуррентные платежи\n\nЧтобы подключить интернет-эквайринг, оставьте [заявку на сайте Т‑Банка](https://www.tbank.ru/kassa/) и заполните анкету компании или ИП. Подробности подключения можете узнать [в Т-Помощи](https://www.tbank.ru/business/help/business-payments/internet-acquiring/how-involve/connect/?card=q1) или у персонального менеджера\n\n## Способы интеграции интернет-эквайринга от Т‑Кассы\n\nИнтернет-эквайринг нужно интегрировать — настроить оплату на сайте или в приложении. Есть четыре способа интеграции:\n\n* Платежный модуль — для сайтов на CMS,\n* Платежный виджет — для самописного сайта,\n* SDK — для мобильного приложения,\n* API — для разработки своей интеграции.\n\nИнтеграцию можно выполнить самостоятельно или с помощью разработчика\n\n### Платежный модуль\n\nСпособ интеграции интернет-эквайринга с сайтом, созданным на основе CMS. Вы устанавливаете модуль — на странице сайта появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nМодуль подходит, если ваш сайт собран на CMS — например, 1С-Битрикс, WordPress или Taplink. Т‑Касса поддерживает многие популярные CMS, в некоторые уже встроены модули — их устанавливать не нужно\n\n[Инструкции по интеграции с помощью платежного модуля](https://www.tbank.ru/kassa/dev/cms/)\n\n### Платежный виджет\n\nСпособ интеграции интернет-эквайринга с самописным сайтом. Вы вставляете готовый код на страницу сайта — на этом месте появляется кнопка оплаты. Покупатель нажимает на кнопку и переходит на платежную форму с разными способами оплаты: банковскими картами, по T‑Pay, SberPay, Mir Pay, СБП, Долями, в рассрочку. Вы можете выбрать, какие способы оплаты оставить в форме: все или некоторые.\n\nВиджет подходит в двух случаях:\n* ваш сайт самописный или на CMS, для которой в Т‑Банке нет платежного модуля;\n* вы не планируете принимать автоплатежи.\n\nДля интеграции виджета потребуется помощь программиста\n\n[Инструкция по интеграции с помощью виджета](https://www.tbank.ru/kassa/dev/widget/)\n\n### Мобильный SDK\nСпособ интеграции интернет-эквайринга с мобильным приложением. Покупатель оплачивает товар без перехода в мобильный браузер, оставаясь внутри вашего приложения\n\nС помощью SDK вы можете разместить платежную форму Т‑Кассы — со всеми или некоторыми способами оплаты. Также с помощью SDK вы можете отдельно встраивать способы оплаты — например, T‑Pay или СБП — в вашу платежную форму\n\nSDK подходит, если принимаете оплату в приложении на Android начиная с версии 7.0 или iOS начиная с версии 12.3. С инструкцией по подключению SDK в ЛК можно ознакомиться по ссылкам ниже:\n\n[Инструкция для Android начиная с версии 7.0](https://opensource.tbank.ru/mobile-tech/asdk-android)\n\n[Инструкция для iOS начиная с версии 12.3](https://opensource.tbank.ru/mobile-tech/asdk-ios)\n\n### API\nСамый гибкий и сложный способ интеграции интернет-эквайринга. Например, API подходит, если у вас самописный сайт и вы хотите настроить оплату под запросы бизнеса: совмещать в платежной форме разные способы оплаты, принимать рекуррентные платежи или подключать другие сервисы Т‑Кассы\n\nДля интеграции потребуется помощь программиста\n\n[Документация по API](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Rekomendacii-pri-integracii)\n\n## Платежная форма\nПлатежная форма — это готовый интерфейс с встроенными способами оплаты, который позволяет принимать платежи онлайн\n\nДля использования платежной формы необходимо подключить интернет-эквайринг, настроить терминал и интегрировать платежную форму на ваш сайт одним из способов выше(кроме SDK)\n### Платежная форма в webview\nНекоторые webview не умеют обрабатывать DeepLink ссылки. Из-за этого способы оплаты, которые осуществляют переход в мобильное приложение во время платежа (СБП, Mir Pay, T‑Pay), могут работать некорректно\n\nВ случае использования платежной формы в webview необходимо учесть особенности вашей интеграции и сделать необходимые доработки для поддержки DeepLink\n\nПо результатам доработок необходимо дополнительно протестировать корректную работу всех способов оплат. В случае обнаружения проблем, требуется связаться с разработчиками webview модуля для их устранения, либо рекомендуется отключить неработающие способы оплаты\n**Ссылки с примерами решений**:\n1. [Первое решение(java,kotlin)](https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/webview/upi-intent-android/#13-handle-deep-links-in-shouldoverrideurlloading-),\n2. [Второе решение(java)](https://stackoverflow.com/questions/25672330/how-to-enable-deep-linking-in-webview-on-android-app).\n\n#### Рекомендации по интеграции\nПлатформа IOS:\nЧтобы deeplink работал в web — есть 2 варианта решения:\n1. Использовать SFSafariViewController, он умеет открывать диплинки, дополнительная настройка не нужна.\n2. Если используете WKWebView он не умеет открывать диплинки из коробки, чтобы его научить, надо обработать открытие диплинка Т‑Банка, пример описан ниже.\n\n**Пример реализации обработки открытия диплинка Т‑Банка** \n```\nnavigationDelegate = self\nfunc webView(\n _ webView: WKWebView,\n decidePolicyFor navigationAction: WKNavigationAction,\n decisionHandler: @escaping (WKNavigationActionPolicy) -> Void\n) {\n if let url = navigationAction.request.url, let scheme = url.scheme {\n if scheme != \"https\" && scheme != \"http\" {\n UIApplication.shared.open(url)\n }\n }\n decisionHandler(.allow)\n}\n```\n\n### Платежная форма в iframe\nНе рекомендуется использовать платежную форму в iframe для мобильных версий сайтов, так как у кнопочных способов оплаты могут возникать проблемы с открытием DeepLink и переходов в мобильное приложение для оплаты (СБП, Mir Pay, T‑Pay). Это связано с тем, что Iframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe\n\nЕсли в мобильной версии сайта использование iframe обязательно, вам необходимо сделать доработки согласно инструкции ниже, чтобы вы могли использовать кнопочные способы оплаты. Она позволит произвести переход в стороннее приложение. Доработки представляют собой скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице.\n\nПосле реализации доработок необходимо протестировать корректную работу всех способов оплат. В случае проблем и вопросов вы можете обратиться в нашу поддержку acq_help@tbank.ru\n\nВ десктопной версии iframe кнопочные способы оплаты будут работать без специальных доработок\n\n
    Инструкция по доработкам для mobile iframe\n
    \nIframe является изолированным контейнером, из-за этого переходы на сторонние ссылки не могут быть обработаны внутри iframe (переход будет внутри iframe). Чтобы произвести переход в стороннее приложение требуется скрипт \"снаружи\" iframe, который получит сообщение о переходе от iframe и вызовет его на основной странице\n\nВ случае если у вас подключены способы оплаты, использующие deeplink, а именно: T‑Pay, СБП или Mir Pay, то в процессе оплаты может возникать ошибка\n\n##### Информация\nСкрипт общается с фреймом по средствам *window.postMessage()*\n\nДобавление скрипта решает проблему передачи ссылки на ресурс платежного сервиса, для способов оплаты использующих DeepLink. Данная проблема может возникнуть при попытке передачи ссылки в браузер Клиента, из контейнера Платежной формы расположенного в теге ``\n \n\n\n```\nДинамическая интеграция (Если iframe генерируется динамически):\n```\n
    \n \n\n```\n##### Настройка\nКласс Integration принимает 2 аргумента:\n1. HTMLIFrameElement — iframe DOM элемент.\n2. config — необязательный аргумент с конфигурацией PaymentFormIntegrationConfig.\n\nPaymentFormIntegrationConfig: \n```\ninterface PaymentFormIntegrationConfig {\n iframe: {\n element: HTMLIFrameElement;\n /**\n * Используется если скрипт встраивается в промежуточный iframe\n */\n proxy?: true;\n /**\n * Вызывается в момент получения deepLink из ПФ\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n deepLinkRedirectCallback?: (url: string) => void;\n /**\n * Вызывается в момент получения exit из ПФ\n * Например при нажатии кнопки \"Вернуться в магазин\"\n * Стандартное значение: (url) => {window.location.href = url}\n * @param url\n */\n exitRedirectCallback?: (url: string) => void;\n };\n}\n```\nЕсли Вам не требуется перенаправлять родительскую страницу на возврат в магазин, а требуется просто закрыть модальное окно с платежной формой — замените этот параметр конфигурации\n\nПример инициализации скрипта с конфигурацией: \n```\nvar paymentForm = new PaymentForm.Integration({\n iframe: {\n element: document.getElementById('payment-form'),\n exitRedirectCallback: (url) => {\n // Вызов закрытия модального окна\n }\n }\n});\n```\n##### Iframe внутри iframe\nБываю случаи когда приложение используется внутри iframe, который находится внутри другого iframe. В таком случае необходимо встроить скрипт с ключом proxy: true во все промежуточные iframe.\nПример инициализации скрипта для основной страницы: \n```\n\n \n\n\n```\nПример инициализации скрипта для вложенного iframe: \n```\n\n \n\n\n```\n\"Промежуточный\" скрипт, будет перенаправлять сообщения в каждый следующий iframe\n\nКоллбеки событий будут отрабатывать вызываться в \"промежуточных\" iframe только в случае их переопределения в config\n##### Как работает скрипт\nОбщение между формой и родителем, происходит через *window.postMessage()*\n\n1. После успешной загрузки, платежная форма внутри iframe отправляет сообщение loaded родителю.\n2. После получения loaded из ПФ, скрипт отправляет сообщение ready на Платежную форму, таким образом происходит рукопожатие и платежная форма определяет что может отобразить кнопочные методы оплаты.\n3. Действиями Клиента на Платежной форме вызывается способ оплаты возвращающий DeepLink на ресурс платежного сервиса.\n4. Платежная форма, передает DeepLink в целевое окно клиента, с помощью события deepLink.\n5. Целевое окно выполняет редирект Клиента, по ссылке полученной в DeepLink, с помощью вызова *deepLinkRedirectCallback*.\n6. Аналогично передаются и другие сообщения.\n\n
    \n\n### Кастомизация на платежной форме\nНа платежной форме доступна функция кастомизации, которая позволяет настроить форму под себя и своих клиентов. Для установки кастомизации обратитесь к вашему персональному менеджеру и передайте пожелания по настройкам \n\n#### Список доступных настроек кастомизации: \n|**Возможности кастомизации** | **Доп. описание**|\n|--- | ---|\n|Брендирование UI платежной формы |
  • добавлять лого своей компании на ПФ (логотип отобразится рядом с суммой заказа) 
  • управлять цветами кнопок (кнопка \"Оплатить\" и другие кнопки со страниц статусов и модальных окон)
  • |\n|Управление блоком детализации (информация о заказе и магазине) |
  • делать блок свернутым и развернутым по-умолчанию
  •  скрывать  блок с детализацией на ПФ
  • менять порядок строк в детализации
  • |\n|Управление светлой и темной темой |
  • показывать темную или светлую тему по-умолчанию
  • отключать темной/светлой темы
  • |\n\n\n\n\n## Инструкции по безопасности при интеграции\nУбедитесь, что вы используете последнюю версию интеграции, а также [генерируете и передаете корректный токен](https://www.tbank.ru/kassa/dev/payments/#section/Podpis-zaprosa) независимо от способа интеграции.
    Если ваш сайт собран на CMS, то необходимо использовать новейшую версию платежного модуля, доступную на [сайте Т‑Кассы](https://www.tbank.ru/kassa/dev/cms/) — это доступный источник актуальных версий. Современные модули для популярных CMS генерируют корректный токен автоматически\n\nТакже мы расписали несколько дополнительных обязательных мер, которые необходимо соблюдать при интеграции с MAPI, а именно: \n\n1. Наиболее безопасный способ передачи данных от Мерчанта в MAPI — прямая интеграция бэкенда Мерчанта с бэкендом Т‑Кассы. В этом случае злоумышленник сможет перехватить запрос только если окажется в локальной сети Мерчанта.\n\n2. При любых способах интеграции с MAPI (в том числе и с помощью нашего платежного виджета) необходимо сверять параметры созданных заказов. В случае выявления расхождений между суммой операции, инициированной клиентом, и суммой совершенной операции, не осуществляйте доставку товара клиенту и незамедлительно уведомите Т‑Банк об этом. Для сверки параметров есть несколько способов:\n\t
    2.1. Получение нотификаций:\n\t\n\t- **По e-mail**: на указанную почту придет письмо при переходе платежа в статус «CONFIRMED»;\n\t\n\t- **По http**: MAPI будет отправлять POST-запрос при каждом изменении статуса платежа на URL, указанный в настройках терминала.\n\t\n\t
    2.2. Вызов метода GetState, который возвращает основные параметры и текущий статус платежа. Рекомендуется сверять/валидировать дополнительные данные заказа — `PaymentId` и `Amount`.\n\n3. Обновляйте модули для CMS. Современные модули для популярных CMS сверяют суммы заказов автоматически.\n\nЕсли на вашем сайте не применены описанные выше меры безопасности или используете программное обеспечение для интеграции, полученное не с [сайта Т‑Кассы](https://www.tbank.ru/kassa/develop/), вы самостоятельно отвечаете за возможные риски и неблагоприятные последствия, связанные с использованием такого программного обеспечения\n\n## Обработка карточных данных\nПлатежные системы разработали требования к безопасности карточных данных клиентов — **Payment Card Industry Data Security Standard** (PCI DSS). Компания должна пройти сертификацию, чтобы подтвердить надежность управления карточной информацией\n\nЕсли у вас нет сертификации PCI DSS, вы можете использовать платежную форму Т‑Кассы. В этом случае, все операции, связанные с обработкой критичных данных производятся на стороне Т‑Кассы. Мерчанту достаточно настроить интеграцию с MerchantAPI и инициализировать платеж. Клиент будет перенаправлен на платежную форму, в которую он сможет ввести данные карты. Когда платеж завершится, клиент снова увидит сайт Мерчанта. Подробную информацию о подключении эквайринга смотрите в разделе Non PCI DSS. \n\nЕсли ваш ресурс соответствует требованиям PCI DSS, то вы можете собирать и хранить карточные данные клиентов. В таком случае, MerchantAPI получает зашифрованные карточные данные от Мерчанта. Подробную информацию о подключении такого способа смотрите в разделе PCI DSS.\n\n# Передача признака инициатора операции\nПлатежные системы хотят понимать, кем была инициирована карточная операция. Особенно остро эта необходимость проявляется в случае проведения операций без 3ds и по сохраненным реквизитам\n\nДля выполнения требования регулятора мы добавили в метод /Init новый атрибут OperationInitiatorType. В значении этого атрибута ожидаем получать признак того, кем была инициирована операция и какой способ предоставления реквизитов был использован\n\nПодробное описание сценариев проведения операций, значений OperationInitiatorType, взаимосвязь с другими атрибутами и типами терминалов:\n|Тип операции и инициатор|Описание|Сценарий карточной операции|OperationInitiatorType|RebillId в /Charge|Recurrent в /Init|AFT терминал|ECOM терминал|\n|---|---|---|---|---|---|---|---|\n|Сustomer Initiated Credential-Not-Captured (CIT CNC)|Инициированная покупателем оплата без сохранения реквизитов карты для последующего использования|Стандартный платеж|0|null|N|Разрешено|Разрешено|\n|Сustomer Initiated Credential-Captured (CIT CC)|Инициированная покупателем оплата c сохранением реквизитов карты для последующего использования|Стандартный платеж с созданием родительского рекуррентного платежа|1|null|Y|Разрешено|Разрешено|\n|Сustomer Initiated Credential-on-File (CIT COF)|Инициированная покупателем оплата по сохраненным реквизитам карты (ранее была проведена операция с сохранением реквизитов CIT CC)|Рекуррентный платеж, инициированный покупателем|2|not null|N|Запрещено|Разрешено|\n|Merchant Initiated Credential-on-File, Recurring (CIT COF R)|Инициированные торговым предприятием повторяющиеся платежи **без графика** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяются для оплаты коммунальных услуг, платежей за услуги связи, кабельное/спутниковое телевидение и прочее. Сумма может быть определена заранее или становится известна непосредственно перед оплатой|Рекуррентный платеж, инициированный торговым предприятием|R|not null|N|Запрещено|Разрешено|\n|Merchant Credential-on-File, Installment (CIT COF I)|Инициированные торговым предприятием повторяющиеся платежи **по графику** (ранее была проведена операция с сохранением реквизитов CIT CC). Применяется для платежей в рассрочку по товарному кредиту, для оплаты страховки в рассрочку, для погашения кредита в соответствии с графиком платежей. График платежей может быть изменен по соглашению сторон, т.е. суммы и даты платежей должны быть известны плательщику (держателю карты) до момента проведения операции.|Рекуррентный платеж, инициированный торговым предприятием|I|not null|N|Разрешено|Запрещено|\n\n# Какими терминами пользуемся в документации?\n| **Термин** | Определение |\n| ------ | -------- |\n| **Клиент** | Физлицо, производящее перевод с использованием банковской карты на сайте Мерчанта |\n| **Мерчант** | Бизнес, принимающий и осуществляющий переводы по банковским картам на своем сайте |\n| **Т‑Касса** | Сервис, помогающий проводить выплату клиенту-физлицу |\n| **Эмитент** | Банк, выпустивший карту клиента-физлица |\n| **PCI DSS**| Международный стандарт безопасности, созданный для защиты данных банковских карт |\n| **3-D Secure** | Протокол, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт. 3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей |\n| **Терминал** | Точка приема платежей Мерчанта (в общем случае привязывается к сайту, на котором осуществляется прием платежей). Далее в этой документации описан протокол для терминала мерчанта.
    Для проведения тестов используются данные тестового терминала TinkoffBankTest (пароль аналогичен) |\n| **ККМ** | Контрольно-кассовая машина|\n|**Личный кабинет Мерчанта**|[Веб-приложение](https://business.tbank.ru/oplata/main), в котором Мерчант управляет интернет-эквайрингом - настраивает параметры терминалов, подтверждает или отменяет платежи, анализирует статистику|\n\n\n# Параметры терминала\nКаждый терминал обладает свойствами, которые влияют на те или иные аспекты приёма платежей. Эти свойства настраиваются при подключении интернет-эквайринга и могут быть изменены в Личном кабинете Мерчанта\n\nВ таблице ниже перечислены основые параметры приёма платежей для терминала\n\n|Название параметра|Формат|Описание|\n|---|---|---|\n|TerminalKey|20 символов (чувствительно к регистру)|Уникальный символьный ключ терминала. Устанавливается Т‑Кассой|\n|Success URL|250 символов(чувствительно к регистру)| URL на веб-сайте Мерчанта, куда будет переведен клиент в случае успешной оплаты
    — true - платеж завершился успешно
    — false — платеж не завершился *\n|Fail URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент в случае неуспешной оплаты *\n|Success Add Card URL| 250 символов (чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после успешной привязки карты *|\n|Fail Add Card URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет переведен клиент после неуспешной привязки карты *|\n|Notification URL| 250 символов(чувствительно к регистру)|URL на веб-сайте Мерчанта, куда будет отправлен POST запрос о статусе выполнения вызываемых методов. Только для методов **Authorize**, **FinishAuthorize**, **Confirm**, **Cancel**|\n|Валюта терминала|3 символа| Валюта, в которой будут происходить списания по данному терминалу, если иное не передано в запросе|\n|Активность терминала|Рабочий /Неактивный /Тестовый|Определяет режим работы данного терминала|\n|Password |20 символов(чувствительно к регистру)|Используется для подписи запросов/ответов. Является секретной информацией, известной только Мерчанту и Т‑Кассе. Пароль находится в [личном кабинете](https://business.tbank.ru/oplata/main) мерчанта\n|Отправлять нотификацию на FinishAuthorize|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **FinishAuthorize** (по умолчанию да)|\n|Отправлять нотификацию на Completed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **AttachCard** (по умолчанию Да)|\n|Отправлять нотификацию на Reversed|Да/Нет| Определяет, будет ли отправлена нотификация на выполнение метода **Cancel** (по умолчанию Да)|\n\n\\* *в URL можно указать необходимые параметры в виде ${<параметр>}, которые будут переданы на URL\nметодом GET*\n\n# Подпись запроса\nПеред выполнением запроса MAPI проверяет, можно ли доверять его инициатору. Для этого сервер проверяет подпись запроса. В MAPI используется механизм подписи с помощью токена. Мерчант должен добавлять токен к каждому запросу, где это требуется. \n\n> В описании входных параметров для каждого метода мы указали, нужно подписывать запрос или нет. Токен формируется на основании тех полей, которые присутствуют в запросе, поэтому токены для каждого запроса уникальные, и не совпадают никогда\n\n**Токен** в MAPI — это строка, в которой Мерчант зашифровал данные своего запроса с помощью пароля. Для создания токена Мерчант использует пароль из Личного кабинета мерчанта\n\nРассмотрим на примере процесс шифрования тела запроса для метода Init:\n```json\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"Token\": \"68711168852240a2f34b6a8b19d2cfbd296c7d2a6dff8b23eda6278985959346\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 3500,\n \"Quantity\": 2,\n \"Amount\": 7000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 550,\n \"Quantity\": 4,\n \"Amount\": 4200,\n \"Tax\": \"vat10\"\n }\n ]\n }\n}\n```\n\nЧтобы зашифровать данные запроса Мерчант должен выполнить следующие шаги:\n1. Собрать массив передаваемых данных в виде пар Ключ-Значения. В массив нужно добавить только параметры корневого объекта. Вложенные объекты и массивы не участвуют в расчете токена. В примере ниже в массив включены параметры `TerminalKey`, `Amount`, `OrderId`, `Description` и исключен объект `Receipt` и `DATA`.\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"}]\n```\n\n2. Добавить в массив пару {`Password`, Значение пароля}. Пароль можно найти в личном кабинете Мерчанта\n``` JSON\n[{\"TerminalKey\": \"MerchantTerminalKey\"},{\"Amount\": \"19200\"},{\"OrderId\": \"21090\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"Password\": \"usaf8fw8fsw21g\"}]\n```\n\n3. Отсортировать массив по алфавиту по ключу.\n```JSON\n[{\"Amount\": \"19200\"},{\"Description\": \"Подарочная карта на 1000 рублей\"},{\"OrderId\": \"21090\"},{\"Password\": \"usaf8fw8fsw21g\"},{\"TerminalKey\": \"MerchantTerminalKey\"}]\n```\n\n4. Конкатенировать только **значения** пар в одну строку.\n```JSON\n\"19200Подарочная карта на 1000 рублей21090usaf8fw8fsw21gMerchantTerminalKey\"\n```\n\n5. Применить к строке хеш-функцию SHA-256 (с поддержкой UTF-8).\n```JSON\n\"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n```\n\n6. Добавить получившийся результат в значение параметра `Token` в тело запроса и отправить запрос.\n```JSON\n{\n \"TerminalKey\": \"MerchantTerminalKey\",\n \"Amount\": 19200,\n \"OrderId\": \"21090\",\n \"Description\": \"Подарочная карта на 1000 рублей\",\n \"DATA\": {\n \"Phone\": \"+71234567890\",\n \"Email\": \"a@test.com\"\n },\n \"Receipt\": {\n \"Email\": \"a@test.ru\",\n \"Phone\": \"+79031234567\",\n \"Taxation\": \"osn\",\n \"Items\": [\n {\n \"Name\": \"Наименование товара 1\",\n \"Price\": 10000,\n \"Quantity\": 1,\n \"Amount\": 10000,\n \"Tax\": \"vat10\",\n \"Ean13\": \"303130323930303030630333435\"\n },\n {\n \"Name\": \"Наименование товара 2\",\n \"Price\": 20000,\n \"Quantity\": 2,\n \"Amount\": 40000,\n \"Tax\": \"vat20\"\n },\n {\n \"Name\": \"Наименование товара 3\",\n \"Price\": 30000,\n \"Quantity\": 3,\n \"Amount\": 90000,\n \"Tax\": \"vat10\"\n }\n ]\n },\n \"Token\": \"0024a00af7c350a3a67ca168ce06502aa72772456662e38696d48b56ee9c97d9\"\n}\n```\nПроверить корректность формирования токена можно сервисом https://tokentcs.web.app\n\n> Помимо этого информацию о корректности токена можно проверить в ЛК ИЭ в разделе \"Операции\".\nВыберите нужный заказ, затем \"Дополнительная информация о заказе\", поле \"inittokenisvalid\". Если значение в этом поле будет \"true\", это означает, что токен валидный. Если \"false\", то токен передан некорректный.\n" }, "servers": [ { @@ -29,7 +29,7 @@ "tags": [ { "name": "Сценарии оплаты по карте", - "description": "## Правила работы\n\nПрием платежей осуществляется вызовом методов с передачей параметров методом POST в формате JSON. Все методы и передаваемые параметры являются чувствительными к регистру. \nДля нашего ИЭ оплата проходит только в рублях.\n> При необходимости оплаты в валюте, мерчант самостоятельно на своей стороне реализовывает логику конвертации суммы в запросе\n \nДля POST-запроса в заголовке должен присутствовать `Content Type: application/json`.\nURL: https://securepay.tinkoff.ru/v2/\n \n\n## Сценарии платежа\nОсновная сущность в интернет-эквайринге Т‑Кассы — это **платеж**. В зависимости от настроек терминала платеж может идти по разным сценариям\n\nЕсли Мерчант хочет получить деньги сразу после завершения оплаты, тогда терминал должен быть настроен на приём **одностадийных платежей**. Другой способ — **двухстадийный платеж**. После оплаты деньги заблокируются на карте клиента, а Мерчант затем подтверждает платёж в удобный ему момент. \n\n>Настроить способ приема на терминале можно в Личном кабинете Мерчанта, либо указать нужный тип при вызове метода `Init` в параметре `PayType`\n\n### Стандартный платеж для мерчантов с PCI DSS\n#### Инициализация платежа\nДля того, чтобы создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\nВ ответ MAPI создаст новый платеж в статусе **NEW** и вернёт обратно его идентификатор в параметре `PaymentId`\n\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\nЕсли в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка — закодированный в формате `base64` JSON-объект с параметрами:\n|Название параметра|Тип данных|Описание|\n|---|---|---|\n|threeDSMethodNotificationURL|string|Обратный адрес, на который будет >отправлен запрос после прохождения `3DS Method`|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n\nБраузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n\nПример запроса на `ThreeDSMethodURL`:\n\n``` html\n\n
    \n\n
    \n\n```\n\nПример декодированного значения `threeDSMethodData`:\n```json\n{\n\n\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n\n}\n```\n\n \n\n### Стандартный платеж\n\nЗа проведение платежа отвечает метод — `FinishAuthorize`. Через него Мерчант передает в MAPI карточные данные клиента, таким образом продолжая обработку платежа\n\n \n\n>Если платеж **одностадийный**, то после вызова метода деньги будут списаны с карты клиента\n>\n>Если платеж **двухстадийный**, то после вызова метода деньги будут заблокированы на карте клиента. Мерчант должен дополнительно подтвердить списание, вызвав метод `Confirm`\n\n \n\nВ ответ MAPI вернет один из возможных статусов:\n\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|AUTH_FAIL|Неуспешная авторизация|Провести платеж заново|\n|REJECTED|Платеж отклонен|Провести платеж заново|\n|CONFIRMED|Успешный одностадийный платеж|-|\n|AUTHORIZED|Успешный двухстадийный платеж|Подтвердить платеж|\n|3DS_CHECKING|Требуется подтверждение платежа по 3D-Secure|
    • Отменить платеж (действие доступно для клиента)
    • Пройти подтверждение (действие доступно для клиента)
    |\n\n\n#### Без 3DS-подтверждения\n\nЕсли по платежу не требуется проходить подтверждение 3DS, то MAPI в ответе `FinishAuthorize` вернет один из трех конечных статусов платежа:\n\n- **CONFIRMED** (при одностадийном платеже),\n\n- **AUTHORIZED** (при двухстадийном платеже),\n\n- **REJECTED** (при отказе в проведении платежа).\n\n \n\n#### C 3DS-подтверждением\n\nЕсли в ответе метода `FinishAuthorize` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен сформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `FinishAuthorize` в параметре `ACSUrl`. Вместе с этим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n**Важно:** Проведение тестовых платежей возможно только на тестовом окружении\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `FinishAuthorize`|\n|PaReq| Запрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `FinishAuthorize`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента. Тип устройства передается в запросе `FinishAuthorize` в параметре `deviceChannel`. Возможны два варианта — браузер (BRW, код `02`) и приложение (APP, код `01`).\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n \nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `FinishAuthorize`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n### Стандартный платеж для Мерчантов без PCI DSS\n#### Инициализация платежа\nДля того, чтоды создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа. При успешном прохождении запроса в ответе на метод `Init` будет прислан параметр `PaymentURL`, на который необходимо переадресовать клиента. При переходе на `PaymentURL` клиенту откроется платежная форма Т‑Кассы, где необходимо ввести реквизиты карты, а дальше — этап прохождения 3DS.\n\n> Методы Authorize и FinishAuthorize вызываются системами Т‑Кассы при переадресации клиента на PaymentURL (возвращается в ответе на метод Init). Актуально для Мерчантов, использующих платежную форму Банка\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\n#### Метод Authorize\nВызов происходит автоматически при переадресации клиента на страницу PaymentURL, указанную в ответе на Init. Статус платежа выставляется в FORM_SHOWED\n\n#### Метод FinishAuthorize\nПодтверждает инициированный платеж передачей карточных данных и осуществляет списание денежных средств с карты клиента\n\n#### Осуществление платежа на платежной форме Т‑Кассы\nВызывается формой оплаты, доступной по адресу PaymentURL, при заполнении клиентом карточных данных и нажатии кнопки «Оплатить»\n\nСтатус перевода:\n* при успешном сценарии: CONFIRMED,\n* при неуспешном: REJECTED.\n\nПереадресация клиента:\n* в случае успешного перевода на Success URL;\n* в случае неуспешного перевода на Fail URL.\n\n\n#### Завершение платежа\nЕсли платёж завершился успешно, то клиент будет перенаправлен на страницу `Success URL` из настроек терминала\n\n### Двухстадийный платеж\n\nДвухстадийный платеж — платеж, состоящий из двух этапов. На первом этапе проверяется наличие средств у клиента и осуществляется их блокировка (холдирование средств). На втором этапе Мерчант должен либо подтвердить списание средств, либо отменить холдирование средств. \n\nКогда клиент оплачивает заказ, деньги за покупку замораживаются (холдируются) на его счете до семи дней.\nЕсли клиент за это время отказался от заказа, он автоматически получает деньги обратно, а компания избегает комиссии за эквайринг\n\nЕсли клиент не стал отказываться от товара и вы подтвердили продажу в течение семи дней, деньги на его счете размораживаются и поступают на счет компании. В этом случае Т‑Касса списывает комиссию\n\nЕсли Мерчант не подтвердит платеж вовремя, может столкнуться с негативом от клиента\n\nНапример, в случае, когда клиент может не вспомнить, за что списались деньги, и может обратиться в свой банк для возврата средств\n\n
    Про сроки холдирования\n
    \n\nХолдирование денежных средств на карте покупателя зависит от его банка эмитента и не всегда равно семи дням. Этот срок может быть другим. Например, покупатель оплатил товар, его банк заморозил средства на карте на 3 дня, они прошли, деньги разморозились и стали доступны на счете. Спустя день вы подтверждаете платеж, списывая сумму покупки. Фактически оплата прошла один раз.\n\n
    \n\n**Техническая реализация двухстадийных платежей:** \n\nЕсли терминал настроен на прием двухстадийный платежей, то после вызова метода `FinishAuthorize` деньги блокируются на карте клиента, и платеж переходит в статус **AUTHORIZED**\n\nКогда Мерчант захочет списать деньги, он должен вызвать метод `Confirm` и передать в запросе `PaymentId`. После успешного списания платеж перейдет в статус **CONFIRMED**. Если Мерчант хочет отменить заказ (например, данный товар закончился), он должен вызвать метод `Cancel`\n\n### Рекуррентные платежи\nМерчант может сохранять платежные данные клиента и использовать их для повторных списаний. Такие платежи называются **рекуррентными**. В этом случае клиент должен совершить хотя бы один платеж, который был настроен как рекуррентный. Для этого Мерчант должен передать параметр `Recurrent` в методе **Init**.\n\nПосле успешной оплаты MAPI отправит Мерчанту уведомление об изменении статуса платежа на **AUTHORIZED** или **CONFIRMED** и передаст параметр `RebillId`. Следующие платежи этого клиента будут рекуррентными, если Мерчант вызовет метод **Init**, а затем без переадресации на `PaymentURL` вызовет метод **Charge** и передаст параметр `RebillId`.\n \n>Метод `Charge` работает как по одностадийной, так и по двухстадийной схеме оплаты. Чтобы перейти на двухстадийную схему, нужно переключить терминал в [Личном кабинете](https://business.tbank.ru/oplata/main), а также написать обращение на с просьбой переключить схему рекуррентов\n\n## Возврат и отмена платежа\nМерчант может отменить успешный платеж. В таком случае, деньги вернутся на ту карту, которую клиент указывал при совершении платежа\n\nУспешный платеж — платеж, который находится в статусе **AUTHORIZED** или **CONFIRMED**. Если Мерчант отменяет платеж в статусе **AUTHORIZED**, то происходит разморозка заблокированной суммы на карте клиента. Если платеж в статусе **CONFIRMED**, то деньги списываются со счета Мерчанта и возвращаются на карту клиента.\n \n> Возврат может быть частичный или полный. Частичный возврат — отмена не на всю сумму платежа. Полный возврат — отмена на полную сумму платежа.\n\nЧтобы отменить платеж, Мерчант должен вызвать метод [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) и передать в запросе идентификатор платежа `PaymentId`. По умолчанию, MAPI сделает полный возврат. Если требуется частичная отмена, то во входящем запросе Мерчант должен передать сумму, которая вернется клиенту, в параметре `Amount`. \n\n
    Про частичный возврат при подключенной Онлайн-кассе\n
    \n\n1. Если при работе используется онлайн-касса, то возврат можно делать только по позициям в чеке. Если возврат нужно сделать на иную сумму, то сначала надо отключить онлайн-кассу и только потом провести возврат через API методом [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel), передавая в нем нужную сумму в параметре `Amount`\n\n2. Если у клиента подключена онлайн-касса, то в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать:\n* в `Amount` — сумму к частичному возврату\\анхолду;\n* в `Receipt` — передать параметры чека.\n\nВ `Items` — параметр `Amount` для частичного возврата\\анхолда должен рассчитываться следующим образом: Price * Quantity = Amount\n\nНапример, товар стоит 500.00 рублей и нужно вернуть 50.00 рублей, то в [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать Amount = 5000:\n\n```JSON\n{\n \"Name\": \"Item12\",\n \"Price\": 50000,\n \"Quantity\": 0.1,\n \"Amount\": 5000,\n \"Tax\": \"none\",\n \"PaymentObject\": \"service\"\n}\n```\nЕсли в чеке несколько позиций, то по каждой позиции в чеке нужно сделать аналогично\n\nБез активной онлайн-кассы достаточно передать нужную сумму в `Amount` в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel). В случае частичного анхолда остаток также остается в резерве и его нужно подтвердить\n\n## Получение данных о платеже\nМерчант может получить информацию об основных параметрах платежа в любой момент\n\nЕсли требуется получить данные по конкретному платежу, то Мерчант должен вызвать метод [`GetState`](#tag/Standartnyj-platyozh/paths/~1GetState/post) и передать в запросе `PaymentId`\n\nЕсли по одному заказу было несколько, то получить историю платежей и их текущий статус можно с помощью метода [`CheckOrder`](#tag/Standartnyj-platyozh/paths/~1CheckOrder/post). Мерчант должен передать в запросе `OrderId`\n\n*`OrderId` не является уникальным параметром. Рекомендуется сверять дополнительные данные заказа — `PaymentId` и `Amount`.*\n\n## Статусная модель платежа\nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL` и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**3DS_CHECKING**|Платеж проходит проверку 3D-Secure|\n|**3DS_CHECKED**|Платеж успешно прошел проверку 3D-Secure|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REVERSING**|Мерчант запросил отмену авторизованного, но еще не подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REVERSED**|Частичный возврат по авторизованному платежу завершился успешно|\n|**REVERSED**|Полный возврат по авторизованному платежу завершился успешно|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**СANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схеме ниже — полный жизненный цикл платежа\n[![scheme](https://acdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)](https://acdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)" + "description": "## Правила работы\n\nПрием платежей осуществляется вызовом методов с передачей параметров методом POST в формате JSON. Все методы и передаваемые параметры являются чувствительными к регистру. \nДля нашего ИЭ оплата проходит только в рублях.\n> При необходимости оплаты в валюте, мерчант самостоятельно на своей стороне реализовывает логику конвертации суммы в запросе\n \nДля POST-запроса в заголовке должен присутствовать `Content Type: application/json`.\nURL: https://securepay.tinkoff.ru/v2/\n \n\n## Сценарии платежа\nОсновная сущность в интернет-эквайринге Т‑Кассы — это **платеж**. В зависимости от настроек терминала платеж может идти по разным сценариям\n\nЕсли Мерчант хочет получить деньги сразу после завершения оплаты, тогда терминал должен быть настроен на приём **одностадийных платежей**. Другой способ — **двухстадийный платеж**. После оплаты деньги заблокируются на карте клиента, а Мерчант затем подтверждает платёж в удобный ему момент. \n\n>Настроить способ приема на терминале можно в Личном кабинете Мерчанта, либо указать нужный тип при вызове метода `Init` в параметре `PayType`\n\n### Стандартный платеж для мерчантов с PCI DSS\n#### Инициализация платежа\nДля того, чтобы создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\nВ ответ MAPI создаст новый платеж в статусе **NEW** и вернёт обратно его идентификатор в параметре `PaymentId`\n\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\nЕсли в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка — закодированный в формате `base64` JSON-объект с параметрами:\n|Название параметра|Тип данных|Описание|\n|---|---|---|\n|threeDSMethodNotificationURL|string|Обратный адрес, на который будет >отправлен запрос после прохождения `3DS Method`|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n\nБраузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n\nПример запроса на `ThreeDSMethodURL`:\n\n``` html\n\n
    \n\n
    \n\n```\n\nПример декодированного значения `threeDSMethodData`:\n```json\n{\n\n\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n\n}\n```\n\n \n\n### Стандартный платеж\n\nЗа проведение платежа отвечает метод — `FinishAuthorize`. Через него Мерчант передает в MAPI карточные данные клиента, таким образом продолжая обработку платежа\n\n \n\n>Если платеж **одностадийный**, то после вызова метода деньги будут списаны с карты клиента\n>\n>Если платеж **двухстадийный**, то после вызова метода деньги будут заблокированы на карте клиента. Мерчант должен дополнительно подтвердить списание, вызвав метод `Confirm`\n\n \n\nВ ответ MAPI вернет один из возможных статусов:\n\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|AUTH_FAIL|Неуспешная авторизация|Провести платеж заново|\n|REJECTED|Платеж отклонен|Провести платеж заново|\n|CONFIRMED|Успешный одностадийный платеж|-|\n|AUTHORIZED|Успешный двухстадийный платеж|Подтвердить платеж|\n|3DS_CHECKING|Требуется подтверждение платежа по 3D-Secure|
    • Отменить платеж (действие доступно для клиента)
    • Пройти подтверждение (действие доступно для клиента)
    |\n\n\n#### Без 3DS-подтверждения\n\nЕсли по платежу не требуется проходить подтверждение 3DS, то MAPI в ответе `FinishAuthorize` вернет один из трех конечных статусов платежа:\n\n- **CONFIRMED** (при одностадийном платеже),\n\n- **AUTHORIZED** (при двухстадийном платеже),\n\n- **REJECTED** (при отказе в проведении платежа).\n\n \n\n#### C 3DS-подтверждением\n\nЕсли в ответе метода `FinishAuthorize` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен сформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `FinishAuthorize` в параметре `ACSUrl`. Вместе с этим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n**Важно:** Проведение тестовых платежей возможно только на тестовом окружении\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `FinishAuthorize`|\n|PaReq| Запрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `FinishAuthorize`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента. Тип устройства передается в запросе `FinishAuthorize` в параметре `deviceChannel`. Возможны два варианта — браузер (BRW, код `02`) и приложение (APP, код `01`).\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n \nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `FinishAuthorize`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `FinishAuthorize`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `FinishAuthorize`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n### Стандартный платеж для Мерчантов без PCI DSS\n#### Инициализация платежа\nДля того, чтоды создать платеж, Мерчант должен инициировать платеж методом `Init`, в котором передается сумма платежа и номер заказа. При успешном прохождении запроса в ответе на метод `Init` будет прислан параметр `PaymentURL`, на который необходимо переадресовать клиента. При переходе на `PaymentURL` клиенту откроется платежная форма Т‑Кассы, где необходимо ввести реквизиты карты, а дальше — этап прохождения 3DS.\n\n> Методы Authorize и FinishAuthorize вызываются системами Т‑Кассы при переадресации клиента на PaymentURL (возвращается в ответе на метод Init). Актуально для Мерчантов, использующих платежную форму Банка\n\nПри создании платежа (вызов метода /Init), в объекте DATA в атрибуте OperationInitiatorType необходимо передавать признак инициатора операции. См. метод [Init](#tag/Standartnyj-platyozh/paths/~1Init/post)\n\n#### Метод Authorize\nВызов происходит автоматически при переадресации клиента на страницу PaymentURL, указанную в ответе на Init. Статус платежа выставляется в FORM_SHOWED\n\n#### Метод FinishAuthorize\nПодтверждает инициированный платеж передачей карточных данных и осуществляет списание денежных средств с карты клиента\n\n#### Осуществление платежа на платежной форме Т‑Кассы\nВызывается формой оплаты, доступной по адресу PaymentURL, при заполнении клиентом карточных данных и нажатии кнопки «Оплатить»\n\nСтатус перевода:\n* при успешном сценарии: CONFIRMED,\n* при неуспешном: REJECTED.\n\nПереадресация клиента:\n* в случае успешного перевода на Success URL;\n* в случае неуспешного перевода на Fail URL.\n\n\n#### Завершение платежа\nЕсли платёж завершился успешно, то клиент будет перенаправлен на страницу `Success URL` из настроек терминала\n\n### Двухстадийный платеж\n\nДвухстадийный платеж — платеж, состоящий из двух этапов. На первом этапе проверяется наличие средств у клиента и осуществляется их блокировка (холдирование средств). На втором этапе Мерчант должен либо подтвердить списание средств, либо отменить холдирование средств. \n\nКогда клиент оплачивает заказ, деньги за покупку замораживаются (холдируются) на его счете до семи дней.\nЕсли клиент за это время отказался от заказа, он автоматически получает деньги обратно, а компания избегает комиссии за эквайринг\n\nЕсли клиент не стал отказываться от товара и вы подтвердили продажу в течение семи дней, деньги на его счете размораживаются и поступают на счет компании. В этом случае Т‑Касса списывает комиссию\n\nЕсли Мерчант не подтвердит платеж вовремя, может столкнуться с негативом от клиента\n\nНапример, в случае, когда клиент может не вспомнить, за что списались деньги, и может обратиться в свой банк для возврата средств\n\n
    Про сроки холдирования\n
    \n\nХолдирование денежных средств на карте покупателя зависит от его банка эмитента и не всегда равно семи дням. Этот срок может быть другим. Например, покупатель оплатил товар, его банк заморозил средства на карте на 3 дня, они прошли, деньги разморозились и стали доступны на счете. Спустя день вы подтверждаете платеж, списывая сумму покупки. Фактически оплата прошла один раз.\n\n
    \n\n**Техническая реализация двухстадийных платежей:** \n\nЕсли терминал настроен на прием двухстадийный платежей, то после вызова метода `FinishAuthorize` деньги блокируются на карте клиента, и платеж переходит в статус **AUTHORIZED**\n\nКогда Мерчант захочет списать деньги, он должен вызвать метод `Confirm` и передать в запросе `PaymentId`. После успешного списания платеж перейдет в статус **CONFIRMED**. Если Мерчант хочет отменить заказ (например, данный товар закончился), он должен вызвать метод `Cancel`\n\n### Рекуррентные платежи\nМерчант может сохранять платежные данные клиента и использовать их для повторных списаний. Такие платежи называются **рекуррентными**. В этом случае клиент должен совершить хотя бы один платеж, который был настроен как рекуррентный. Для этого Мерчант должен передать параметр `Recurrent` в методе **Init**.\n\nПосле успешной оплаты MAPI отправит Мерчанту уведомление об изменении статуса платежа на **AUTHORIZED** или **CONFIRMED** и передаст параметр `RebillId`. Следующие платежи этого клиента будут рекуррентными, если Мерчант вызовет метод **Init**, а затем без переадресации на `PaymentURL` вызовет метод **Charge** и передаст параметр `RebillId`.\n \n>Метод `Charge` работает как по одностадийной, так и по двухстадийной схеме оплаты. Чтобы перейти на двухстадийную схему, нужно переключить терминал в [Личном кабинете](https://business.tbank.ru/oplata/main), а также написать обращение на с просьбой переключить схему рекуррентов\n\n## Возврат и отмена платежа\nМерчант может отменить успешный платеж. В таком случае, деньги вернутся на ту карту, которую клиент указывал при совершении платежа\n\nУспешный платеж — платеж, который находится в статусе **AUTHORIZED** или **CONFIRMED**. Если Мерчант отменяет платеж в статусе **AUTHORIZED**, то происходит разморозка заблокированной суммы на карте клиента. Если платеж в статусе **CONFIRMED**, то деньги списываются со счета Мерчанта и возвращаются на карту клиента.\n \n> Возврат может быть частичный или полный. Частичный возврат — отмена не на всю сумму платежа. Полный возврат — отмена на полную сумму платежа.\n\nЧтобы отменить платеж, Мерчант должен вызвать метод [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) и передать в запросе идентификатор платежа `PaymentId`. По умолчанию, MAPI сделает полный возврат. Если требуется частичная отмена, то во входящем запросе Мерчант должен передать сумму, которая вернется клиенту, в параметре `Amount`. \n\n
    Про частичный возврат при подключенной Онлайн-кассе\n
    \n\n1. Если при работе используется онлайн-касса, то возврат можно делать только по позициям в чеке. Если возврат нужно сделать на иную сумму, то сначала надо отключить онлайн-кассу и только потом провести возврат через API методом [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel), передавая в нем нужную сумму в параметре `Amount`\n\n2. Если у клиента подключена онлайн-касса, то в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать:\n* в `Amount` — сумму к частичному возврату\\анхолду;\n* в `Receipt` — передать параметры чека.\n\nВ `Items` — параметр `Amount` для частичного возврата\\анхолда должен рассчитываться следующим образом: Price * Quantity = Amount\n\nНапример, товар стоит 500.00 рублей и нужно вернуть 50.00 рублей, то в [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel) нужно передать Amount = 5000:\n\n```JSON\n{\n \"Name\": \"Item12\",\n \"Price\": 50000,\n \"Quantity\": 0.1,\n \"Amount\": 5000,\n \"Tax\": \"none\",\n \"PaymentObject\": \"service\"\n}\n```\nЕсли в чеке несколько позиций, то по каждой позиции в чеке нужно сделать аналогично\n\nБез активной онлайн-кассы достаточно передать нужную сумму в `Amount` в методе [Cancel](https://www.tbank.ru/kassa/dev/payments/#tag/Otmena-platezha/operation/Cancel). В случае частичного анхолда остаток также остается в резерве и его нужно подтвердить\n\n## Получение данных о платеже\nМерчант может получить информацию об основных параметрах платежа в любой момент\n\nЕсли требуется получить данные по конкретному платежу, то Мерчант должен вызвать метод [`GetState`](#tag/Standartnyj-platyozh/paths/~1GetState/post) и передать в запросе `PaymentId`\n\nЕсли по одному заказу было несколько, то получить историю платежей и их текущий статус можно с помощью метода [`CheckOrder`](#tag/Standartnyj-platyozh/paths/~1CheckOrder/post). Мерчант должен передать в запросе `OrderId`\n\n*`OrderId` не является уникальным параметром. Рекомендуется сверять дополнительные данные заказа — `PaymentId` и `Amount`.*\n\n## Статусная модель платежа\nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL` и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**3DS_CHECKING**|Платеж проходит проверку 3D-Secure|\n|**3DS_CHECKED**|Платеж успешно прошел проверку 3D-Secure|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REVERSING**|Мерчант запросил отмену авторизованного, но еще не подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REVERSED**|Частичный возврат по авторизованному платежу завершился успешно|\n|**REVERSED**|Полный возврат по авторизованному платежу завершился успешно|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**СANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схеме ниже — полный жизненный цикл платежа\n[![scheme](https://cdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)](https://cdn.t-static.ru/static/documents/payment%20schema%20EACQ.jpg)" }, { "name": "Методы работы с клиентами", @@ -37,15 +37,15 @@ }, { "name": "Сценарии привязки карты", - "description": "## Общая информация\nМерчант может сохранить платежные данные клиента, чтобы при последующих оплатах ему не приходилось заполнять платежную форму. Для этого клиент привязывается к терминалу, через который будут проходить платежи. После, для этого клиенту можно сохранять карты. \n\nМерчант может выбрать способ привязки клиента — с проверкой 3D-Secure или без\n\nЕсли выбрана опция с проверкой, то клиент должен будет подтвердить операцию уже на этом этапе. Все дальнейшие платежи будут проходить по схеме рекуррентного платежа, то есть подтверждать каждое списание не нужно\n\nЕсли Мерчант выбрал опцию привязки без проверки 3D-Secure, то клиент и его карты будут сохранены без подтверждения. Однако, оно подтребуется при первом платеже по привязанной карте\n\nЗа способ привязки отвечает параметр `CheckType` в запросе метода `AddCard`. Если Мерчант не передаст этот параметр, то MAPI, по умолчанию, будет считать, что привязка прошла без подтверждения клиента\n\n> Для корректной работы методов Т‑Касса должна разрешить Мерчанту привязывать карты и клиентов к терминалу. В результате привязки карты к параметру `CustomerKey` будет привязана `CardId`\n\n## Сценарии работы с картами и клиентами\n### Добавление, получение и удаление клиента\nДля сохранения идентификатора клиента `CustomerKey` Мерчант должен вызвать метод `AddCustomer` и передать в запросе параметр `CustomerKey`\n\nДля удаления клиента из списка привязанных к терминалу Мерчант должен вызвать метод `RemoveCustomer`передать в запросе параметр `CustomerKey`\n\nДля получения сохраненных данных клиента Мерчант должен вызвать метод `GetCustomer` и передать в запросе параметр `CustomerKey`\n\n### Добавление, получение и удаление карты\nдля Мерчантов с PCI DSS\n\n#### Инициализация привязки\nПосле сохранения клиента в списке привязанных к терминалу Мерчант может добавить карту. Для этого он вызывает метод `AddCard` и передает в запросе параметр `CustomerKey`. В ответ MAPI пришлет идентификатор сессии привязки карты `PaymentId`.\n\n#### Проверка версии 3DS\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\n>Если в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка - закодированный в формате `base64` JSON-объект с параметрами:\n>|Название параметра|Тип данных|Описание|\n>|---|---|---|\n>|threeDSMethodNotificationURL|string|Обратный адрес, на который будет отправлен запрос после прохождения `3DS Method`|\n>|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n>\n>Браузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n>\n>Пример запроса на `ThreeDSMethodURL`:\n>\n>``` js\n>\n>
    \n> value=\"eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjU2ZTcxMmE1LTE5MGEtNDU4OC05MWJjLWUwODYyNmU3N2M0NCIsInRocm\n>VlRFNNZXRob2ROb3RpZmljYXRpb25VUkwiOiJodHRwczovL3Jlc3QtYXBpLXRlc3QudGlua29mZi5ydS92Mi9Db21wbGV0ZTNEU0\n>1ldGhvZHYyIn0\">\n>
    \n>\n>```\n>\n>Пример декодированного значения `threeDSMethodData`:\n>```json\n>{\n>\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n>\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n>}\n>```\n\n#### Завершение привязки\nДля завершения привязки карты Мерчант вызывает метод `AttachCard` и передает зашифрованные карточные данные, а также набор параметров для прохождения проверки 3D-Secure\n\nВ ответ MAPI вернет один из возможных статусов:\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|REJECTED|Привязка отклонена|Провести привязку заново|\n|COMPLETED|Успешная привязка карты|-|\n|3DS_CHECKING|Требуется подтверждение привязки по 3D-Secure|
    • Отменить привязку
    • Пройти подтверждение
    \n\nЕсли в ответе метода `AttachCard` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен\nсформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `AttachCard` в параметре `ACSUrl`. Вместе с\nэтим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `AttachCard`|\n|PaReq|\tЗапрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `AttachCard`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n\nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `AttachCard`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n#### Завершение привязки\nЕсли привязка завершилась успешно, то клиент будет перенаправлен на страницу `Success Add Card URL` из настроек терминала\n\n## Статусная модель привязки карты\nВ процессе обработки операция привязки меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n| Статус | Описание |\n| --- | --- |\n| NEW | Новая сессия |\n| FORM_SHOWED | Показ формы привязки карты |\n| 3DS_CHECKING | Отправка клиента на проверку 3DS |\n| 3DS_CHECKED | Клиент успешно прошел проверку 3DS |\n| AUTHORIZING | Отправка платежа на 0 руб |\n| AUTHORIZED | Платеж на 0 руб прошел успешно |\n| COMPLETED | Привязка успешно завершена |\n| REJECTED | Привязка отклонена |\n\n\nНа схеме ниже — полный жизненный цикл привязки карты\n\n[![scheme](https://acdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)](https://acdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)" + "description": "## Общая информация\nМерчант может сохранить платежные данные клиента, чтобы при последующих оплатах ему не приходилось заполнять платежную форму. Для этого клиент привязывается к терминалу, через который будут проходить платежи. После, для этого клиенту можно сохранять карты. \n\nМерчант может выбрать способ привязки клиента — с проверкой 3D-Secure или без\n\nЕсли выбрана опция с проверкой, то клиент должен будет подтвердить операцию уже на этом этапе. Все дальнейшие платежи будут проходить по схеме рекуррентного платежа, то есть подтверждать каждое списание не нужно\n\nЕсли Мерчант выбрал опцию привязки без проверки 3D-Secure, то клиент и его карты будут сохранены без подтверждения. Однако, оно подтребуется при первом платеже по привязанной карте\n\nЗа способ привязки отвечает параметр `CheckType` в запросе метода `AddCard`. Если Мерчант не передаст этот параметр, то MAPI, по умолчанию, будет считать, что привязка прошла без подтверждения клиента\n\n> Для корректной работы методов Т‑Касса должна разрешить Мерчанту привязывать карты и клиентов к терминалу. В результате привязки карты к параметру `CustomerKey` будет привязана `CardId`\n\n## Сценарии работы с картами и клиентами\n### Добавление, получение и удаление клиента\nДля сохранения идентификатора клиента `CustomerKey` Мерчант должен вызвать метод `AddCustomer` и передать в запросе параметр `CustomerKey`\n\nДля удаления клиента из списка привязанных к терминалу Мерчант должен вызвать метод `RemoveCustomer`передать в запросе параметр `CustomerKey`\n\nДля получения сохраненных данных клиента Мерчант должен вызвать метод `GetCustomer` и передать в запросе параметр `CustomerKey`\n\n### Добавление, получение и удаление карты\nдля Мерчантов с PCI DSS\n\n#### Инициализация привязки\nПосле сохранения клиента в списке привязанных к терминалу Мерчант может добавить карту. Для этого он вызывает метод `AddCard` и передает в запросе параметр `CustomerKey`. В ответ MAPI пришлет идентификатор сессии привязки карты `PaymentId`.\n\n#### Проверка версии 3DS\nНа следующем этапе Мерчант вызвает метод `Check3DSVersion`, в котором передает зашифрованные карточные данные клиента и `PaymentId`. Это нужно для проверки версии протокола 3D-Secure по карте. Она может быть либо версии 1.0, либо 2.0.\n\n>Если в ответе метода `Check3DSVersion` есть параметр `ThreeDSMethodURL`, то браузер клиента должен вызывать ресурс, адрес которого пришел в параметре >`ThreeDSMethodURL`. В запросе нужно передать строковый параметр `threeDSMethodData`. Эта строка - закодированный в формате `base64` JSON-объект с параметрами:\n>|Название параметра|Тип данных|Описание|\n>|---|---|---|\n>|threeDSMethodNotificationURL|string|Обратный адрес, на который будет отправлен запрос после прохождения `3DS Method`|\n>|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `Check3DSVersion`|\n>\n>Браузер должен вызвать `3DS Method` в скрытом iframe и передать данные в формате `x-www-form-urlencoded`\n>\n>Пример запроса на `ThreeDSMethodURL`:\n>\n>``` js\n>\n>
    \n> value=\"eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjU2ZTcxMmE1LTE5MGEtNDU4OC05MWJjLWUwODYyNmU3N2M0NCIsInRocm\n>VlRFNNZXRob2ROb3RpZmljYXRpb25VUkwiOiJodHRwczovL3Jlc3QtYXBpLXRlc3QudGlua29mZi5ydS92Mi9Db21wbGV0ZTNEU0\n>1ldGhvZHYyIn0\">\n>
    \n>\n>```\n>\n>Пример декодированного значения `threeDSMethodData`:\n>```json\n>{\n>\"threeDSServerTransID\":\"56e712a5-190a-4588-91bc-e08626e77c44\",\n>\"threeDSMethodNotificationURL\":\"https://rest-api-test.tinkoff.ru/v2/>Complete3DSMethodv2\"\n>}\n>```\n\n#### Завершение привязки\nДля завершения привязки карты Мерчант вызывает метод `AttachCard` и передает зашифрованные карточные данные, а также набор параметров для прохождения проверки 3D-Secure\n\nВ ответ MAPI вернет один из возможных статусов:\n|Статус|Описание|Доступные действия|\n|---|---|---|\n|REJECTED|Привязка отклонена|Провести привязку заново|\n|COMPLETED|Успешная привязка карты|-|\n|3DS_CHECKING|Требуется подтверждение привязки по 3D-Secure|
    • Отменить привязку
    • Пройти подтверждение
    \n\nЕсли в ответе метода `AttachCard` вернулся статус платежа **3DS_CHECKING**, то это означает, что требуется пройти проверку 3D-Secure. Для этого Мерчант должен\nсформировать запрос в сервис аутентификации банка, выпустившего карту. Адрес сервиса возвращается в ответе `AttachCard` в параметре `ACSUrl`. Вместе с\nэтим требуется перенаправить клиента на эту же страницу `ACSUrl` для прохождения 3DS.\n\nВ заголовке запроса требуется передать параметр `Content-Type` со значением ` application/x-www-form-urlencoded`. Набор параметров в теле запросе зависит от версии протокола 3DS по карте\n\n##### 3DS 1.0\nЕсли версия **3DS 1.0**, то в запросе передаются параметры:\n\n|Название параметра|Описание|\n|---|---|\n|MD| Информация для идентификации платежной сессии на стороне торговой точки. Придет в ответе метода `AttachCard`|\n|PaReq|\tЗапрос на аутентификацию плательщика, который содержит разные детали транзакции. Придет в ответе метода `AttachCard`|\n|TermURL|Адрес перенаправления после аутентификации 3DS. Должен содержать ссылку на обработчик на стороне Мерчанта, принимающий результаты прохождения 3-D Secure|\n\n##### 3DS 2.0\nЕсли версия **3DS 2.0**, то в запросе передаются параметры, в зависимости от типа устройства клиента\n\n**Параметры для браузера:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JSON с параметрами `threeDSServerTransID`, `acsTransID`,`challengeWindowSize`, `messageType`, `messageVersion` закодированный в формат `base64`|\n\nСтрока `creq` для браузера формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|challengeWindowSize|string|Размер экрана, на котором открыта страница ACS.Допустимые значения:
  • **01** = 250 x 400
  • **02** = 390 x 400
  • **03** = 500 x 600
  • **04** = 600 x 400
  • **05** = Full screen
  • |\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n\n**Параметры для приложения:**\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|creq|string|JWE object с параметрами `threeDSServerTransID`, `acsTransID`, `messageType`, `messageVersion`, `sdkTransID`, `sdkCounterStoA` закодированный в формат `PS256`|\n\nСтрока `creq` для приложения формируется из следующих параметров:\n|Название параметра|Тип данных| Описание|\n|---|---|---|\n|threeDSServerTransID|string|Идентификатор транзакции из ответа метода `AttachCard`|\n|acsTransID|string|Идентификатор транзакции, присвоенный ACS, полученный в ответе на `AttachCard`|\n|messageType|string|Передается фиксированное значение «CReq»|\n|messageVersion|string|Версия 3DS, полученная из ответа метода `Check3dsVersion`|\n|sdkTransID|string|Уникальный идентификатор транзакции, назначенный 3DS SDK для идентификации одной транзакции, полученный в ответе на `AttachCard`|\n|sdkCounterStoA|string|Внутренний счетчик 3DS SDK внутри ACS. Поддерживаемые значения:
    000-255
    |\n\n#### Подтверждение прохождения 3DS\nПосле того, как сервис аутентификации банка, выпустившего карту, прислал результат прохождения 3D-Secure, Мерчант должен передать эту информацию в MAPI. В зависимости от версии протокола 3DS для этого нужно вызвать один из методов:\n- Для 3DS 1.0 — `Submit3DSAuthorization`,\n- Для 3DS 2.0 — `Submit3DSAuthorizationV2`.\n\n#### Завершение привязки\nЕсли привязка завершилась успешно, то клиент будет перенаправлен на страницу `Success Add Card URL` из настроек терминала\n\n## Статусная модель привязки карты\nВ процессе обработки операция привязки меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n\n| Статус | Описание |\n| --- | --- |\n| NEW | Новая сессия |\n| FORM_SHOWED | Показ формы привязки карты |\n| 3DS_CHECKING | Отправка клиента на проверку 3DS |\n| 3DS_CHECKED | Клиент успешно прошел проверку 3DS |\n| AUTHORIZING | Отправка платежа на 0 руб |\n| AUTHORIZED | Платеж на 0 руб прошел успешно |\n| COMPLETED | Привязка успешно завершена |\n| REJECTED | Привязка отклонена |\n\n\nНа схеме ниже — полный жизненный цикл привязки карты\n\n[![scheme](https://cdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)](https://cdn.t-static.ru/static/documents/Status%20scheme%20of%20linking%20cards.png)" }, { "name": "Оплата через СБП", - "description": "## Общая информация для оплат по QR\n1. Банк по умолчанию покупатель выбирает на своём устройстве, через API это настроить невозможно\n2. Если оплата СБП отклоняется на стороне эмитента, эквайер на своей стороне не может повлиять на это \n3. На платежной форме банка при выборе способа оплаты СБП, отображается QR-код с надписью \"Отсканируйте в приложении Т‑Банка\", т.к. мы не можем отвечать, что у другого банка есть возможность сканирования QR-кода внутри приложения, поэтому мы указываем только информацию про Т‑Банк\n4. По СБП не предусмотрена двухстадийная оплата, соответственно холдирование невозможно даже при рекуррентном платеже\n5. Способ оплаты СБП не работает для маркетплейсов\n6. Внимание! Тестирование оплаты через Систему быстрых платежей возможно на prod окружении и только на demo терминале \n\nURL: https://securepay.tinkoff.ru/v2/\n\n## Статусная модель платежа \nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`.|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL`, и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**ASYNC_REFUNDING**|Обработка возврата денежных средств по QR|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**CANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**ATTEMPTS_EXPIRED**|Клиент превысил количество попыток открытия формы|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схемах ниже изображен полный жизненный цикл платежа\n[![scheme](https://acdn.t-static.ru/static/documents/schemaSBPPayments.png)](https://acdn.t-static.ru/static/documents/schemaSBPPayments.png)\n\n## Привязка счёта\n### Таблица статусов привязки счёта\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос AddAccountQr или GetQr для сессии с рекуррентным платежом|\n|**PROCESSING**|QR сформирован и отправлен мерчанту|\n|**ACTIVE**|Привяза счета прошла успешно|\n|**INACTIVE**|Банк отклонил привязку счета|\n### Схема привязки счёта \n[![scheme](https://acdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)](https://acdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)\n\nНа схеме ниже приведены переходы статуса привязки счета при оплате с одновременной привязкой. Переходы статуса платежа в данной операции показаны на схеме полного жизненного цикла платежа\n[![scheme](https://acdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)](https://acdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)\n\n## Рекуррентный платеж\n### Таблица статусов рекуррентного платежа\n|Статус | Правило перехода|\n|--- | ---|\n|NEW | MAPI получил запрос Init. После этого он создает новый платеж в статусе NEW и возвращает обратно его идентификатор в параметре PaymentId|\n|FORM_SHOWED | MAPI принял запрос на обработку платежа. Ожидается подтверждение от НСПК о проведении оплаты по привязке|\n|AUTHORIZING | MAPI принял запрос от НСПК на авторизацию платежа|\n|AUTHORIZED | Платеж авторизован, деньги заблокированы на карте клиента|\n|CONFIRMING | Подтверждение платежа обрабатывается MAPI и платежной системой|\n|CONFIRMED | Платеж подтвержден, деньги списаны с карты клиента|\n|REFUNDING | Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|ASYNC_REFUNDING | Обработка возврата денежных средств по QR|\n|PARTIAL_REFUNDED | Частичный возврат по подтвержденному платежу завершился успешно|\n|REFUNDED | Полный возврат по подтвержденному платежу завершился успешно|\n|CANCELED | Мерчант отменил платеж|\n|REJECTED | Банк отклонил платеж|\n\n### Схема проведения рекуррентого платежа\n[![scheme](https://acdn.t-static.ru/static/documents/schtmaSBPRecurrent.png)](https://acdn.t-static.ru/static/documents/schtmaSBPRecurrent.png) \n\n\n### Логика привязки при наличии нескольких терминалов\n[![scheme;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png)](https://acdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png) \nЕсли клиент привязывает счет к терминалу мерчанта, у которого есть несколько терминалов, то клиент имеет возможность выполнять рекуррентные платежи на всех терминалах Мерчанта\n\nПроцесс выглядит следующим образом:\n1. Мерчанту принадлежат терминалы \"А\" и \"Б\", покупатель ранее проводил оплату только по терминалу \"А\".\n2. Покупатель пропбует провести рекуррентный платеж по терминалу \"Б\".\n3. Система проверяет наличие привязки по терминалу \"Б\".\n4. Так как привязка по этому терминалу не проводилась, система с помощью идентификатора магазина проверяет наличие привязки на других терминалах мерчанта. \n5. Система успешно находит привязку по терминалу \"А\", в связи с чем разрешает проведение рекуррентного платежа.\n\n# Подключение СБП\n## Откройте расчетный счёт\nДля подключения СБП клиент должен быть резидентом. Если клиент нерезидент, СБП работать не будет\n\nЗаполните [заявку](https://www.tbank.ru/business/) и откройте расчетный счет в Т‑Банке\n\n## Подключите Интернет эквайринг\nПодайте [заявку](https://business.tbank.ru/oplata/main) на подключение интернет эквайринг и заполните данные об организации и магазине\n## Выберите доступные типы интеграций\nСБП доступен для следующих типов интеграций:\n* Платежный [виджет](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Vidzhet-SBP),\n* Платежный [API](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Obshaya-informaciya-dlya-oplat-po-QR),\n* Мобильный [SDK](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Sposoby-integracii),\n* Через Агента ТСП,\n* Стикер с QR-кодом для размещения на кассе.\n\nДалее, настройте интеграцию на сайте, в мобильном приложении или в любом другом интерфейсе\n\n## Включение СБП\n\n### Требования к подключению СБП\nРасчётный счёт в Т‑Банке установлен в магазине счётом для выплат\n\n### Подключение СБП в Личном Кабинете\nВойдите в свой личный кабинет и откройте страницу магазина, для которого вы хотите подключить оплату\nчерез СБП. Перейдите на вкладку “Способы оплаты“\n\n[![sposobioplati;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)](https://acdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)\n\nНажмите \"Настроить“ на плашке Система быстрых платежей.\nДалее выбираете тот способ интеграции, который планируете использовать\n\n#### Платежная форма Т‑Банка\nЕсли планируете использовать её, то выбираете данную вкладку и нажимаете \"Включить\"\n\n[![sbp_pf_tinkoff_off;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_tinkoff_on;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)\n\n#### Собственная платежная форма\nЕсли у вас уже есть собственная платежная форма или вы хотите подключить виджет СБП, то необходимо нажать \"Включить\" в данной вкладке. После включения останется настроить интеграцию по API \n\n[![sbp_pf_svoya_off;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_svoya_on;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)](https://acdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)\n\n#### Приложение \nЕсли вы планируете использовать СБП в своём приложении, то включаете соответствующую настройку, после чего следуете инструкции размещенной в данном разделе \n\n[![app_sbp_off:block;margin:auto|](https://acdn.t-static.ru/static/documents/app_sbp_off.jpg)](https://acdn.t-static.ru/static/documents/app_sbp_off.jpg)\n\nПосле включения вкладка будет выглядить следующим образом\n\n[![app_sbp_on:block;margin:auto|](https://acdn.t-static.ru/static/documents/app_sbp_on.jpg)](https://acdn.t-static.ru/static/documents/app_sbp_on.jpg)\n\n#### Статический QR\nВне зависимости от того, какой способ интеграции вы используете, вы всегда можете скачать статический QR-код в данном разделе\n\n[![novii_static_qr:block;margin:auto|](https://acdn.t-static.ru/static/documents/novii_static_qr.png)](https://acdn.t-static.ru/static/documents/novii_static_qr.png)\n\n\n### Настройка интеграций при включении способа оплаты СБП\n#### Платежная форма Т‑Банка\nПосле подключения СБП в Личном кабинете, QR код автоматически отобразится на платежной форме, ничего\nдополнительно интегрировать не нужно.\n[Описание](https://www.tbank.ru/kassa/develop/widget/install/), как интегрировать Платежную форму на сайт.\nПлатёжные формы Т‑Банка:\nМобильная\n\n[![pfsbpmobile;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/pfsbpmobile.png)](https://acdn.t-static.ru/static/documents/pfsbpmobile.png)\n\nДесктопная\n[![pfsbpdesktop;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/pfsbpdesktop.png)](https://acdn.t-static.ru/static/documents/pfsbpdesktop.png)\n\nВнимание! Способ — Оплата Картой, является обязательным, отключить его нельзя, все остальные\nспособы — опциональные и их можно выключить в Личном кабинете\n\n#### API\nЕсли ваша интеграция по API, то вы самостоятельно отображаете полученный QR-код или кнопку на вашем\nсайте или любом другом интерфейсе\n\n#### SDK\nЕсли ваша интеграция предусматривает исопользование мобильного приложения, то в SDK необходимо\nпередать специальные параметры в [IOS](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-ios) и [Android](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-android) для отображения QR кода\n\n#### Агентская интеграция\nЕсли ваша интеграция настроена с Агентом ТСП, то необходимо\n1. Создать магазин типа – **Выставление счета**.\n2. Включить СБП в способах оплаты.\n3. Сообщить Агенту ТСП об успешном включении.\n\nИнтерфейс \"SDK Т‑Банка\": \n\n[![sbpsdk1;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbpsdk1.png)](https://acdn.t-static.ru/static/documents/sbpsdk1.png)\n\n[![sbpsdk2;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/sbpsdk2.png)](https://acdn.t-static.ru/static/documents/sbpsdk2.png)\n\n### Прием платежей с помощью стикеров с QR-кодом\nСтикер со статичным QR кодом – платежный QR код который размещается в кассовой зоне магазина.\nПосле создании магазина в Личном кабинете, его можно скачать в режиме онлайн\n\n#### Получение стикера\nДля получения стикера с QR кодом небходимо:\n1. Создать магазин с выставлением счета, если у вас уже есть магазин, то далее п.2.\n2. Зайдите в настройки СБП в разделе \"Способы оплаты\".\n3. Нажать на кнопку \"скачать\" в разделе Статический QR. \n4. Полученный QR код необходимо распечатать и разместить в кассовой зоне вашего магазина.\nСтикер \"QR Т‑Банка”:\n\n\n[![sbpqr;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/novii_static_qr_skrin.png)](https://acdn.t-static.ru/static/documents/novii_static_qr_skrin.png)\n\n\nПосле сканирования покупателем Стикера с QR кодом ему необходимо будет ввести сумму и\nподтвердить оплату\n\n**Внимание!** Фискализация по операциям с помощью Стикера с QR-кодом не происходит через онлайн\nкассы, даже если онлайн кассы подключенны в личном кабинете\n\n#### Нотификации об оплате\nПосле оплаты вам придет нотификация в зависимости от настроек, на email или по http на ваш сервер\n\n**Магазин — Выставление счетов** \nНастройка нотификаций происходит через acq_help@tbank.ru\n\n**Магазин — Интернет магазин** \nЕсли у вас уже есть интернет-магазин, то нотификации вы можете самостоятельно настроить в разделе\nТерминал\n\n\n[![nastroikiterminala;display:block;margin:auto|](https://acdn.t-static.ru/static/documents/nastroikiterminala.png)](https://acdn.t-static.ru/static/documents/nastroikiterminala.png)\n\n### Настроить выбор банка при интеграции по API\nЕсли вы интегрировались по API, то можно настроить выбор банка при оплате по СБП.\nДля этого нужно создать прямую ссылку, которая существует для того, чтобы перенаправить\nклиента при клике на ссылку в конкретное приложение банка.\n1. Чтобы сформировать прямую ссылку на переход в приложение банка, необходимо заменить\nhttps из функциональной ссылки на значение параметра schema из списка банков.\n2. Список банков лежит по ссылке - https://qr.nspk.ru/proxyapp/c2bmembers.json.\n\nНапример:\nФункциональная ссылка https://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nЗаменить https на соответствующую schema Т‑Банка —\nbank100000000004://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nДля каждого из банков сделать прямую ссылку по логике указанной в п.1. На Вашей платёжной форме\nнеобходимо отобразить список банков из п. 2\n\n# Виджет СБП\nСБП можно интегрировать с помощью виджета, ниже будет описан порядок такой интеграции\n\n## Подключение платежного виджета\n\n### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка \"Оплатить СБП\"\n```\n\n \n \n \n \n \n \n\n
    \n
    \n \n \n \n \n \n \n \n
    \n\n```\nСумма заказа \"amount\" указывается в рублях, копейки через точку\n\n## Формирование чека\n\nДобавьте в код поле ввода receipt:\n```\n\n```\nВ значении атрибута value поля receipt нужно указывать параметры чека. Например, добавьте следующий код:\n```\n var form = document.forms.TinkoffPayForm;\n\n // Данные для чека\n Object.defineProperty(form.receipt, 'value', {\n get: function () {\n return JSON.stringify({\n Email: form.email.value,\n Phone: form.phone.value,\n EmailCompany: 'mail@mail.com',\n Taxation: 'patent',\n Items: [\n {\n Name: form.description.value || 'Оплата',\n Price: form.amount.value + '00',\n Quantity: 1.0,\n Amount: form.amount.value + '00',\n PaymentMethod: 'full_prepayment',\n PaymentObject: 'service',\n Tax: 'none',\n },\n ],\n });\n },\n });\n```\n## Подключение СБП\n## Подключение СБП в Личном Кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернетмагазина, для которого вы хотите подключить оплату через СБП на сайте. Перейдите на вкладку “Способы оплаты”. Для подключения СБП надо провести первый платеж любым доступным способом.\n2. Нажмите на плашку СБП для подключения оплаты через СБП на сайте.\n3. В случае успешного подключения СБП для интернет-магазина плашка должна стать активной. \n## Настройка оплаты товаров\nДля подключения оплаты СБП для одного и более товаров потребуется передавать в метод initPayments объект настроек, в котором определено поле paymentItems \n\nЗначением поля paymentItems является массив объектов, которые определяют размещение платёжных кнопок и информацию о платеже\n\nПример кода приведен ниже:\n \n```\n var terminalkey = document.forms.TinkoffPayForm.terminalkey;\n\n var widgetParameters = {\n terminalKey: terminalkey.value,\n paymentItems: [\n {\n container: document.getElementById(\"tinkoffWidgetContainer1\"),\n paymentInfo: function () {\n return {\n paymentData: document.forms.TinkoffPayForm,\n };\n },\n },\n ],\n paymentSystems: { TinkoffFps: {} },\n };\n\n window.addEventListener(\"load\", function () {\n initPayments(widgetParameters);\n });\n\n```\n## Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Информация о платеже| \n## Тесты по QR\n* Сценарий “Платеж-успех” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту. \n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId).\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом CONFIRMED.\n* Сценарий “Платеж — отказ по таймауту” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId) и параметр IsDeadlineExpired = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом DEADLINE_EXPIRED.\n* Сценарий “Платеж – отказ, отклонен Т‑Кассой” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии\nТ‑Кассы (PaymentId) и параметр IsRejected = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом REJECTED.\n* Сценарий “Возврат – успех \n1) Инициировать возврат (не отмену) методом Cancel тестового платежа по QR-коду СБП,\nвыполненного успешно в тесте “Платеж-успех”\n2) Запросить текущий статус платежа вызывая метод **GetState**.\n3) Получить ответ со статусом REFUNDED.\n\n## Настройка платежного виджета\nВставьте идентификатор магазина в код платежного виджета в значение параметра terminalkey. Идентификатор магазина выдаётся банком,\nего можно получить в личном кабинете (раздел «Магазины», вкладка \"Терминалы\"):\n\nЕсли необходимо изменить состав полей платежного виджета, укажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо поле, выставьте у этого поля параметр required:\n```\n\n```\nСтилизация платежного виджета производится магазином самостоятельно. Ограничений на стилизацию со стороны Т‑Банка нет:\n```\n \n \n \n \n\n```\nПроверить статус платежа можно в личном кабинете интернет-эквайринга, просмотрев операции по СБП, по API с помощью метода [GetState](https://www.tbank.ru/kassa/dev/payments/#tag/Standartnyj-platyozh/paths/~1GetState/post) или с помощью нотификации по http или на e-mail в разделе [Нотификации мерчанта об операциях](https://www.tinkoff.ru/kassa/dev/payments/index.html#tag/Notifikacii-Merchanta-ob-operaciyah)" + "description": "## Общая информация для оплат по QR\n1. Банк по умолчанию покупатель выбирает на своём устройстве, через API это настроить невозможно\n2. Если оплата СБП отклоняется на стороне эмитента, эквайер на своей стороне не может повлиять на это \n3. На платежной форме банка при выборе способа оплаты СБП, отображается QR-код с надписью \"Отсканируйте в приложении Т‑Банка\", т.к. мы не можем отвечать, что у другого банка есть возможность сканирования QR-кода внутри приложения, поэтому мы указываем только информацию про Т‑Банк\n4. По СБП не предусмотрена двухстадийная оплата, соответственно холдирование невозможно даже при рекуррентном платеже\n5. Способ оплаты СБП не работает для маркетплейсов\n6. Внимание! Тестирование оплаты через Систему быстрых платежей возможно на prod окружении и только на demo терминале \n\nURL: https://securepay.tinkoff.ru/v2/\n\n## Статусная модель платежа \nВ процессе обработки платеж меняет свое состояние. В таблице ниже описаны основные статусы, а также условия перехода в них\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос `Init`. После этого, он создает новый платеж в статусе **NEW** и возвращает обратно его идентификатор в параметре `PaymentId` и ссылку на платежную форму в параметре `PaymentURL`.|\n|**FORM_SHOWED**|Мерчант перенаправил клиента на страницу платежной формы `PaymentURL`, и страница загрузилась у клиента в браузере|\n|**AUTHORIZING**|Платеж обрабатывается MAPI и платежной системой|\n|**AUTHORIZED**|Платеж авторизован, деньги заблокированы на карте клиента|\n|**CONFIRMING**|Подтверждение платежа обрабатывается MAPI и платежной системой|\n|**CONFIRMED**|Платеж подтвержден, деньги списаны с карты клиента|\n|**REFUNDING**|Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|**ASYNC_REFUNDING**|Обработка возврата денежных средств по QR|\n|**PARTIAL_REFUNDED**| Частичный возврат по подтвержденному платежу завершился успешно|\n|**REFUNDED**|Полный возврат по подтвержденному платежу завершился успешно|\n|**CANCELED**|Мерчант отменил платеж|\n|**DEADLINE_EXPIRED**|1. Клиент не завершил платеж в срок жизни ссылки на платежную форму `PaymentURL`. Этот срок Мерчант настраивает в Личном кабинете, либо передает в параметре `RedirectDueDate` при вызове метода `Init`
    2. Платеж не прошел проверку 3D-Secure в срок|\n|**ATTEMPTS_EXPIRED**|Клиент превысил количество попыток открытия формы|\n|**REJECTED**|Банк отклонил платеж|\n|**AUTH_FAIL**|Платеж завершился ошибкой или не прошел проверку 3D-Secure|\n\nНа схемах ниже изображен полный жизненный цикл платежа\n[![scheme](https://cdn.t-static.ru/static/documents/schemaSBPPayments.png)](https://cdn.t-static.ru/static/documents/schemaSBPPayments.png)\n\n## Привязка счёта\n### Таблица статусов привязки счёта\n|Статус|Правило перехода|\n|---|---|\n|**NEW**|MAPI получил запрос AddAccountQr или GetQr для сессии с рекуррентным платежом|\n|**PROCESSING**|QR сформирован и отправлен мерчанту|\n|**ACTIVE**|Привяза счета прошла успешно|\n|**INACTIVE**|Банк отклонил привязку счета|\n### Схема привязки счёта \n[![scheme](https://cdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)](https://cdn.t-static.ru/static/documents/perehody_statysa_privyazki.png)\n\nНа схеме ниже приведены переходы статуса привязки счета при оплате с одновременной привязкой. Переходы статуса платежа в данной операции показаны на схеме полного жизненного цикла платежа\n[![scheme](https://cdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)](https://cdn.t-static.ru/static/documents/Privyazka_pri_odnovremennoi_oplate.png)\n\n## Рекуррентный платеж\n### Таблица статусов рекуррентного платежа\n|Статус | Правило перехода|\n|--- | ---|\n|NEW | MAPI получил запрос Init. После этого он создает новый платеж в статусе NEW и возвращает обратно его идентификатор в параметре PaymentId|\n|FORM_SHOWED | MAPI принял запрос на обработку платежа. Ожидается подтверждение от НСПК о проведении оплаты по привязке|\n|AUTHORIZING | MAPI принял запрос от НСПК на авторизацию платежа|\n|AUTHORIZED | Платеж авторизован, деньги заблокированы на карте клиента|\n|CONFIRMING | Подтверждение платежа обрабатывается MAPI и платежной системой|\n|CONFIRMED | Платеж подтвержден, деньги списаны с карты клиента|\n|REFUNDING | Мерчант запросил отмену подтвержденного платежа. Возврат обрабатывается MAPI и платежной системой|\n|ASYNC_REFUNDING | Обработка возврата денежных средств по QR|\n|PARTIAL_REFUNDED | Частичный возврат по подтвержденному платежу завершился успешно|\n|REFUNDED | Полный возврат по подтвержденному платежу завершился успешно|\n|CANCELED | Мерчант отменил платеж|\n|REJECTED | Банк отклонил платеж|\n\n### Схема проведения рекуррентого платежа\n[![scheme](https://cdn.t-static.ru/static/documents/schtmaSBPRecurrent.png)](https://cdn.t-static.ru/static/documents/schtmaSBPRecurrent.png) \n\n\n### Логика привязки при наличии нескольких терминалов\n[![scheme;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png)](https://cdn.t-static.ru/static/documents/sbp_recurrent_multiterminal_scheme.png) \nЕсли клиент привязывает счет к терминалу мерчанта, у которого есть несколько терминалов, то клиент имеет возможность выполнять рекуррентные платежи на всех терминалах Мерчанта\n\nПроцесс выглядит следующим образом:\n1. Мерчанту принадлежат терминалы \"А\" и \"Б\", покупатель ранее проводил оплату только по терминалу \"А\".\n2. Покупатель пропбует провести рекуррентный платеж по терминалу \"Б\".\n3. Система проверяет наличие привязки по терминалу \"Б\".\n4. Так как привязка по этому терминалу не проводилась, система с помощью идентификатора магазина проверяет наличие привязки на других терминалах мерчанта. \n5. Система успешно находит привязку по терминалу \"А\", в связи с чем разрешает проведение рекуррентного платежа.\n\n# Подключение СБП\n## Откройте расчетный счёт\nДля подключения СБП клиент должен быть резидентом. Если клиент нерезидент, СБП работать не будет\n\nЗаполните [заявку](https://www.tbank.ru/business/) и откройте расчетный счет в Т‑Банке\n\n## Подключите Интернет эквайринг\nПодайте [заявку](https://business.tbank.ru/oplata/main) на подключение интернет эквайринг и заполните данные об организации и магазине\n## Выберите доступные типы интеграций\nСБП доступен для следующих типов интеграций:\n* Платежный [виджет](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Vidzhet-SBP),\n* Платежный [API](https://www.tbank.ru/kassa/dev/payments/#tag/Oplata-cherez-SBP/Obshaya-informaciya-dlya-oplat-po-QR),\n* Мобильный [SDK](https://www.tbank.ru/kassa/dev/payments/#section/Vvedenie/Sposoby-integracii),\n* Через Агента ТСП,\n* Стикер с QR-кодом для размещения на кассе.\n\nДалее, настройте интеграцию на сайте, в мобильном приложении или в любом другом интерфейсе\n\n## Включение СБП\n\n### Требования к подключению СБП\nРасчётный счёт в Т‑Банке установлен в магазине счётом для выплат\n\n### Подключение СБП в Личном Кабинете\nВойдите в свой личный кабинет и откройте страницу магазина, для которого вы хотите подключить оплату\nчерез СБП. Перейдите на вкладку “Способы оплаты“\n\n[![sposobioplati;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)](https://cdn.t-static.ru/static/documents/fa5996fc-d52a-4f4b-b1cb-71bf4ebcd910.jpg)\n\nНажмите \"Настроить“ на плашке Система быстрых платежей.\nДалее выбираете тот способ интеграции, который планируете использовать\n\n#### Платежная форма Т‑Банка\nЕсли планируете использовать её, то выбираете данную вкладку и нажимаете \"Включить\"\n\n[![sbp_pf_tinkoff_off;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_tinkoff_on;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_tinkoff_on.jpg)\n\n#### Собственная платежная форма\nЕсли у вас уже есть собственная платежная форма или вы хотите подключить виджет СБП, то необходимо нажать \"Включить\" в данной вкладке. После включения останется настроить интеграцию по API \n\n[![sbp_pf_svoya_off;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_off.jpg)\n\nПосле подключения вкладка будет выглядить следующим образом \n\n[![sbp_pf_svoya_on;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)](https://cdn.t-static.ru/static/documents/sbp_pf_svoya_on.jpg)\n\n#### Приложение \nЕсли вы планируете использовать СБП в своём приложении, то включаете соответствующую настройку, после чего следуете инструкции размещенной в данном разделе \n\n[![app_sbp_off:block;margin:auto|](https://cdn.t-static.ru/static/documents/app_sbp_off.jpg)](https://cdn.t-static.ru/static/documents/app_sbp_off.jpg)\n\nПосле включения вкладка будет выглядить следующим образом\n\n[![app_sbp_on:block;margin:auto|](https://cdn.t-static.ru/static/documents/app_sbp_on.jpg)](https://cdn.t-static.ru/static/documents/app_sbp_on.jpg)\n\n#### Статический QR\nВне зависимости от того, какой способ интеграции вы используете, вы всегда можете скачать статический QR-код в данном разделе\n\n[![novii_static_qr:block;margin:auto|](https://cdn.t-static.ru/static/documents/novii_static_qr.png)](https://cdn.t-static.ru/static/documents/novii_static_qr.png)\n\n\n### Настройка интеграций при включении способа оплаты СБП\n#### Платежная форма Т‑Банка\nПосле подключения СБП в Личном кабинете, QR код автоматически отобразится на платежной форме, ничего\nдополнительно интегрировать не нужно.\n[Описание](https://www.tbank.ru/kassa/develop/widget/install/), как интегрировать Платежную форму на сайт.\nПлатёжные формы Т‑Банка:\nМобильная\n\n[![pfsbpmobile;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/pfsbpmobile.png)](https://cdn.t-static.ru/static/documents/pfsbpmobile.png)\n\nДесктопная\n[![pfsbpdesktop;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/pfsbpdesktop.png)](https://cdn.t-static.ru/static/documents/pfsbpdesktop.png)\n\nВнимание! Способ — Оплата Картой, является обязательным, отключить его нельзя, все остальные\nспособы — опциональные и их можно выключить в Личном кабинете\n\n#### API\nЕсли ваша интеграция по API, то вы самостоятельно отображаете полученный QR-код или кнопку на вашем\nсайте или любом другом интерфейсе\n\n#### SDK\nЕсли ваша интеграция предусматривает исопользование мобильного приложения, то в SDK необходимо\nпередать специальные параметры в [IOS](https://opensource.tbank.ru/mobile-tech/asdk-ios) и [Android](https://opensource.tbank.ru/mobile-tech/asdk-android) для отображения QR кода\n\n#### Агентская интеграция\nЕсли ваша интеграция настроена с Агентом ТСП, то необходимо\n1. Создать магазин типа – **Выставление счета**.\n2. Включить СБП в способах оплаты.\n3. Сообщить Агенту ТСП об успешном включении.\n\nИнтерфейс \"SDK Т‑Банка\": \n\n[![sbpsdk1;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbpsdk1.png)](https://cdn.t-static.ru/static/documents/sbpsdk1.png)\n\n[![sbpsdk2;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/sbpsdk2.png)](https://cdn.t-static.ru/static/documents/sbpsdk2.png)\n\n### Прием платежей с помощью стикеров с QR-кодом\nСтикер со статичным QR кодом – платежный QR код который размещается в кассовой зоне магазина.\nПосле создании магазина в Личном кабинете, его можно скачать в режиме онлайн\n\n#### Получение стикера\nДля получения стикера с QR кодом небходимо:\n1. Создать магазин с выставлением счета, если у вас уже есть магазин, то далее п.2.\n2. Зайдите в настройки СБП в разделе \"Способы оплаты\".\n3. Нажать на кнопку \"скачать\" в разделе Статический QR. \n4. Полученный QR код необходимо распечатать и разместить в кассовой зоне вашего магазина.\nСтикер \"QR Т‑Банка”:\n\n\n[![sbpqr;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/novii_static_qr_skrin.png)](https://cdn.t-static.ru/static/documents/novii_static_qr_skrin.png)\n\n\nПосле сканирования покупателем Стикера с QR кодом ему необходимо будет ввести сумму и\nподтвердить оплату\n\n**Внимание!** Фискализация по операциям с помощью Стикера с QR-кодом не происходит через онлайн\nкассы, даже если онлайн кассы подключенны в личном кабинете\n\n#### Нотификации об оплате\nПосле оплаты вам придет нотификация в зависимости от настроек, на email или по http на ваш сервер\n\n**Магазин — Выставление счетов** \nНастройка нотификаций происходит через acq_help@tbank.ru\n\n**Магазин — Интернет магазин** \nЕсли у вас уже есть интернет-магазин, то нотификации вы можете самостоятельно настроить в разделе\nТерминал\n\n\n[![nastroikiterminala;display:block;margin:auto|](https://cdn.t-static.ru/static/documents/nastroikiterminala.png)](https://cdn.t-static.ru/static/documents/nastroikiterminala.png)\n\n### Настроить выбор банка при интеграции по API\nЕсли вы интегрировались по API, то можно настроить выбор банка при оплате по СБП.\nДля этого нужно создать прямую ссылку, которая существует для того, чтобы перенаправить\nклиента при клике на ссылку в конкретное приложение банка.\n1. Чтобы сформировать прямую ссылку на переход в приложение банка, необходимо заменить\nhttps из функциональной ссылки на значение параметра schema из списка банков.\n2. Список банков лежит по ссылке - https://qr.nspk.ru/proxyapp/c2bmembers.json.\n\nНапример:\nФункциональная ссылка https://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nЗаменить https на соответствующую schema Т‑Банка —\nbank100000000004://qr.nspk.ru/AS10004UVOQ9J4I489A8SG8NIA6P3F8B\nДля каждого из банков сделать прямую ссылку по логике указанной в п.1. На Вашей платёжной форме\nнеобходимо отобразить список банков из п. 2\n\n# Виджет СБП\nСБП можно интегрировать с помощью виджета, ниже будет описан порядок такой интеграции\n\n## Подключение платежного виджета\n\n### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка \"Оплатить СБП\"\n```\n\n \n \n \n \n \n \n\n
    \n
    \n \n \n \n \n \n \n \n
    \n\n```\nСумма заказа \"amount\" указывается в рублях, копейки через точку\n\n## Формирование чека\n\nДобавьте в код поле ввода receipt:\n```\n\n```\nВ значении атрибута value поля receipt нужно указывать параметры чека. Например, добавьте следующий код:\n```\n var form = document.forms.TinkoffPayForm;\n\n // Данные для чека\n Object.defineProperty(form.receipt, 'value', {\n get: function () {\n return JSON.stringify({\n Email: form.email.value,\n Phone: form.phone.value,\n EmailCompany: 'mail@mail.com',\n Taxation: 'patent',\n Items: [\n {\n Name: form.description.value || 'Оплата',\n Price: form.amount.value + '00',\n Quantity: 1.0,\n Amount: form.amount.value + '00',\n PaymentMethod: 'full_prepayment',\n PaymentObject: 'service',\n Tax: 'none',\n },\n ],\n });\n },\n });\n```\n## Подключение СБП\n## Подключение СБП в Личном Кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернетмагазина, для которого вы хотите подключить оплату через СБП на сайте. Перейдите на вкладку “Способы оплаты”. Для подключения СБП надо провести первый платеж любым доступным способом.\n2. Нажмите на плашку СБП для подключения оплаты через СБП на сайте.\n3. В случае успешного подключения СБП для интернет-магазина плашка должна стать активной. \n## Настройка оплаты товаров\nДля подключения оплаты СБП для одного и более товаров потребуется передавать в метод initPayments объект настроек, в котором определено поле paymentItems \n\nЗначением поля paymentItems является массив объектов, которые определяют размещение платёжных кнопок и информацию о платеже\n\nПример кода приведен ниже:\n \n```\n var terminalkey = document.forms.TinkoffPayForm.terminalkey;\n\n var widgetParameters = {\n terminalKey: terminalkey.value,\n paymentItems: [\n {\n container: document.getElementById(\"tinkoffWidgetContainer1\"),\n paymentInfo: function () {\n return {\n paymentData: document.forms.TinkoffPayForm,\n };\n },\n },\n ],\n paymentSystems: { TinkoffFps: {} },\n };\n\n window.addEventListener(\"load\", function () {\n initPayments(widgetParameters);\n });\n\n```\n## Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Информация о платеже| \n## Тесты по QR\n* Сценарий “Платеж-успех” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту. \n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId).\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом CONFIRMED.\n* Сценарий “Платеж — отказ по таймауту” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии Т‑Кассы (PaymentId) и параметр IsDeadlineExpired = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом DEADLINE_EXPIRED.\n* Сценарий “Платеж – отказ, отклонен Т‑Кассой” \n1) Инициировать начало платежной сессии – вызывать метод **Init**.\n2) Запросить формирование Динамического QR-кода **GetQr**.\n3) Отобразить Динамический QR-код на странице клиенту.\n4) Вызвать метод **SbpPayTest**, передавая в нем внутренний идентификатор платежной сессии\nТ‑Кассы (PaymentId) и параметр IsRejected = true.\n5) Запросить текущий статус платежа вызывая метод **GetState**.\n6) Получить ответ со статусом REJECTED.\n* Сценарий “Возврат – успех \n1) Инициировать возврат (не отмену) методом Cancel тестового платежа по QR-коду СБП,\nвыполненного успешно в тесте “Платеж-успех”\n2) Запросить текущий статус платежа вызывая метод **GetState**.\n3) Получить ответ со статусом REFUNDED.\n\n## Настройка платежного виджета\nВставьте идентификатор магазина в код платежного виджета в значение параметра terminalkey. Идентификатор магазина выдаётся банком,\nего можно получить в личном кабинете (раздел «Магазины», вкладка \"Терминалы\"):\n\nЕсли необходимо изменить состав полей платежного виджета, укажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо поле, выставьте у этого поля параметр required:\n```\n\n```\nСтилизация платежного виджета производится магазином самостоятельно. Ограничений на стилизацию со стороны Т‑Банка нет:\n```\n \n \n \n \n\n```\nПроверить статус платежа можно в личном кабинете интернет-эквайринга, просмотрев операции по СБП, по API с помощью метода [GetState](https://www.tbank.ru/kassa/dev/payments/#tag/Standartnyj-platyozh/paths/~1GetState/post) или с помощью нотификации по http или на e-mail в разделе [Нотификации мерчанта об операциях](https://www.tinkoff.ru/kassa/dev/payments/index.html#tag/Notifikacii-Merchanta-ob-operaciyah)" }, { "name": "Оплата через T‑Pay", - "description": "## Общая информация\nОплата доступна на мобильных устройствах и десктопах, проводится последовательным вызовом\nметодов:\n\n- `/TinkoffPay/terminals/{terminalKey}/status`,\n- `/Init`,\n- `/TinkoffPay/transactions/{paymentId}/versions/{version}/link` либо `/TinkoffPay/{paymentId}/QR`.\n\n# Другие способы интеграции \n\n## T‑Pay SDK\nT‑Pay SDK — интеграция способа оплаты в приложение. Документация по SDK активно поддерживается на GitHub. \nАдреса: \n* [SDK Android](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-android),\n* [SDK IOS](https://opensource.tbank.ru/tinkoff-mobile-tech/tinkoff-asdk-ios).\n\n## T‑Pay web\nT‑Pay web — способ интеграции через установку виджета на сайт\n\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n\n\n
    \n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n
    \n```\n#### Настройка платежного виджета\nВставьте идентификатор мерчанта в код платежного виджета в значение параметра terminalkey. Идентификатор мерчанта выдается Т‑Кассой,\nего можно получить в личном кабинете (раздел «Магазины»).\nЕсли необходимо изменить состав полей платежного виджета,\nукажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо\nполе, выставьте у этого поля параметр required:\n```\n \n```\nЕсли требуется открывать платежную форму в текущем окне,\nукажите у данного атрибута значение true:\n```\n \n```\nСтилизация платежного виджета производится мерчантом\nсамостоятельно. Ограничений на стилизацию со стороны Т‑Кассы нет:\n```\n \n```\n### Подключение T‑Pay\n#### Подключение T‑Pay в личном кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернет-магазина, для которого вы хотите подключить оплату через T‑Pay на сайте. Перейдите на вкладку «Способы оплаты».\n2. Нажмите кнопку «Настроить» на плашке T‑Pay, перейдите в подраздел «Своя платежная\nформа» и нажмите «Включить».\n3. В случае успешного подключения T‑Pay для интернет-магазина должна отобразиться\nстраница активного статуса подключения T‑Pay на сайте.\n\n\n#### Подключение T‑Pay на страницах интернет-магазина\nВставьте приведенный ниже код на страницу вашего сайта сразу после кода платежного виджета:\n```\n\n\n```\n\n\nМетод initPayments запускает инициализацию платежных кнопок T‑Pay.\nВходным параметром метода является объект с данными о настройках проведения платежей\n##### Структура объекта T‑Pay\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n\n### Настройка оплаты множества товаров\nДля подключения оплаты T‑Pay на одной странице для нескольких товаров потребуется передавать в метод initPayments объект\nнастроек, в котором определено поле paymentItems.\nЗначением поля paymentItems является массив объектов, которые определяют размещение платежных кнопок и информацию о платеже.\nПример кода страницы приведен ниже:\n```\n
    \n\n
    \n\n\n```\n\n#### Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n## T‑Pay + T‑ID.\nДля интеграции T‑Pay + T‑ID, предварительно требуется настроить интеграцию с ID. Ознакомиться с его API можно по ссылке https://developer.tbank.ru/products/scenarios/TID/w2w\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n\n\n
    \n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n\t\n\n
    \n```\n#### Настройка платежного виджета\nВставьте идентификатор мерчанта в код платежного виджета в значение параметра terminalkey. Идентификатор мерчанта выдается Т‑Кассой,\nего можно получить в личном кабинете (раздел «Магазины»).\nЕсли необходимо изменить состав полей платежного виджета,\nукажите у полей, которые хотите скрыть, type=\"hidden\":\n```\n \n```\nЕсли необходимо сделать обязательным для заполнения какое-либо\nполе, выставьте у этого поля параметр required:\n```\n \n```\nЕсли требуется открывать платежную форму в текущем окне,\nукажите у данного атрибута значение true:\n```\n \n```\nСтилизация платежного виджета производится мерчантом\nсамостоятельно. Ограничений на стилизацию со стороны Т‑Кассы нет:\n```\n \n```\n### Подключение T‑Pay\n#### Подключение T‑Pay в личном кабинете\n1. Перейдите в свой личный кабинет и откройте страницу интернет-магазина, для которого вы хотите подключить оплату через T‑Pay на сайте. Перейдите на вкладку «Способы оплаты».\n2. Нажмите кнопку «Настроить» на плашке T‑Pay, перейдите в подраздел «Своя платежная\nформа» и нажмите «Включить».\n3. В случае успешного подключения T‑Pay для интернет-магазина должна отобразиться\nстраница активного статуса подключения T‑Pay на сайте.\n\n\n#### Подключение T‑Pay на страницах интернет-магазина\nВставьте приведенный ниже код на страницу вашего сайта сразу после кода платежного виджета:\n```\n\n\n```\n\n\nМетод initPayments запускает инициализацию платежных кнопок T‑Pay.\nВходным параметром метода является объект с данными о настройках проведения платежей\n##### Структура объекта T‑Pay\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n\n### Настройка оплаты множества товаров\nДля подключения оплаты T‑Pay на одной странице для нескольких товаров потребуется передавать в метод initPayments объект\nнастроек, в котором определено поле paymentItems.\nЗначением поля paymentItems является массив объектов, которые определяют размещение платежных кнопок и информацию о платеже.\nПример кода страницы приведен ниже:\n```\n
    \n\n
    \n\n\n```\n\n#### Структура объекта массива paymentItems\n|Наименование|Обязательный|Тип данных|Описание|\n|-|---|--|-|\n|container|Да|HTMLFormElement|Элемент, в который вставляют кнопки|\n|paymentInfo|Да|Function/Object|Платежная информация|\n\n## T‑Pay + T‑ID.\nДля интеграции T‑Pay + T‑ID, предварительно требуется настроить интеграцию с ID. Ознакомиться с его API можно по ссылке https://developer.tbank.ru/products/scenarios/TID/w2w\n\n### Подключение платежного виджета\n\n#### Установка платежного виджета на сайт\nВставьте следующий код на ваш сайт в место, где должна располагаться кнопка «Оплатить»\n```\n\n\n\n\n