ym88659208ym87991671
Сервис «Корпоративные подписки» | Документация для разработчиков

Сервис «Корпоративные подписки»

Обновлено 11 октября 2024

Информация о сервисе

Корпоративные подписки – это сервис для организации расчетов с юридическими лицами (ЮЛ) и индивидуальными предпринимателями (ИП), который позволяет получать сведения о подписчиках и безакцептно списывать денежные средства за предоставление услуг или товаров.

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

Платежное требование

Платежное требование - это документ, используемый для безналичных расчетов между юридическими лицами, в котором поставщик предъявляет должнику претензию за неуплату задолженности по договору. Банк на основании этого документа списывает сумму задолженности со счета плательщика в пользу получателя.

Основное различие между платежным требованием и платежным поручением заключается в инициаторе платежа. В платежном поручении инициатором является владелец счета, тогда как в платежном требовании - получатель денег (кредитор, поставщик, продавец или исполнитель услуг). Кредитор оформляет платежное требование и направляет его в банк для исполнения. Часто для выполнения платежного требования требуется акцепт (согласие) плательщика.

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

Другая часть механизма построена на предварительном акцепте (у себя мы его называем Заранее данный акцепт - ЗДА) на списание денежных средств со счета подписчика.


Терминология

  • Заранее данный акцепт (далее по тексту - ЗДА) – временное согласие Клиента на списание денежных средств в счет оплаты предоставленных услуг или товаров по подписке. Наличие Заранее данного акцепта позволяет по запросу от вашей компании Банку списывать средства со счета Клиента без дополнительного согласования.
  • Оформить Подписку – подписать Заявление на Заранее данный акцепт.
  • Исходящее Платежное требование (далее по тексту - ИПТ) – расчетный документ, на основании которого Банк списывает денежные средства со счета Клиента-подписчика.
  • Digest ИПТ – набор значимых полей платежного документа, который подписывается электронной подписью (ЭП).

Схема работы сервиса

Схема работы сервиса

Варианты реализации

В рамках Платформы вы самостоятельно разрабатываете ролевую модель и настраиваете права доступа к функциональности.

Ниже, в качестве примера, приведена диаграмма вариантов использования:

Варианты реализации
Оформление подписки

Для наличия возможности без акцептного списания денежных средств со счета Клиента потребуется получить от него согласие на автоматические списания. Его получить можно при оформлении Подписки пользователем Клиента. Клиент становится подписчиком после заключения договора с вашей компанией или акцепта Оферты вашей Платформы и оформления ЗДА на списание платы за подписку на основании заключенного договора/акцепта Оферты.


Шаги

  1. Сформировать черновик ЗДА
  2. Подписать черновик ЗДА
  3. Проверить статус подписания ЗДА
  4. Проверить подписанный ЗДА

Участники usecase

  • Пользователь - представитель ЮЛ/ИП, от лица которого он работает в рамках вашего сервиса (Платформы)
  • Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
  • Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа

Предварительные условия

  • Пользователь имеет пользовательский профиль в СберБизнес своей компании
  • Пользователь находится в пространстве Платформы
  • Пользователь прошел авторизацию с помощью СберБизнес ID

Результат применения

  • Платформа получила подтверждение оформления Подписки (подписан документ заявление на ЗДА)
Оформление подписки

Используемые запросы

№МетодТочка вызоваОписаниеОперация в scopeШаг в схеме
1Alt text/fintech/api/v1/acceptance-advancesСоздание черновика заявления ЗДАACCEPTANCE_ADVANCE1. Сформировать черновик ЗДА
2Alt text/ic/sso/api/v2/oauth/tokenОбновление токена доступаopenid1. Сформировать черновик ЗДА
3Alt text/fintech/api/v1/acceptance-advances/{externalId}/stateПолучение статуса заявления ЗДАACCEPTANCE_ADVANCE3. Проверить статус подписания ЗДА
4Alt text/fintech/api/v1/acceptance-advances/{externalId}Получение заявления ЗДАACCEPTANCE_ADVANCE4. Проверить подписанный ЗДА
Списание платы за подписку

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

Например, Пользователь Клиента оформил Подписку 15 января. На следующий день, 16 января, можно будет сформировать платежное требование для списания денежных средств. Если сформировать платежное требование в день оформления Подписки, то платежное требование исполнено не будет - оно встанет в "Картотеку" в СберБизнес Клиента на ручное подтверждение.


В схеме можно использовать автоматизированное подписание документа. Данная возможность доступна только при использовании ЭЦП сотрудника вашей компании.

Подробнее об использовании ЭЦП в Sber API можно почитать в одноименном разделе.


Шаги

  1. Проверить актуальность подписки
  2. Создать и подписать ИПТ

Участники usecase

  • Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
  • Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа

Предварительные условия

  • Успешно выполнен сценарий "Оформление подписки"
  • Платформа сохранила идентификатор (extertalId) заявления на ЗДА, созданного в сценарии "Оформление подписки"
  • У Платформы есть access_token пользователя вашей компании

Результат применения

  • Платформа создала ИПТ
Списание платы за подписку

Используемые запросы

№МетодТочка вызоваОписаниеОперация в scopeШаг в схеме
1Alt text/fintech/api/v1/acceptance-advances/{externalId}/stateПолучение статуса заявления ЗДАACCEPTANCE_ADVANCE1. Проверить актуальность подписки
2Alt text/ic/sso/api/v2/oauth/tokenОбновление токена доступаopenid1. Проверить актуальность подписки
и
2. Создать и подписать ИПТ
3Alt text/fintech/api/v1/payment-requests/outgoingСоздание платежного требованияPAYMENT_REQUEST_OUT2. Создать и подписать ИПТ
Проверка статуса оплаты

Шаги

  1. Проверить статус оплаты

Участники usecase

  • Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
  • Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа

Предварительные условия

  • Успешно выполнен сценарий "Списание платы за подписку"
  • Платформа сохранила идентификатор (extertalId) ИПТ, созданного в сценарии "Списание платы за подписку"
  • У Платформы есть access_token пользователя вашей компании

Результат применения

  • ИПТ исполнено Банком
Проверка статуса оплаты

Используемые запросы

№МетодТочка вызоваОписаниеОперация в scopeШаг в схеме
1Alt text/fintech/api/v1/payment-requests/outgoing/{externalId}/stateПолучение статуса платежного требованияPAYMENT_REQUEST_OUT1. Проверить статус оплаты
2Alt text/ic/sso/api/v2/oauth/tokenОбновление токена доступаopenid1. Проверить статус оплаты

Переадресация на заявление ЗДА

Для начала обработки заявления на ЗДА Банком оно должно быть подписано. При создании документа с помощью запроса API, документ также появляется в клиентской части СберБизнес Пользователя.

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

Ссылка переадресации выглядит следующим образом:

{контур банка}/ic/ufs/advance-acceptance/index.html#/advance-acceptance-creator/{externalId}?backUrl={backUrl}

ПеременнаяОписаниеДополнительная информация
{контур Банка}адрес Банка, на который делается запрос для открытия страницы сервиса подписания заявленияДля корректного выбора контура Банка потребуется определить тип криптопрофиля пользователя Клиента.
В рамках запроса /v1/oauth/user-info вы получаете данные по Клиенту, в том числе атрибут userCryptoType.
Атрибут позволяет определить криптопрофиль пользователя - SMS (СМС) или Token (электронный ключ (токен)).

- Тестовый контур https://efs-sbbol-ift-web.testsbi.sberbank.ru:9443
- Промышленный контур СМС-пользователь https://sbi.sberbank.ru:9443
- Промышленный контур Токен-пользователь http://localhost:28016
{externalId}уникальный идентификатор заявленияДанный идентификатор присваивает ваша Платформа на шаге создания черновика заявления на ЗДА
{backUrl}страница возврата, на которую Банк вернет пользователя Клиента после успешного подписания черновика заявления- backUrl нужно закодировать URLEncode;
- Если не указать backUrl в ссылке, пользователи не смогут после подписания вернуться на Платформу;
- Если backUrl будет отличаться от адреса вашей платформы, который указали при регистрации в Банке, то при возврате клиента на backUrl он будет видеть ошибку.

Создание черновика заявления ЗДА

Alt text /fintech/api/v1/acceptance-advances

Ресурс позволяет создать черновик заявления на заранее данный акцепт.

Для создания черновика заранее данного акцепта необходимо отправить POST-запрос /fintech/api/v1/acceptance-advances с токеном доступа (access_token) пользователя в параметре Authorization заголовка и реквизитами документа в теле запросе.

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


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

  • Тестовый контур https://iftfintech.testsbi.sberbank.ru:9443
  • Промышленный контур https://fintech.sberbank.ru:9443

Request

/fintech/api/v1/acceptance-advances
НаименованиеТипФорматRegexpОбязательностьОписание
HEADER
Authorizationstringstring^[a-zA-Z0-9]{38}$requiredAccess token пользователя, полученный через SSO.
Content-Typestringstring^(application/json|text/plain|application/xml|multipart/form-data|application/x-www-form-urlencoded)$requiredТип данных, которые передаются в теле запроса.

Должен содержать значение application/json.
BODY
AcceptanceAdvance {
 acceptLastDatestringISO 8601
YYYY-MM-DD		^[0-9]{4}-[0-9]{2}-[0-9]{2}$optionalДата окончания периода действия ЗДА.

Если поле оставить незаполненным, то будет создаваться черновик заявления на выпуск бессрочного ЗДА,
 acceptStartDatestringISO 8601
YYYY-MM-DD		^[0-9]{4}-[0-9]{2}-[0-9]{2}$requiredДата начала периода действия ЗДА,
 contractDatestringISO 8601 YYYY-MM-DD^[0-9]{4}-[0-9]{2}-[0-9]{2}$requiredДата заключения договора, на основании которого в дальнейшем Клиенту выставляется ИПТ,
 contractNumberstringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]{1,40}$requiredНомер договора, на основании которого в дальнейшем Клиенту выставляется ИПТ,
 datestringISO 8601 YYYY-MM-DD^[0-9]{4}-[0-9]{2}-[0-9]{2}$requiredДата составления документа,
 externalIdstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredИдентификатор документа, присвоенный вами,
 numberstringstring^[0-9]{1,6}$requiredНомер документа,
 obligationstringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]{1,50}$optionalПредмет договора,
 payeeAccountstringstring^[0-9]{20}$requiredСчет получателя,
 payeeBankBicstringstring^[0-9]{9}$optionalБИК получателя,
 payeeInnstringstring^([0-9]{5}|[0-9]{10}|[0-9]{12}|0)$optionalИНН получателя,
 payeeNamestringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]+$optionalНаименование получателя,
 payerAccountstringstring^[0-9]{20}$optionalСчет плательщика,
 payerBicstringstring^[0-9]{9}$optionalБИК плательщика,
 payerInnstringstring^([0-9]{5}|[0-9]{10}|[0-9]{12}|0)$optionalИНН плательщика,
 payerNamestringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]+$optionalНаименование плательщика
}

Responses

201 (Сreated)
НаименованиеТипОбязательностьОписание
AcceptanceAdvance {
 acceptLastDatestringoptionalДата окончания периода действия ЗДА,
 acceptStartDatestringrequiredДата начала периода действия ЗДА,
 bankCommentstringoptionalРасшифровка статуса обработки,
 bankStatusstringoptionalСтатус обработки,
 contractDatestringrequiredДата договора,
 contractNumberstringrequiredНомер договора,
 datestringrequiredДата документа,
 externalIdstringrequiredИдентификатор документа, присвоенный партнером,
 numberstringrequiredНомер документа,
 obligationstringoptionalПредмет договора,
 payeeAccountstringrequiredСчет получателя,
 payeeBankBicstringoptionalБИК получателя,
 payeeInnstringoptionalИНН получателя,
 payeeNamestringoptionalНаименование получателя,
 payerAccountstringoptionalСчет плательщика,
 payerBicstringoptionalБИК плательщика,
 payerInnstringoptionalИНН плательщика,
 payerNamestringoptionalНаименование плательщика
}
400 (Bad request)
CauseMessageDescription
DESERIALIZATION_FAULTНеверный формат запросаДанные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request ресурса. Скорректируйте заполнение атрибутов и повторите запрос.
WORKFLOW_FAULTДокумент с таким externalId уже существует в системеИспользуется externalId, который уже есть в системе (дубль). Сгенерируйте новый externalId и повторите запрос.
Неизвестный счет плательщика: {payerAccount}
Неизвестный счет получателя: {accountNumber}
Отсутствует доступный открытый рублевый расчетный счетОшибка может возникнуть если:
1. Указан не расчетный счет (например, транзитный)
2. Указан валютный счет
3. Указан счет для гособоронзаказа
4. Указан счет ТСЖ
Счет закрыт: {accountNumber}
Счет заблокирован: {accountNumber}
Введен некорректный ИНН получателя
Введен некорректный ИНН плательщика
БИК банка получателя не соответствует БИК привязанного к счету получателя
БИК банка плательщика не соответствует БИК привязанного к счету плательщика
VALIDATION_FAULTОбъект AcceptanceAdvance не соответствует моделиДанные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request ресурса, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
401 (Unauthorized Error)
CauseMessageDescription
UNAUTHORIZEDaccessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-хУказан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
403 (Forbidden)
CauseMessageDescription
ACTION_ACCESS_EXCEPTIONОперация не может быть выполнена: доступ к ресурсу запрещенИспользуемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API.
В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция ACCEPTANCE_ADVANCE. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
415 (Unsupported Media Type)
CauseMessageDescription
Отсутствует параметр Content-type в header запроса
В параметре Content-type установлено значение, отличное от application/json
НаименованиеТипОбязательностьОписание
Отсутствует
500 (Internal Server Error)
CauseMessageDescription
UNKNOWN_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
503 (Service Temporarily Unavailable)
CauseMessageDescription
UNAVAILABLE_RESOURCE_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}

Получение статуса заявления ЗДА

Alt text /fintech/api/v1/acceptance-advances/{externalId}/state

Ресурс позволяет получить актуальный статус заявления на заранее данный акцепт.

Для получения статуса заявления на заранее данный акцепт необходимо отправить GET-запрос /fintech/api/v1/acceptance-advances/{externalId}/state с токеном доступа (access_token) пользователя в параметре Authorization заголовка и идентификатором документа (externalId) в path-параметре.

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


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

  • Тестовый контур https://iftfintech.testsbi.sberbank.ru:9443
  • Промышленный контур https://fintech.sberbank.ru:9443

Request

/fintech/api/v1/acceptance-advances/{externalId}/state
НаименованиеТипФорматRegexpОбязательностьОписание
HEADER
Authorizationstringstring^[a-zA-Z0-9]{38}$requiredAccess token пользователя, полученный через SSO.
PATH PARAMETERS
externalIdstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredИдентификатор документа, присвоенный вами при создании заявления на ЗДА

Responses

200 (OK)
НаименованиеТипОбязательностьОписание
PaymentDocState {
 bankCommentstringoptionalБанковский комментарий к статусу документа,
 bankStatusstringoptionalСтатус документа
}
400 (Bad request)
CauseMessageDescription
DESERIALIZATION_FAULTНеверный формат запросаДанные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request ресурса. Скорректируйте заполнение атрибутов и повторите запрос.
VALIDATION_FAULTОшибка валидацииДанные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request ресурса, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
401 (Unauthorized Error)
CauseMessageDescription
UNAUTHORIZEDaccessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-хУказан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
403 (Forbidden)
CauseMessageDescription
ACTION_ACCESS_EXCEPTIONОперация не может быть выполнена: доступ к ресурсу запрещенИспользуемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API.
В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция ACCEPTANCE_ADVANCE. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
404 (Not found)
CauseMessageDescription
NOT_FOUNDДокумент с указанным ID не найден
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
500 (Internal Server Error)
CauseMessageDescription
UNKNOWN_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
503 (Service Temporarily Unavailable)
CauseMessageDescription
UNAVAILABLE_RESOURCE_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}

Статусы заявления ЗДА

bankStatus (string)
Код статусаНаименованиеКомментарий
Промежуточный/Продолжать опрашивать
CREATEDСозданДокумент создан и прошел первичный контроль на КЧ.
DELETEDУдаленДокумент удален Пользователем
PARTSIGNEDЧастично подписанДокумент подписан не полным набором подписей.
SIGNEDПодписанДокумент подписан полным набором подписей.
ACCEPTEDПринятДокумент принят на стороне банка
ACCEPTED_BY_ABSПринят АБСДокумент принят АБС Банка.
REFUSEDBYABSОтказан АБСДокумент отказан АБС Банка.
REFUSEDBYBANKОтвергнут банкомДокумент отказан сотрудником Банка по результатам ручной обработки.
REQUISITEERRORОшибка реквизитовВ процессе контроля в АБС Банка обнаружены ошибки в реквизитах документа.
INVALIDEDSЭП/АСП не вернаВ процессе контроля в АБС Банка обнаружена ошибка подписи документа.
Окончательный (Успешный)/Прекратить опрос
IMPLEMENTEDИсполнен1. Документ исполнен Банком. В ЕКС создано Распоряжение на ЗДА.
(для заявления на заранее данный акцепт)2. Документ исполнен Банком. Есть связанное заявление на отмену действия ЗДА.
Окончательный (Не успешный)/Прекратить опрос
ACCEPTEXPIREИстек срок акцептаИстек срок действия заранее данного акцепта.
RECALLОтозванДата отмены действия ЗДА меньше (раньше) или равна текущей дате. Заранее данный акцепт (Распоряжение) отменен.
CHECKERRORОшибка контроляПри прохождении контролей на КЧ, в процессе сохранения, обнаружены ошибки.

Получение заявления ЗДА

Alt text /fintech/api/v1/acceptance-advances/{externalId}

Ресурс позволяет получить полные данные заявления на заранее данный акцепт.

Для получения данных заявления на заранее данный акцепт необходимо отправить GET-запрос /fintech/api/v1/acceptance-advances/{externalId} с токеном доступа (access_token) пользователя в параметре Authorization заголовка и идентификатором документа (externalId) в path-параметре.

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


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

  • Тестовый контур https://iftfintech.testsbi.sberbank.ru:9443
  • Промышленный контур https://fintech.sberbank.ru:9443

Request

/fintech/api/v1/acceptance-advances/{externalId}
НаименованиеТипФорматRegexpОбязательностьОписание
HEADER
Authorizationstringstring^[a-zA-Z0-9]{38}$requiredAccess token пользователя, полученный через SSO.
PATH PARAMETERS
externalIdstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredИдентификатор документа, присвоенный вами при создании заявления на ЗДА

Responses

200 (OK)
НаименованиеТипОбязательностьОписание
AcceptanceAdvance {
 acceptLastDatestringoptionalДата окончания периода действия ЗДА,
 acceptStartDatestringrequiredДата начала периода действия ЗДА,
 bankCommentstringoptionalРасшифровка статуса обработки,
 bankStatusstringoptionalСтатус обработки,
 contractDatestringrequiredДата договора,
 contractNumberstringrequiredНомер договора,
 datestringrequiredДата документа,
 externalIdstringrequiredИдентификатор документа, присвоенный партнером,
 numberstringrequiredНомер документа,
 obligationstringoptionalПредмет договора,
 payeeAccountstringrequiredСчет получателя,
 payeeBankBicstringoptionalБИК банка получателя,
 payerCorrAccstringoptionalКорсчет банка получателя платежа,
 payeeInnstringoptionalИНН получателя,
 payeeNamestringoptionalНаименование получателя,
 payerAccountstringoptionalСчет плательщика,
 payerBicstringoptionalБИК плательщика,
 payerInnstringoptionalИНН плательщика,
 payerNamestringoptionalНаименование плательщика
}
400 (Bad request)
CauseMessageDescription
DESERIALIZATION_FAULTНеверный формат запросаДанные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request ресурса. Скорректируйте заполнение атрибутов и повторите запрос.
VALIDATION_FAULTОшибка валидацииДанные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request ресурса, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
401 (Unauthorized Error)
CauseMessageDescription
UNAUTHORIZEDaccessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-хУказан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
403 (Forbidden)
CauseMessageDescription
ACTION_ACCESS_EXCEPTIONОперация не может быть выполнена: доступ к ресурсу запрещенИспользуемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API.
В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция ACCEPTANCE_ADVANCE. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
404 (Not found)
CauseMessageDescription
NOT_FOUNDДокумент с указанным ID не найден
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
500 (Internal Server Error)
CauseMessageDescription
UNKNOWN_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
503 (Service Temporarily Unavailable)
CauseMessageDescription
UNAVAILABLE_RESOURCE_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}

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

ВАЖНО!

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

Например, Клиент оформил Подписку 15 января. На следующий день, 16 января, можно будет сформировать платежное требование для списания денежных средств. Если сформировать платежное требование в день оформления Подписки, то платежное требование не будет исполнено - оно встанет в "Картотеку" в СберБизнес Клиента на ручное подтверждение.

Alt text /fintech/api/v1/payment-requests/outgoing

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

Для создания платежного требования необходимо отправить POST-запрос /fintech/api/v1/payment-requests/outgoing с токеном доступа (access_token) пользователя собственной организации в параметре Authorization заголовка и реквизитами платежного требования в теле запросе.

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


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

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


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

  • Тестовый контур https://iftfintech.testsbi.sberbank.ru:9443
  • Промышленный контур https://fintech.sberbank.ru:9443

Request

/fintech/api/v1/payment-requests/outgoing
НаименованиеТипФорматRegexpОбязательностьОписание
HEADER
Authorizationstringstring^[a-zA-Z0-9]{38}$requiredAccess token пользователя, полученный через SSO.
BODY
PaymentRequestOut {
 acceptanceTermstringstring^[1-5]{1}$optionalСрок для акцепта (поле 36). Указывается количество дней для получения акцепта плательщика,
 amountnumberfloat^[0-9]+(.[0-9]+)?$requiredСумма платежа,
 datestringISO 8601 YYYY-MM-DD^(\d{4})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$requiredДата составления документа,
 deliveryKindstringstring^(электронно|срочно|0)$optionalВид платежа: электронно, срочно
Если не заполнено или 0, то будет присвоено значение "электронно",
 digestSignaturesarray[Signature]array[object]optionalЭлектронные подписи по дайджесту документа.

Если ЭП передана/ы в API, то они сохраняются вместе с документом, а сам документ продвигается дальше по своему жизненному циклу.

Если ЭП не была/и передана/ы, то документ сохраняется в своем начальном статусе и ожидает дальнейшего подписания в интерфейсе СберБизнес.

О подписании дайджеста платежного документа подробно рассказали в соответствующем разделе документации
 externalIdstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredИдентификатор документа, присвоенный партнером,
 numberstringstring^[0-9]$optionalНомер документа,
 operationCodestringstring^02$requiredКод операции,
 payeeAccountstringstring^[0-9]$requiredСчет получателя платежа,
 payeeBankBicstringstring^[0-9]{9}$requiredБИК получателя платежа,
 payeeBankCorrAccountstringstring^[0-9]{20}$requiredКорсчет банка получателя платежа,
 payeeInnstringstring^([0-9]{5}|[0-9]{10}|[0-9]{12}|0)$optionalИНН получателя платежа,
 payeeNamestringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]+$requiredПолное наименование получателя платежа,
 payerAccountstringstring^[0-9]{20}$requiredСчет плательщика,
 payerBankBicstringstring^[0-9]{9}$requiredБИК банка плательщика,
 payerBankCorrAccountstringstring^[0-9]{20}$requiredКорсчет банка плательщика,
 payerInnstringstring^([0-9]{5}|[0-9]{10}|[0-9]{12}|0)$requiredИНН плательщика,
 payerNamestringstring^[0-9a-zA-Zа-яА-ЯеЁ \t]+$requiredПолное наименование плательщика,
 paymentConditionstringstring^(1|2)$requiredУсловие оплаты (поле 35).

Указывается цифра "1" - заранее данный акцепт плательщика или цифра "2" - требуется получение акцепта плательщика,
 prioritystringstring^[1-5]{1}$requiredОчередность платежа,
 purposestringstring^.{0,210}$requiredНазначение платежа.

Рекомендации по заполнению
 vatVatobjectrequiredДанные НДС,
 voCodestringstring^[0-9]{5}$requiredКод вида валютной операции
}
Signature {
 base64Encodedstringbase64^[a-zA-Z0-9]+$requiredЗначение электронной подписи, закодированное в Base64,
 certificateUuidstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredУникальный идентификатор сертификата ключа проверки электронной подписи
}
Vat {
 amountnumberfloat^[0-9]+(.[0-9]+)?$optionalСумма НДС,
 ratestringstring^[0-9]{0,2}$optionalСтавка НДС,
 typestringstring^(INCLUDED|NO_VAT|MANUAL)$requiredСпособ расчета НДС.

INCLUDED - НДС включен в сумму платежа
NO_VAT - не облагается НДС
MANUAL - ручной ввод НДС
}

digestSignatures

Формат дайджеста
Наименование поляОписание поляПример
acceptanceTermСрок акцепта5
amountСумма платежа100.01
dateДата составления документа31.12.2018
externalIdИдентификатор документа, присвоенный сервисом22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6
operationCodeКод операции02
payeeAccountНомер счета получателя40802810600000200000
payeeBankBicБИК получателя044525225
payeeBankCorrAccountКорсчет банка получателя30101810400000000225
payeeInnИНН получателя0452566242
payeeNameПолное наименование получателя платежаОбщество с ограниченной ответственностью "Получатель"
payerAccountСчет плательщика40802810600000200000
payerBankBicБИК плательщика044525225
payerBankCorrAccountКорсчет банка плательщика30101810400000000225
payerInnИНН плательщика8554122325
payerNameПолное наименование плательщикаОбщество с ограниченной ответственностью "Клиент"
paymentConditionУсловие оплаты (1/2)1
priorityОчередность платежа5
purposeНазначение платежаОплата по договору №123 от 13.04.2024. НДС 20% - 20.00 рублей включен в сумму.

Responses

201 (Created)
НаименованиеТипОбязательностьОписание
PaymentRequestOut {
 acceptanceTermstringoptionalСрок для акцепта (поле 36). Указывается количество дней для получения акцепта плательщика,
 amountnumberrequiredСумма платежа,
 bankCommentstringoptionalБанковский комментарий к статусу документа,
 bankStatusstringoptionalСтатус документа,
 crucialFieldsHashstringoptionalHash от ключевых полей документа,
 datestringrequiredДата составления документа,
 deliveryKindstringoptionalВид платежа: электронно, срочно
Если не заполнено или 0, то будет присвоено значение "электронно",
 digestSignaturesarray[Signature]optionalЭлектронные подписи по дайджесту документа,
 externalIdstringrequiredИдентификатор документа, присвоенный партнером,
 numberstringoptionalНомер документа,
 operationCodestringrequiredКод операции,
 payeeAccountstringrequiredСчет получателя платежа,
 payeeBankBicstringrequiredБИК получателя платежа,
 payeeBankCorrAccountstringrequiredКорсчет банка получателя платежа,
 payeeInnstringoptionalИНН получателя платежа,
 payeeNamestringrequiredПолное наименование получателя платежа,
 payerAccountstringrequiredСчет плательщика,
 payerBankBicstringrequiredБИК банка плательщика,
 payerBankCorrAccountstringrequiredКорсчет банка плательщика,
 payerInnstringrequiredИНН плательщика,
 payerNamestringrequiredПолное наименование плательщика,
 paymentConditionstringrequiredУсловие оплаты (поле 35),
 prioritystringrequiredОчередность платежа,
 purposestringrequiredНазначение платежа,
 vatVatrequiredДанные НДС,
 voCodestringrequiredКод вида валютной операции
}
Signature {
 base64EncodedstringoptionalЗначение электронной подписи (ЭП), закодированное в Base64,
 certificateUuidstringoptionalУникальный идентификатор сертификата ключа проверки электронной подписи
}
Vat {
 amountnumberoptionalСумма НДС,
 ratestringoptionalСтавка НДС,
 typestringrequiredСпособ расчета НДС
}
202 (Accepted)
CauseMessageDescription
WORKFLOW_FAULTДокумент сохранен, но обработка ЭП или принятие документа завершились ошибкой. ЭП не может быть принятаНеизвестный идентификатор сертификата. Проверьте корректность отправленной ЭП в запросе.
Возможно, была отправлена ЭП с типом "Первая подпись" или "Вторая подпись". Для случаев, когда используется ЭП подписантов с типом "Первая подпись" или "Вторая подпись" для принятия документа в обработку требуется передать в запросе данные обеих подписей.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
400 (Bad request)
CauseMessageDescription
DESERIALIZATION_FAULTНеверный формат запросаДанные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request ресурса. Скорректируйте заполнение атрибутов и повторите запрос.
WORKFLOW_FAULTНевозможно идентифицировать организацию плательщикаПроверьте корректность указанных реквизитов плательщика.
Невозможно идентифицировать банк получателя по указанным номеру БИК и корреспондентскому счетуПроверьте корректность указанных реквизитов получателя платежа - атрибуты payeeBankBic и payeeBankCorrAccount
Документ с таким externalId уже существует в системеИспользуется externalId, который уже есть в системе (дубль). Сгенерируйте новый externalId и повторите запрос.
VALIDATION_FAULTОшибка валидацииДанные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request ресурса, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
401 (Unauthorized Error)
CauseMessageDescription
UNAUTHORIZEDaccessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-хУказан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
403 (Forbidden)
CauseMessageDescription
ACTION_ACCESS_EXCEPTIONОперация не может быть выполнена: доступ к ресурсу запрещенИспользуемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API.
В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция PAYMENT_REQUEST_OUT. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
500 (Internal Server Error)
CauseMessageDescription
UNKNOWN_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
503 (Service Temporarily Unavailable)
CauseMessageDescription
UNAVAILABLE_RESOURCE_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}

Получение статуса платежного требования

Alt text /fintech/api/v1/payment-requests/outgoing/{externalId}/state

Ресурс позволяет получить статус ранее отправленного платежного требования.

Для получения статуса необходимо отправить GET-запрос /fintech/api/v1/payment-requests/outgoing/{externalId}/state с токеном доступа (access_token) пользователя собственной организации в параметре Authorization заголовка и идентификатор документа (externalId) в query-параметре запроса.

В параметре scope ссылки авторизации пользователя вашей компании должен быть указан сервис PAYMENT_REQUEST_OUT для получения доступа к этому ресурсу.


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

  • Тестовый контур https://iftfintech.testsbi.sberbank.ru:9443
  • Промышленный контур https://fintech.sberbank.ru:9443

Request

/fintech/api/v1/payment-requests/outgoing/{externalId}/state
НаименованиеТипФорматRegexpОбязательностьОписание
HEADER
Authorizationstringstring^[a-zA-Z0-9]{38}$requiredAccess token пользователя, полученный через SSO.
PATH PARAMETERS
externalIdstringUUID^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$requiredИдентификатор документа, присвоенный вами при создании исходящего платежного требования

Responses

200 (OK)
НаименованиеТипОбязательностьОписание
PaymentDocState {
 bankCommentstringoptionalБанковский комментарий к статусу документа,
 bankStatusstringoptionalСтатус документа,
 channelInfostringoptionalКомментарий, специфичный для документа, полученного по данному каналу,
 crucialFieldsHashstringoptionalHash от ключевых полей документа
}
400 (Bad request)
CauseMessageDescription
DESERIALIZATION_FAULTНеверный формат запросаДанные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request ресурса. Скорректируйте заполнение атрибутов и повторите запрос.
VALIDATION_FAULTОшибка валидацииДанные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request ресурса, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.
НаименованиеТипОбязательностьОписание
ResourceFault {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки (UUID),
 messagestringoptionalСообщение,
 checksarray[Check]optionalСписок проверок, приведших к ошибке,
 fieldNamesarray[string]optionalНазвания полей с некорректным значением (только для VALIDATION_FAULT)
}
Check {
 levelstringoptionalУровень результата = ['ERROR', 'WARNING'],
 messagestringoptionalСообщение,
 fieldsarray[string]optionalНазвания полей (при наличии связи с моделью)
}
401 (Unauthorized Error)
CauseMessageDescription
UNAUTHORIZEDaccessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-хУказан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
403 (Forbidden)
CauseMessageDescription
ACTION_ACCESS_EXCEPTIONОперация не может быть выполнена: доступ к ресурсу запрещенИспользуемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API.
В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция PAYMENT_REQUEST_OUT. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
404 (Not found)
CauseMessageDescription
NOT_FOUNDДокумент с указанным ID не найден
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
500 (Internal Server Error)
CauseMessageDescription
UNKNOWN_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}
503 (Service Temporarily Unavailable)
CauseMessageDescription
UNAVAILABLE_RESOURCE_EXCEPTIONВнутренняя ошибка сервераСделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.
НаименованиеТипОбязательностьОписание
Notice {
 causestringoptionalПричина или основание сообщения,
 referenceIdstringoptionalУникальный идентификатор ошибки,
 messagestringoptionalСообщение,
}

Статусы платежных требований

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

Дополнительная информация

Назначение платежа

Назначение должно раскрывать экономический смысл платежа.

  • Сведения должны быть лаконичными — у поля есть ограничения по знакам 210 символов.
  • В назначении необходимо указать реквизиты документа, по которому вы осуществляете платеж, например, номер договора или счета.
  • Рекомендуем указывать конкретный предмет оплаты.
  • Если платеж с НДС, необходимо прописать точную сумму налога.
    Ниже подробнее рассказали о формировании информации об НДС в назначении платежа.

Рекомендуемый вариант заполнения:

Оплата по договору [номер договора] от [дата договора]. НДС [ставка НДС]% - [сумма НДС] рубля [способ расчета НДС]. [Любая ваша информация]

При создании ИПТ с помощью ресурса /fintech/api/v1/payment-requests/outgoing в рамках сервиса Корпоративные подписки

  • Где [номер договора] соответствует contractNumber, который указывали при формировании заявления на ЗДА с помощью ресурса /fintech/api/v1/acceptance-advances
  • Где [дата договора] это дата в формате DD.MM.YYYY (ГОСТ Р 7.0.97-2016 (п. 5.10)), совпадающая с датой указанной в атрибуте contractDate при формировании заявления на ЗДА с помощью ресурса /fintech/api/v1/acceptance-advances.
  • [ставка НДС], [сумма НДС] и [способ расчета НДС] вы указываете в объекте vat (НДС).
  • Если необходимо дополнить назначение, поставьте точку после блока с НДС и укажите свою информацию

Параметры НДС

Чтобы все работало правильно, нужно передать такие параметры:

  • Если НДС не указан, то по умолчанию будут использованы эти значения:
    "vat": {
      "type": "NO_VAT",
      "rate": "0",
      "amount": "0.00"
    }
    Важно: в поле «Назначение платежа» обязательно укажите НДС не облагается.
  • Если выбрали «type» — INCLUDED (НДС включен в сумму платежа), то в поле «amount» укажите сумму НДС. Значение «rate» должно быть 10 или 20. В поле «Назначение платежа» обязательно укажите посчитанную сумму НДС. Пример правильного заполнения: НДС 10% — 100.63 рубля (пробел обозначается нижним подчеркиванием, символ не ставится). Если процентное значение не указано, то дефис перед суммой ставить не нужно: НДС 100.63 рубля.
  • Если выбрали «type» — MANUAL (ввод НДС вручную), то поле «amount» заполнять необязательно, но по умолчанию сумма НДС будет равна нулю. Если же поле «amount» заполнено, то укажите нужную сумму НДС в соответствии с форматом. Если процентное значение не указано, то дефис перед суммой ставить не нужно: НДС 100.63 рубля.

FAQ

Будет ли исполнено Банком платежное требование , отправленное выходные или праздничные дни?

В выходные и праздничные дни платежи исполняются, если вы подключили расширенный режима счета. В него входят:

  • переводы на счета корпоративных клиентов и физических лиц внутри ПАО Сбербанк;
  • переводы в пользу контрагентов в других банках (в том числе в бюджет и на счета физических лиц);
  • переводы на основании документов, ранее помещенных в очередь не исполненных в срок распоряжений к банковскому счету клиента в пользу контрагентов (корпоративных клиентов и физических лиц) внутри ПАО Сбербанк (в том числе оплата задолженности, возникшей по комиссиям банка), а также в другие банки. Инструкция по подключению и отключению расширенного режима счета на странице помощи СберБизнеса.
Что происходит если денежных средств на счете клиента недостаточно?

В случае недостатка денежных средств на счете клиента для оплаты, платежное требование подлежит частичному исполнению (в сумме доступного остатка по банковскому счету плательщика), далее платежное требование помещается в очередь неисполненных в срок распоряжений и исполняется по мере поступления денежных средств в порядке очередности, установленной законодательством РФ. В данном случае вы получите промежуточный статус по платежному требованию CARD2 («Картотека»).
Необходимо продолжать спрашивать статус по платежному требованию до момента получения конечного статуса IMPLEMENTED («Исполнен»). Создавать новое платежное поручение и отправлять повторно Клиенту не требуется.

Может ли клиент отключить подписку?

Клиент может отменить подписку в СберБизнесе, отозвав согласие на заранее данный акцепт. В таком случае при вызове ресурса /fintech/api/v1/partner-info/advance-acceptances в поле "active" вы получите значение "false".

ПАО Сбербанк использует cookie для персонализации сервисов и удобства пользователей.
Вы можете запретить сохранение cookie в настройках своего браузера.