ym88659208ym87991671
Создание рублевого платежного поручения | Документация для разработчиков

Создание рублевого платежного поручения

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

Запрос на создание рублевого платежного поручения (РПП).

Должен содержать токен доступа (access_token) пользователя в параметре Authorization заголовка. В случае использования подписи КЭП ЮЛ, необходимо передавать access_token пользователя, на имя которого выпущен сертификат КЭП ЮЛ.

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

  • Если в запросе на создание платежного документа передать ЭП к документу (объект digestSignatures), то Банк сразу начнет обработку документа.
  • Если в запросе не передавать ЭП к документу, то платежное поручение будет создано в статусе черновик. Для начала обработки документа Банком потребуется зайти в интерфейс СберБизнес и подписать его.
Дайджест

Дайджест это текстовый документ, содержащий перечень и значения полей запроса, к которому он относится и предназначенный для подписания ЭП. Сохраняйте порядок и количество полей дайджеста, как показано в примере ниже, иначе подписать его не получится.

Наименование поляОписание поляПример
amountСумма платежа100.00
dateДата составления документа2018-05-31
departmentalInfo.docNumber108Номер налогового документа(реквизит-108)123
departmentalInfo.drawerStatus101Показатель статуса налогоплательщика(реквизит-101)01
departmentalInfo.kbkКод бюджетной классификации(реквизит-104)18210102010011000110
departmentalInfo.oktmoКод ОКТМО(реквизит-105)1701000
departmentalInfo.paymentKind110Тип налогового платежа(реквизит-110)НС
departmentalInfo.reasonCode106Показатель основания платежа(реквизит-106)ТП
departmentalInfo.uipУникальный идентификатор платежа0
externalIdИдентификатор документа, присвоенный сервисомa0000000-0000-0000-0000-000000000001
incomeTypeCodeКод вида дохода получателей выплаты по 229-ФЗ2
operationCodeКод операции01
payeeAccountНомер счета получателя40702810600100001212
payeeBankBicБИК получателя044525225
payeeBankCorrAccountКорсчет банка получателя30101810400000000225
payeeInnИнн получателя222201236445
payeeKppКпп получателя222201001
payeeNameПолное наименование получателя платежаОбщество с ограниченной ответственностью "Получатель"
payerAccountСчет плательщика40702810500006103990
payerBankBicБИК плательщика044525225
payerBankCorrAccountКорсчет банка плательщика30101810400000000225
payerInnИНН плательщика222201236445
payerKppКПП плательщика222201001
payerNameПолное наименование плательщикаОбщество с ограниченной ответственностью "Клиент"
priorityОчередность платежа5
purposeНазначение платежаОплата интернет заказа №123. НДС нет.
voCodeКод вида валютной операции61150
creditContractNumberНомер кредитного договора2026/33556

Пример:

amount=100.00
date=2018-05-31
departmentalInfo.docNumber108=123
departmentalInfo.drawerStatus101=01
departmentalInfo.kbk=18210102010011000110
departmentalInfo.oktmo=01701000
departmentalInfo.paymentKind110=НС
departmentalInfo.reasonCode106=ТП
departmentalInfo.uip=0
externalId=a0000000-0000-0000-0000-000000000001
incomeTypeCode=2
operationCode=01
payeeAccount=40702810600100001212
payeeBankBic=044525225
payeeBankCorrAccount=30101810400000000225
payeeInn=222201236445
payeeKpp=222201001
payeeName=Общество с ограниченной ответственностью "Получатель"
payerAccount=40702810500006103990
payerBankBic=044525225
payerBankCorrAccount=30101810400000000225
payerInn=222201236445
payerKpp=222201001
payerName=Общество с ограниченной ответственностью "Клиент"
priority=5
purpose=Оплата интернет заказа №123. НДС нет.
voCode=61150
creditContractNumber=2026/33556
Рекомендации по тестированию в песочнице

При тестировании создания рублевого платежного поручения в Песочнице соблюдайте правила:

  • Генерируйте уникальный externalId для каждого документа.
  • Не нужно устанавливать промышленные сертификаты электронной подписи (ЭП) — Песочница использует тестовые идентификаторы ЭП (certificateUuid).
  • Все остальные поля запроса заполняйте произвольными данными (реквизиты, суммы, назначение платежа) в соответствии с требованиями в документации.

Сценарии тестирования

Для тестирования сценариев используйте фиксированные значения certificateUuid. При использовании любых других значений certificateUuid вернется ошибка WORKFLOW_FAULT "Проверьте актуальность сертификата электронной подписи."

Возможны следующие сценарии, при которых платежное поручение в бюджет будет создано:

  • передан полный набор параметров в объекте departmentalInfo;
  • переданы все параметры departmentalInfo, за исключением paymentKind110;
  • в объекте departmentalInfo заполнен только paymentKind110, а остальные поля имеют значение null;
  • объект departmentalInfo передан как null.

1. Чтобы создать неподписанное платежное поручение (черновик), отправьте запрос без объекта digestSignatures.

Статус в ответе: bankStatus: "CREATED"

2. Для отправки документа с единственной подписью передайте в объекте digestSignatures тестовый UUID единоличного исполнительного органа (ЕИО).

Параметры:

  • certificateUuid: bb014b5d-8159-40be-97c1-eafeed4a8c3d

Статус в ответе: bankStatus: "IMPLEMENTED"

Пример:

  "digestSignatures": [
    \{
      "certificateUuid": "bb014b5d-8159-40be-97c1-eafeed4a8c3d",
      "base64Encoded": "MIILDgYJKoZIhvcNAQcCoIIK..."
    \}
  ],

3. Для отправки документа с двумя подписями передайте в объекте digestSignatures тестовые UUID первой И второй подписи.

Параметры:

  • certificateUuid: d5d4f811-f4d4-4205-a70f-58f772eeab72 (Первая подпись)
  • certificateUuid: 4f29c8ef-b55d-43c7-a321-f2b1303a29cd (Вторая подпись)

Статус в ответе: bankStatus: "IMPLEMENTED"

Пример:

  "digestSignatures": [
    \{
      "certificateUuid": "d5d4f811-f4d4-4205-a70f-58f772eeab72",
      "base64Encoded": "MIILDgYJKoZIhvcNAQcCoIIK..."
    \},
    \{
      "certificateUuid": "4f29c8ef-b55d-43c7-a321-f2b1303a29cd",
      "base64Encoded": "MIILDgYJKoZIhvcNAQcCoIIK..."
    \}
  ],

4. Для отправки документа с одной из двух подписей передайте в объекте digestSignatures тестовые UUID первой ИЛИ второй подписи.

Статус в ответе: bankStatus: "PARTSIGNED"

Параметры:

  • certificateUuid: d5d4f811-f4d4-4205-a70f-58f772eeab72 (Первая подпись)
  • certificateUuid: 4f29c8ef-b55d-43c7-a321-f2b1303a29cd (Вторая подпись)

Важно: для получения указанного статуса, передать необходимо только одну подпись.

Пример:

  "digestSignatures": [
    \{
      "certificateUuid": "d5d4f811-f4d4-4205-a70f-58f772eeab72",
      "base64Encoded": "MIILDgYJKoZIhvcNAQcCoIIK..."
    \}
  ],

5. Для отправки документа с УКЭП передайте в объекте digestSignatures тестовый UUID.

Статус в ответе: bankStatus: "IMPLEMENTED"

Параметры:

  • certificateUuid: f47ac10b-58cc-4372-a567-0e02b2c3d479
  • signType: UKEP_UL

6. Если блок departmentalInfo передан некорректно, то метод вернет bankStatus: CHECKERROR и комментарий, в котором будет указано, какое именно поле вызвало ошибку.

Запрос

Ответы

Успешный запрос перевода

Loading...
Это полезный материал?
Заметили ошибку?
Выделите текст и нажмите
Ctrl
+
Enter
, чтобы сообщить нам об ошибке