Рублевое платежное поручение

Обновлено 1 июня 2026

Адрес MCP-сервера

Тестовый контур

https://iftfintech.testsbi.sberbank.ru:9443/fintech/api/business-payments/mcp

Промышленный контур

https://fintech.sberbank.ru:9443/fintech/api/business-payments/mcp

Scope

Для доступа к этому методу в параметре scope ссылки авторизации пользователя должен быть указан сервис MCP_COMMON и MCP_PAYMENT.

Авторизация и аутентификация

Для успешного взаимодействия вам потребуются следующие параметры:

• TLS-сертификат: Необходим для организации защищенного канала связи и аутентификации вашего приложения.

• Access_token: Токен доступа, который требуется передавать в заголовках.

Инструменты (Tools)

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

Свойство	Описание
Имя	rur_payment.create_invoice
Описание	Создание черновика рублевого платежного поручения по свободным реквизитам. Черновик требует подписания в СберБизнес и не является исполненным платежом.
Операция Scope	MCP_PAYMENT
Бизнес-сценарий	Инициирование нового рублевого платежа. LLM генерирует UUID, запрашивает у пользователя реквизиты, вызывает инструмент и сообщает пользователю результат.

Схема взаимодействия

Входные параметры

externalId

required

Уникальный идентификатор платежа. Должен быть сгенерирован LLM клиентом (не повторяется для разных платежей).
Пример: a44ebab9-2dea-d47f-e360-8e5659675740

amount

required

Сумма платежа, строго положительная.
Пример: 1.01

purpose

required

Назначение платежа
Пример: Оплата заказа №123. НДС не облагается

payeeAccount

required

Счет получателя платежа
Пример: 40802810600000200000

payeeBankBic

required

БИК банка получателя платежа
Пример: 044525225

payeeBankCorrAccount

required

Корсчет банка получателя платежа
Пример: 30101810400000000225

payeeInn

required

ИНН получателя платежа
Пример: 7707083893

payeeKpp

required

КПП получателя платежа
Пример: 222201001

payeeName

required

Полное наименование получателя платежа
Пример: ООО "Наименование получателя"

Типовой workflow (рекомендация для LLM)

1. Сгенерировать новый UUID для externalId.
2. Запросить у пользователя все необходимые реквизиты платежа.
3. Вызвать rur_payment.create_invoice с переданными данными.
4. Получить ответ.
5. Сообщить пользователю информацию о создании Черновика. Пример: «Черновик создан, номер {number}, externalId {externalId}. Для подписания перейдите в СберБизнес.»
6. При необходимости через настройку AI-агента сформировать ссылку на подписание:

{контур_банка}/ic/ufs/rpp-light/index.html#/payment-creator/{externalid}

, где:

{контур_банка}

• Тестовый контур: https://efs-sbbol-ift-web.testsbi.sberbank.ru:9443
• Промышленный контур (СМС-пользователь): https://sbi.sberbank.ru:9443
• Промышленный контур (Токен-пользователь): http://localhost:28016

{externalId}

• externalId — уникальный идентификатор платежного документа. Присваивается при создании платежного поручения.

7. При необходимости в дальнейшем вызывать rur_payment.get_state для отслеживания статуса.

Особые условия:

• Для использования tools MCP-сервера необходимо использовать подходящие промпты с указанием необходимой информации.
• Перед отправкой платежного поручения в банк рекомендуется получить подтверждение от пользователя, что реквизиты верны. Созданный черновик платежного поручения можно будет отредактировать вручную в СберБизнес в случае некорректных данных.
• Без подписания платежное поручение останется в статусе черновика и не будет исполнено банком. Для его исполнения пользователю необходимо перейти в СберБизнес и подписать черновик.
• Сумма (amount) всегда должна быть положительной.
• Черновик ≠ исполненный платеж — обязательна подпись в СберБизнес.
• Для каждого нового платежа генерируется уникальный externalId.

Пример промпта:

Создай платежное поручение для ООО "Ромашка" на 100 тысяч рублей за услуги по договору 111, НДС 20%.

• В таком случае AI-агент должен запросить еще ИНН, КПП, номер счета и реквизиты банка получателя - БИК и корреспондентсткий счет. Данные плательщика будут указаны автоматически.

• Также AI-агент должен самостоятельно сгенерировать externalId (UUID, уникальный идентификатор платежа) для запроса создания платежного поручения.

Получить статус платежа

Свойство	Описание
Имя	rur_payment.get_state
Описание	Получение текущего статуса обработки рублевого платежного поручения (РПП). История статусов не предоставляется, возвращается только актуальное состояние.
Операция Scope	MCP_PAYMENT
Бизнес-сценарий	Используется для опроса статуса платежа после создания черновика или при необходимости проверить, перешел ли платеж в финальное состояние (успех/отказ).
Лимиты	Не рекомендуется вызывать инструмент чаще 5 раз в секунду.

Входные параметры

externalId

required

Уникальный идентификатор платежа. Который был сгенерирован LLM при создании черновика платежа.
Пример: a44ebab9-2dea-d47f-e360-8e5659675740

При получении ошибки в ответе (в т.ч. CHECKERROR, REQUISITEERROR) необходимо показать пользователю текст ошибки из поля "bankComment" (если доступно).

Статусы

bankStatus	Наименование статуса	Назначение кода состояния
Промежуточный/Продолжать опрашивать
ACCEPTED	Принят	Электронный документ принят на стороне Банка
ACCEPTED_BY_ABS	Принят АБС или Принят	Электронный документ был принят к обработке в АБС Банка
CARD2	Картотека 2 или Ожидает оплаты	АБС обнаружено, что на счете плательщика недостаточно средств для исполнения документа
CREATED	Создан	Документ записан в БД, проверки не выполнялись
DELAYED	Приостановлен	Обработка электронного документа была приостановлена
DELIVERED	Доставлен	Запрос доставлен в ДБО и взят в обработку
DELIVERED_RZK	Доставлен в СБК	Электронный документ отправлен в СБК и получен квиток о доставке
FRAUDALLOW	Одобрен ФРОД	Проверка во ФРОДЕ прошла успешно, переход на «Принят»
FRAUDREVIEW	На проверке у специалиста Банка	Со стороны ФРОД-анализа получен статус документа «На проверке у специалиста Банка»
FRAUDSENT	Отправлен во ФРОД	Документ отправлен на проверку в АС Fraud-мониторинг
FRAUDSMS	Требуется подтверждение sms-паролем	Со стороны ФРОД-анализа получен статус документа «Требуется подтверждение sms-паролем»
NOT_ACCEPTED_RZK	Не принят СБК	Электронный документ не прошел логические контроли СБК
PARTSIGNED	Частично подписан	ЭД подписан частью подписей, входящих в предусмотренный для данного документа комплект подписей
PROCESSING_RZK	Обрабатывается СБК	ЭД успешно прошел проверки ЭП и логические проверки СБК
REQUESTED_RECALL	Запрошен отзыв	Документ отозван
RZK_SIGN_ERROR	Ошибка ЭП СБК	Проверка подписи под ЭД на стороне СБК дала отрицательный результат
SENDING_TO_RZK	Отправляется в СБК	Электронный документ отправлен в СБК, но не получен квиток о доставке
SIGNED	Подписан	ЭД подписан предусмотренным для него комплектом подписей
TO_PROCESSING_RZK	К отправке в СБК	ЭД подписан предусмотренным для него комплектом о доставке
CHECKERROR	Ошибка контроля	ЭД сформирован, но при сохранении не прошел проверку корректности заполнения полей и сохранен с имеющимися в нем ошибками
Окончательный (Не успешный)/Прекратить опрос
DELETED	Удален	Электронный документа удален из числа действующих документов
INVALIDEDS	ЭП/АСП не верна или Подпись неверна	Проверка ЭП под ЭД на стороне Банка дала отрицательный результат
RECALL	Отозван	Электронный документ был отозван Клиентом по запросу
REFUSEDBYBANK	Отвергнут банком или Отклонен банком	Электронный документ отвергнут банком
REFUSEDBYABS	Отказан АБС	Электронный документ не прошел проверки в АБС
REQUISITEERROR	Ошибка реквизитов	В ЭД указаны ошибочные реквизиты
REFUSED_BY_RZK	Отказан контролирующей организацией	Электронный документ не прошел проверки контролирующей организацией
FRAUDDENY	Отвергнут ФРОД	Документ отказан на основе проверки в АС Fraud-мониторинг, переходим в «Отвергнут банком»
Окончательный (Успешный)/Прекратить опрос
IMPLEMENTED	Исполнен	Электронный документ исполнен Банком