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

Обновлено 12 сентября 2024

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

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

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

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

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

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

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

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

До начала разработки интеграции с сервисом потребуется:

Заключить договор с Банком на использование сервиса "Корпоративные подписки".
Завершить интеграцию со СберБизнес ID.
Без сервиса СберБизнес ID настроить работу "Корпоративные подписки" невозможно.
Направить ссылку на вашу оферту в Банк на почту supportdbo2@sberbank.ru. Оферта должна включать условия предоставления услуг или продажи товаров по подписке.

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

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

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

Графическое описание
Текстовое описание

Шаг	Что делаем	Подробности
1	Предложите Клиенту стать подписчиком	Шаг реализуется с помощью СберБизнес ID - в рамках процесса авторизации через СберБизнес ID появляется шаг подписания Заявления на подключение подписки. - Подробно о подключении сервиса СберБизнес ID рассказали в соответствующем разделе документации. - О вариантах авторизации с помощью СберБизнес ID в рамках сервиса "Корпоративные подписки" рассказали ниже (см. информацию в спойлере "Оформить подписку" в следующем разделе).
2	Получите access_token вашей организации	Организуйте процесс получения access_token вашей организации. Он вам потребуется для использования методов сервиса "Корпоративные подписки".
3	Проверьте наличие подписки у Клиента	С помощью метода `/v1/partner-info/advance-acceptances` получите информацию о клиентах, которые подписались или отписались на запрашиваемую дату. Информация из запроса позволит вам получить реквизиты для списания денежных средств и спланировать оплаты по Клиентам-подписчикам.
4	Создайте исходящее платежное требование в адрес подписчика	С помощью метода `/v1/payment-requests/outgoing` необходимо сформировать и отправить в Банк платежные требования по подписчикам, которым в соответствие с условиями вашей работы необходимо произвести оплату за товары или услуги по подписке.
5	Получите статус платежного требования	С помощью метода `/v1/payment-requests/outgoing/{externalId}/state` вы получите статус платежного требования. Вы можете разработать механизм проверки статуса оплаты и реакцию Платформы на каждый из статусов.

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

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

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

Предложите Клиенту оформить Подписку

Оформить подписку

Для наличия возможности безакцептного списания денежных средств со счета Клиента потребуется получить от него согласие на такие списания. Такое согласие можно получить при оформлении Подписки Клиентом.

Клиент становится подписчиком после подписания Заявления на подключение подписки (далее по тексту - оформить Подписку). Для оформления Подписки используется сервис "СберБизнес ID": на Платформе необходимо организовать клиентский путь через СберБизнес ID.

Есть 2 варианта организации клиентского пути:

Вариант 1
Вариант 2

Сценарий	Клиент авторизуется с помощью СберБизнес ID, через некоторое время выбирает тариф и оформляет Подписку
Особенности	Клиент авторизуется с помощью СберБизнес ID - Платформа получает всю информацию о Клиенте, при этом он еще НЕ подписчик. Спустя некоторое время Клиент выбирает тариф подписки - оформляет Подписку, Платформа получает информацию о счете и разрешение на безакцептное списание.
Когда актуально	- У вас есть бесплатный пробный период - Предусмотрена бесплатная функциональность для авторизованных пользователей Платформы
Что следует учесть	Доступы параметра scope в рамках сервиса "Корпоративные подписки" работают на расширение. Платформа должна "узнавать" клиентов-подписчиков при повторном посещении. Если такой механизм не предусмотрен, то Клиенту-подписчику потребуется повторно пройти авторизацию и оформить Подписку.

Используемые методы

№	Точка вызова	Описание	Операция в scope
1	`/v2/oauth/authorize`	Получение кода авторизации	openid
2	`/v2/oauth/token`	Получение токена доступа	openid
3	`/v2/oauth/user-info`	Получение информации	openid

Сценарий	Клиент выбирает тариф и сразу оформляет Подписку
Особенности	Клиент выбирает тариф - сразу оформляет Подписку, и Платформа получает информацию о компании Клиента, о реквизитах и разрешение на безакцептное списание.
Когда актуально	- У вас есть бесплатный пробный период (но предлагаете его только при условии оформления Подписки) - Если не предусмотрен личный кабинет для пользователей Платформы
Что следует учесть	На Платформе должна быть предусмотрена возможность изучить все тарифы и условия подписки без авторизации. Если это не предусмотреть, то Платформа будет предлагать Клиенту оформить Подписку без информирования его о тарифах и условиях.

Используемые методы

№	Точка вызова	Описание	Операция в scope
1	`/v2/oauth/authorize`	Получение кода авторизации	openid
2	`/v2/oauth/token`	Получение токена доступа	openid
3	`/v2/oauth/user-info`	Получение информации	openid

Спишите оплату с Клиента за использование вашего сервиса

Списание платы за подписку

Шаги

Получить access_token
Проверить подписку Клиента
Создать платежное требование
Получить статус платежного требования

Участники usecase

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

Предусловия

Отсутствуют

Постусловия

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

Используемые методы

№	Точка вызова	Описание	Операция в scope	Шаг в схеме
1	`/v2/oauth/authorize`	Получение кода авторизации	openid	1. Получить access_token
2	`/v2/oauth/token`	Получение токена доступа	openid	1. Получить access_token
3	`/v2/oauth/user-info`	Получение информации	openid	1. Получить access_token
4	`/v1/partner-info/advance-acceptances`	Получить сведения о подписчиках	GET_ADVANCE_ACCEPTANCES	2. Проверить подписку Клиента
5	`/v1/payment-requests/outgoing`	Отправить запрос на безакцептное списание	PAYMENT_REQUEST_OUT	3. Создать платежное требование
6	`/v1/payment-requests/outgoing/{externalId}/state`	Получить статус запроса	PAYMENT_REQUEST_OUT	4. Получить статус платежного требования

Получить сведения о подписчиках (/v1/partner-info/advance-acceptances)

https://fintech.sberbank.ru:9443/fintech/api/v1/partner-info/advance-acceptances

Метод /v1/partner-info/advance-acceptances позволяет получить сведения о клиентах, которые подключились или отписались. В ответе возвращается массив данных с перечнем подписчиков и отписавшихся на запрашиваемый день. Для поддержания актуальной информации необходимо осуществлять ежедневный запрос информации. В массиве данных по клиентам также содержится информация с реквизитным составом, которую дальше можно использовать в запросах на безакцепное списание.

Для получения сведений необходимо отправить GET-запрос /v1/partner-info/advance-acceptances с токеном доступа (access_token) пользователя собственной организации в параметре Authorization заголовка, а также датой, на которую запрашиваете информацию, и идентификатор сервиса (clientId) в querry-параметрах запроса.

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

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

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

Request

/v1/partner-info/advance-acceptances

Модель
Пример

Наименование	Тип	Формат	Regexp	Обязательность	Описание
HEADER
Authorization	string	string	^([a-zA-Z0-9]){38}$	required	Access token пользователя, полученный через SSO.
QUERRY PARAMETERS
date	data-time	ISO 8601 YYYY-MM-DD	^(\d{4})-(0[1-9]\|1[0-2])-(0[1-9]\|[12][0-9]\|3[01])$	required	Дата (подключения или отключения),
clientId	string	string	\d{1,10}	required	Идентификатор платформы

GET /fintech/api/v1/payments/v1/partner-info/advance-acceptances?date=2023-11-20&clientid=142545731
Authorization: Bearer xbgDF3brf456ghi789jkl012mNKFtEpqr678

Responses

200 (OK)

Модель
Пример

Наименование	Тип	Обязательность	Описание
AdvanceAcceptance [
{
AdvanceAcceptance 1 {
active	boolean	optional	Признак активности ЗДА. Значение "true" возвращается по клиентам, подписавшим ЗДА. Если Клиент не подписал ЗДА или отменил его у себя в СберБизнес, то будет возвращаться значение "false",
bundles	Array[AdvanceAcceptanceBundle]	optional	Информация о пакете услуг,
payerAccount	string	optional	Счет плательщика,
payerBankBic	string	optional	БИК банка плательщика,
payerBankCorrAccount	string	optional	Корсчет банка плательщика,
payerInn	string	optional	ИНН плательщика,
payerName	string	optional	Наименование плательщика,
payerOrgIdHash	string	optional	Идентификатор организации плательщика,
purpose	string	optional	Назначение платежа,
sinceDate	string	optional	Дата начала действия ЗДА,
untilDate	string	optional	Дата окончания действия ЗДА
}
AdvanceAcceptanceBundle {
code	string	optional	Код пакета услуг,
name	string	optional	Наименование пакета услуг,
sinceDate	string	optional	Дата подключения пакета услуг,
untilDate	string	optional	Дата отключения пакета услуг,
currentState	string	optional	Статус пакета услуг в настоящее время. Возможные варианты: `ACTIVE`, `NOT_PAID`, `DEACTIVATED`
}
]

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
 
[⁣
 ⁣ ⁣{
 ⁣ ⁣ ⁣ ⁣"payerInn": "5414009744",
 ⁣ ⁣ ⁣ ⁣"payerAccount": "40702810938000000849",
 ⁣ ⁣ ⁣ ⁣"payerBankBic": "044525225",
 ⁣ ⁣ ⁣ ⁣"payerBankCorrAccount": "30101810400000000225",
 ⁣ ⁣ ⁣ ⁣"purpose": "202020 По договору №202020 от 29.03.2022",
 ⁣ ⁣ ⁣ ⁣"payerOrgIdHash": "286f8685274592b5a1e5f7e3d2f2aa583f65ad1f41165425fb4c0fafa790a9e7",
 ⁣ ⁣ ⁣ ⁣"payerName": "ООО_Автотест_Клиент_ЕКС_20200619123849",
 ⁣ ⁣ ⁣ ⁣"sinceDate": "2022-03-29",
 ⁣ ⁣ ⁣ ⁣"untilDate": "2022-06-07",
 ⁣ ⁣ ⁣ ⁣"active": true,
 ⁣ ⁣ ⁣ ⁣"bundles": null
 ⁣ ⁣},
 ⁣ ⁣{
 ⁣ ⁣ ⁣ ⁣"payerInn": "5331355363",
 ⁣ ⁣ ⁣ ⁣"payerAccount": "40702810338000000614",
 ⁣ ⁣ ⁣ ⁣"payerBankBic": "044525225",
 ⁣ ⁣ ⁣ ⁣"payerBankCorrAccount": "30101810400000000225",
 ⁣ ⁣ ⁣ ⁣"purpose": "202020 По договору №202020 от 29.03.2022",
 ⁣ ⁣ ⁣ ⁣"payerOrgIdHash": "e646c19e82e80f6b0895e711a1e8da511d34d1ac4eb0f9103867dfc8413007d0",
 ⁣ ⁣ ⁣ ⁣"payerName": "ООО_Автотест_Клиент_ЕКС_20200608203238",
 ⁣ ⁣ ⁣ ⁣"sinceDate": "2022-03-29",
 ⁣ ⁣ ⁣ ⁣"untilDate": null,
 ⁣ ⁣ ⁣ ⁣"active": true,
 ⁣ ⁣ ⁣ ⁣"bundles": null
 ⁣ ⁣},
 ⁣ ⁣{
 ⁣ ⁣ ⁣ ⁣"payerInn": "8755334940",
 ⁣ ⁣ ⁣ ⁣"payerAccount": "40702810338000000656",
 ⁣ ⁣ ⁣ ⁣"payerBankBic": "044525225",
 ⁣ ⁣ ⁣ ⁣"payerBankCorrAccount": "30101810400000000225",
 ⁣ ⁣ ⁣ ⁣"purpose": "202020 По договору №202020 от 29.03.2022",
 ⁣ ⁣ ⁣ ⁣"payerOrgIdHash": "a9137f1c0e7ece7576679e99f9ff67574f34fd6ad3fb5d7c629137dacc4b9ffb",
 ⁣ ⁣ ⁣ ⁣"payerName": "ООО_Автотест_Клиент_ЕКС_20200609164415",
 ⁣ ⁣ ⁣ ⁣"sinceDate": "2022-03-29",
 ⁣ ⁣ ⁣ ⁣"untilDate": null,
 ⁣ ⁣ ⁣ ⁣"active": true,
 ⁣ ⁣ ⁣ ⁣"bundles": null
 ⁣ ⁣}
]

400 (Bad request)

Cause	Message	Description
DESERIALIZATION_FAULT	Неверный формат запроса	Данные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request метода. Скорректируйте заполнение атрибутов и повторите запрос.
VALIDATION_FAULT	Ошибка валидации	Данные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request метода, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
ResourceFault {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
checks	Array[Check]	optional	Список проверок, приведших к ошибке,
fieldNames	Array[string]	optional	Названия полей с некорректным значением (только для VALIDATION_FAULT)
}
Check [
{
level	string	optional	Уровень результата = ['ERROR', 'WARNING'],
message	string	optional	Сообщение,
fields	Array[string]	optional	Названия полей (при наличии связи с моделью)
}
]

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "VALIDATION_FAULT",
    "referenceId": "934088e0-f079-4fa6-acb4-6fbb69671979",
    "message": "Ошибка при разборе параметров запроса",
    "checks": [
        {
            "level": "ERROR",
            "message": "Unparseable date: \"2023/11/22\"",
            "fields": [
                "date"
            ]
        }
    ],
    "fieldNames": [
        "date"
    ]
}

401 (Unauthorized Error)

Cause	Message	Description
UNAUTHORIZED	accessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-х	Указан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "UNAUTHORIZED",
    "referenceId": "014ec3a1-3e41-4805-9e22-d07947b012af",
    "message": "accessToken not found by value = 3513f959-bbd5-490a-9f9f-67fb7380fae5-2"
}

403 (Forbidden)

Cause	Message	Description
ACTION_ACCESS_EXCEPTION	Операция не может быть выполнена: доступ к ресурсу запрещен	Используемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API. В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция `GET_ADVANCE_ACCEPTANCES`. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
		Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.
		Проверьте используемый access_token в header и clientId в querry-параметре запроса. Оба параметра должны принадлежать одной вашей организации.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 403 Forbidden
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "ACCESS_EXCEPTION",
    "referenceId": "74cbc645-297c-451d-af9c-97c68c2c3560",
    "message": "Получение информации о подключенных клиентах возможно только по собственной организации"
}

404 (Not found)

Cause	Message	Description
DATA_NOT_FOUND_EXCEPTION	Не найдено ни одного заранее данного акцепта за указанную дату	На указанную в запросе дату никто не подписался и не отписался

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 404 Not Found
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "DATA_NOT_FOUND_EXCEPTION",
    "referenceId": "075e05bf-f8cc-44d7-873e-ff46ed9171c3",
    "message": "Не найдено ни одного заранее данного акцепта за указанную дату"
}

500 (Internal Server Error)

Cause	Message	Description
UNKNOWN_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 500 Internal Server Error
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNKNOWN_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a65d",
  "message": "Внутренняя ошибка сервера"
}

503 (Service Temporarily Unavailable)

Cause	Message	Description
UNAVAILABLE_RESOURCE_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNAVAILABLE_RESOURCE_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a67d",
  "message": "Внутренняя ошибка сервера"
}

Отправить запрос на безакцептное списание (/v1/payment-requests/outgoing)

ВАЖНО!

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

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

https://fintech.sberbank.ru:9443/fintech/api/v1/payment-requests/outgoing

Метод /v1/payment-requests/outgoing позволяет создавать платежные требования, где получателем средств является ваша компания.

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

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

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

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

Request

/v1/payment-requests/outgoing

Модель
Пример

Наименование	Тип	Формат	Regexp	Обязательность	Описание
HEADER
Authorization	string	string	^([a-zA-Z0-9]){38}$	required	Access token пользователя, полученный через SSO.
BODY
PaymentRequestOut {
acceptanceTerm	string	string	^[1-5]{1}$	optional	Срок для акцепта (поле 36). Указывается количество дней для получения акцепта плательщика,
amount	number	float	^[0-9]+(.[0-9]+)?$	required	Сумма платежа,
date	string	ISO 8601 YYYY-MM-DD	^(\d{4})-(0[1-9]\|1[0-2])-(0[1-9]\|[12][0-9]\|3[01])$	required	Дата составления документа,
deliveryKind	string	string	^(электронно\|срочно\|0)$	optional	Вид платежа: электронно, срочно Если не заполнено или 0, то будет присвоено значение "электронно",
digestSignatures	Array[Signature]	object		optional	Электронные подписи по дайджесту документа,
externalId	string	UUID	^([0-9A-Fa-f]{8})-([0-9A-Fa-f]{4})-([0-9A-Za-z]{4})-([0-9A-Fa-f]{12})$	required	Идентификатор документа, присвоенный партнером,
number	string	string	^[0-9]$	optional	Номер документа,
operationCode	string	string	^02$	required	Код операции,
payeeAccount	string	string	^[0-9]$	required	Счет получателя платежа,
payeeBankBic	string	string	^[0-9]{9}$	required	БИК получателя платежа,
payeeBankCorrAccount	string	string	^[0-9]{20}$	required	Корсчет банка получателя платежа,
payeeInn	string	string	^([0-9]{5}\|[0-9]{10}\|[0-9]{12}\|0)$	optional	ИНН получателя платежа,
payeeName	string	string	^[0-9a-zA-Zа-яА-ЯеЁ \t]+$	required	Полное наименование получателя платежа,
payerAccount	string	string	^[0-9]{20}$	required	Счет плательщика,
payerBankBic	string	string	^[0-9]{9}$	required	БИК банка плательщика,
payerBankCorrAccount	string	string	^[0-9]{20}$	required	Корсчет банка плательщика,
payerInn	string	string	^([0-9]{5}\|[0-9]{10}\|[0-9]{12}\|0)$	required	ИНН плательщика,
payerName	string	string	^[0-9a-zA-Zа-яА-ЯеЁ \t]+$	required	Полное наименование плательщика,
paymentCondition	string	string	^(1\|2)$	required	Условие оплаты (поле 35). Указывается цифра "1" - заранее данный акцепт плательщика или цифра "2" - требуется получение акцепта плательщика,
priority	string	string	^[1-5]{1}$	required	Очередность платежа,
purpose	string	string	^[a-zA-Z0-9._ -]{1-210}$	required	Назначение платежа. Заполнять значением purpose, полученным в ответе на запрос GET `/v1/partner-info/advance-acceptances` Если необходимо дополнить назначение, поставьте точку и укажите свою информацию,
vat	Array[Vat]	object		required	Данные НДС,
voCode	string	string	^[0-9]{5}$	required	Код вида валютной операции
}
Signature [
{
base64Encoded	string	base64	^[a-zA-Z0-9]+$	optional	Значение электронной подписи (ЭП), закодированное в Base64. Можно передать одну или две ЭП вместе с реквизитами создаваемого документа - ссылка на ЭП. Если ЭП передана/ы в API, то они сохраняются вместе с документом, а сам документ продвигается дальше по своему жизненному циклу. Если ЭП не была/и передана/ы, то документ сохраняется в своем начальном статусе и ожидает дальнейшего подписания в интерфейсе СберБизнес,
certificateUuid	string	UUID	^([0-9A-Fa-f]{8})-([0-9A-Fa-f]{4})-([0-9A-Za-z]{4})-([0-9A-Fa-f]{12})$	optional	Уникальный идентификатор сертификата ключа проверки электронной подписи
}
]
Vat {
amount	number	float	^[0-9]+(.[0-9]+)?$	optional	Сумма НДС,
rate	string	string	^[0-9]{0-1}$	optional	Ставка НДС,
type	string	string	^(INCLUDED\|NO_VAT\|MANUAL)$	required	Способ расчета НДС. INCLUDED - НДС включен в сумму платежа NO_VAT - не облагается НДС MANUAL - ручной ввод НДС
}

POST /fintech/api/v1/payment-requests/outgoing HTTP/1.1
Authorization: Bearer xbgDF3brf456ghi789jkl012mNKFtEpqr678
Content-Type: application/json
 
{
  "acceptanceTerm": "1",
  "amount": 100.00,
  "date": "2023-11-24",
  "deliveryKind": "электронно",
  "digestSignatures": [
    {
      "base64Encoded": "HlaeIHXXEcGT1bFxo1NlpAzpr+kJ2IQrcxVdvDTep6xjsmD1FDb+6NIyLT+/T24S0mPfVCU75sieOMt71TBS7w==",
      "certificateUuid": "22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6"
    }
  ],
  "externalId": "88ffd6c6-61d8-4269-ab1c-8c6ba21eb257",
  "number": "1",
  "operationCode": "02",
  "payeeAccount": "40702810006000001792",
  "payeeBankBic": "048073601",
  "payeeBankCorrAccount": "30101810300000000601",
  "payeeInn": "7379190522",
  "payeeName": "ТЕСТ9036",
  "payerAccount": "40702810506000002149",
  "payerBankBic": "048073601",
  "payerBankCorrAccount": "30101810300000000601",
  "payerInn": "6376615662",
  "payerName": "ООО_Автотест_Клиент_ЕКС_20231027092414",
  "paymentCondition": "2",
  "priority": "5",
  "purpose": "Оплата заказа №123. НДС 20%",
  "vat": {
    "amount": 20,
    "rate": "20",
    "type": "INCLUDED"
  },
  "voCode": "61150"
}

digestSignatures

Передача электронной подписи

Передача электронной подписи (ЭП) осуществляется с использованием массива digestSignatures, где каждый элемент представляет собой подпись (Signature). Каждая подпись должна содержать следующие обязательные поля:

Наименование поля	Описание поля	Пример
base64Encoded (string)	Значение ЭП документа	HlaeIHXXEcGT1bFxo1NlpAzpr+kJ2IQrcxVdvDTep6xjsmD1FDb+6NIyLT+/T24S0mPfVCU75sieOMt71TBS7w==
certificateUuid (string)	Идентификатор сертификата, использованного при создании ЭП (можно узнать, обратившись к ресурсу `/v1/crypto` или `/v1/crypto/eio)`	22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6

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

Документ может быть подписан следующими наборами подписей:

одна (единственная) подпись;
первая и вторая подписи.

При этом нельзя сочетать подпись, имеющую единственное полномочие, с подписью, имеющей первую или вторую подписи.

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

Подробнее о работе с ЭЦП в Sber API можно ознакомиться в соответствующем разделе документации.

Формат дайджеста

Формат
Пример

Наименование поля	Описание поля	Пример
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 от 01.08.2018. НДС не облагается

acceptanceTerm=5
amount=100.01
date=2018-12-31
externalId=22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6
operationCode=02
payeeAccount=40802810600000200000
payeeBankBic=044525225
payeeBankCorrAccount=30101810400000000225
payeeInn=0
payeeName=Общество с ограниченной ответственностью "Получатель"
payerAccount=40802810600000200000
payerBankBic=044525225
payerBankCorrAccount=30101810400000000225
payerInn=0
payerName=Общество с ограниченной ответственностью "Клиент"
paymentCondition=1
priority=5
purpose=Назначение платежа

Responses

201 (Created)

Модель
Пример

Наименование	Тип	Обязательность	Описание
PaymentRequestOut {
acceptanceTerm	string	optional	Срок для акцепта (поле 36). Указывается количество дней для получения акцепта плательщика,
amount	number	required	Сумма платежа,
bankComment	string	optional	Банковский комментарий к статусу документа,
bankStatus	string	optional	Статус документа,
crucialFieldsHash	string	optional	Hash от ключевых полей документа,
date	string	required	Дата составления документа,
deliveryKind	string	optional	Вид платежа: электронно, срочно Если не заполнено или 0, то будет присвоено значение "электронно",
digestSignatures	Array[Signature]	optional	Электронные подписи по дайджесту документа,
externalId	string	required	Идентификатор документа, присвоенный партнером,
number	string	optional	Номер документа,
operationCode	string	required	Код операции,
payeeAccount	string	required	Счет получателя платежа,
payeeBankBic	string	required	БИК получателя платежа,
payeeBankCorrAccount	string	required	Корсчет банка получателя платежа,
payeeInn	string	optional	ИНН получателя платежа,
payeeName	string	required	Полное наименование получателя платежа,
payerAccount	string	required	Счет плательщика,
payerBankBic	string	required	БИК банка плательщика,
payerBankCorrAccount	string	required	Корсчет банка плательщика,
payerInn	string	required	ИНН плательщика,
payerName	string	required	Полное наименование плательщика,
paymentCondition	string	required	Условие оплаты (поле 35). Указывается цифра "1" - заранее данный акцепт плательщика или цифра "2" - требуется получение акцепта плательщика,
priority	string	required	Очередность платежа,
purpose	string	required	Назначение платежа. Заполнять значением purpose, полученным в ответе на запрос GET `/v1/partner-info/advance-acceptances` Если необходимо дополнить назначение, поставьте точку и укажите свою информацию,
vat	Array[Vat]	required	Данные НДС,
voCode	string	required	Код вида валютной операции
}
Signature [
{
base64Encoded	string	optional	Значение электронной подписи (ЭП), закодированное в Base64. Можно передать одну или две ЭП вместе с реквизитами создаваемого документа - ссылка на ЭП. Если ЭП передана/ы в API, то они сохраняются вместе с документом, а сам документ продвигается дальше по своему жизненному циклу. Если ЭП не была/и передана/ы, то документ сохраняется в своем начальном статусе и ожидает дальнейшего подписания в интерфейсе СберБизнес,
certificateUuid	string	optional	Уникальный идентификатор сертификата ключа проверки электронной подписи
}
]
Vat {
amount	number	optional	Сумма НДС,
rate	string	optional	Ставка НДС,
type	string	required	Способ расчета НДС. INCLUDED - НДС включен в сумму платежа NO_VAT - не облагается НДС MANUAL - ручной ввод НДС
}

HTTP/1.1 201 Created
Content-Type: application/json;charset=UTF-8
 
{
    "number": "1",
    "date": "2023-11-24",
    "bankStatus": "CREATED",
    "bankComment": null,
    "externalId": "88ffd6c6-61d8-4269-ab1c-8c6ba21eb257",
    "amount": "100.00",
    "operationCode": "02",
    "deliveryKind": "электронно",
    "digestSignatures": [
       {
         "base64Encoded": "HlaeIHXXEcGT1bFxo1NlpAzpr+kJ2IQrcxVdvDTep6xjsmD1FDb+6NIyLT+/T24S0mPfVCU75sieOMt71TBS7w==",
         "certificateUuid": "22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6"
       }
     ],
    "priority": "5",
    "voCode": null,
    "purpose": "Оплата заказа №123. НДС 20%",
    "payerName": "ООО_Автотест_Клиент_ЕКС_20231027092414",
    "payerInn": "6376615662",
    "payerAccount": "40702810506000002149",
    "payerBankBic": "048073601",
    "payerBankCorrAccount": "30101810300000000601",
    "payeeName": "ТЕСТ9036",
    "payeeInn": "7379190522",
    "payeeAccount": "40702810006000001792",
    "payeeBankBic": "048073601",
    "payeeBankCorrAccount": "30101810300000000601",
    "crucialFieldsHash": "0c78790070b8487a4d73151bdab59899",
    "vat": {
        "type": "INCLUDED",
        "rate": "20",
        "amount": "20.00"
    },
    "paymentCondition": "1"
}

202 (Accepted)

Cause	Message	Description
WORKFLOW_FAULT	Документ сохранен, но обработка ЭП или принятие документа завершились ошибкой. ЭП не может быть принята	Неизвестный идентификатор сертификата. Проверьте корректность отправленной ЭП в запросе. Возможно, была отправлена ЭП с типом "Первая подпись" или "Вторая подпись". Для случаев, когда используется ЭП подписантов с типом "Первая подпись" или "Вторая подпись" для принятия документа в обработку требуется передать в запросе данные обеих подписей.

Модель
Пример

Наименование	Тип	Обязательность	Описание
ResourceFault {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
checks	Array[Check]	optional	Список проверок, приведших к ошибке,
fieldNames	Array[string]	optional	Названия полей с некорректным значением (только для VALIDATION_FAULT)
}
Check [
{
level	string	optional	Уровень результата = ['ERROR', 'WARNING'],
message	string	optional	Сообщение,
fields	Array[string]	optional	Названия полей (при наличии связи с моделью)
}
]

HTTP/1.1 202 Accepted
Content-Type: application/json;charset=UTF-8

{
    "cause": "WORKFLOW_FAULT",
    "referenceId": "73d032bd-e5ca-486b-8978-4d430af67320",
    "message": "Документ сохранен, но обработка ЭП или принятие документа завершились ошибкой. ЭП не может быть принята",
    "checks": [
        {
            "level": "ERROR",
            "message": "Неизвестный идентификатор сертификата: 22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6",
            "fields": []
        }
    ],
    "fieldNames": null
}

400 (Bad request)

Cause	Message	Description
DESERIALIZATION_FAULT	Неверный формат запроса	Данные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request метода. Скорректируйте заполнение атрибутов и повторите запрос.
WORKFLOW_FAULT	Невозможно идентифицировать организацию плательщика	Проверьте корректность указанных реквизитов плательщика.
	Невозможно идентифицировать банк получателя по указанным номеру БИК и корреспондентскому счету	Проверьте корректность указанных реквизитов получателя платежа - атрибуты payeeBankBic и payeeBankCorrAccount
	Документ с таким externalId уже существует в системе	Используется externalId, который уже есть в системе (дубль). Сгенерируйте новый externalId и повторите запрос.
VALIDATION_FAULT	Ошибка валидации	Данные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request метода, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
ResourceFault {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
checks	Array[Check]	optional	Список проверок, приведших к ошибке,
fieldNames	Array[string]	optional	Названия полей с некорректным значением (только для VALIDATION_FAULT)
}
Check [
{
level	string	optional	Уровень результата = ['ERROR', 'WARNING'],
message	string	optional	Сообщение,
fields	Array[string]	optional	Названия полей (при наличии связи с моделью)
}
]

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "DESERIALIZATION_FAULT",
    "referenceId": "4a0e6754-ad22-4d7d-ac82-810afd08b5b2",
    "message": "Неверный формат запроса",
    "checks": [
        {
            "level": "ERROR",
            "message": "Cannot deserialize instance of `java.util.ArrayList<Signature>` out of START_OBJECT token",
            "fields": [
                "digestSignatures"
            ]
        }
    ],
    "fieldNames": [
        "digestSignatures"
    ]
}

401 (Unauthorized Error)

Cause	Message	Description
UNAUTHORIZED	accessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-х	Указан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "UNAUTHORIZED",
    "referenceId": "014ec3a1-3e41-4805-9e22-d07947b012af",
    "message": "accessToken not found by value = 3513f959-bbd5-490a-9f9f-67fb7380fae5-2"
}

403 (Forbidden)

Cause	Message	Description
ACTION_ACCESS_EXCEPTION	Операция не может быть выполнена: доступ к ресурсу запрещен	Используемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API. В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция `PAYMENT_REQUEST_OUT`. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
		Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 403 Forbidden
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "ACCESS_EXCEPTION",
    "referenceId": "74cbc645-297c-451d-af9c-97c68c2c3560",
    "message": "Получение информации о подключенных клиентах возможно только по собственной организации"
}

500 (Internal Server Error)

Cause	Message	Description
UNKNOWN_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 500 Internal Server Error
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNKNOWN_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a65d",
  "message": "Внутренняя ошибка сервера"
}

503 (Service Temporarily Unavailable)

Cause	Message	Description
UNAVAILABLE_RESOURCE_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNAVAILABLE_RESOURCE_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a67d",
  "message": "Внутренняя ошибка сервера"
}

Получить статус запроса (/v1/payment-requests/outgoing/{externalId}/state)

https://fintech.sberbank.ru:9443/fintech/api/v1/payment-requests/outgoing/{externalId}/state

Метод /v1/payment-requests/outgoing/{externalId}/state позволяет получить статус ранее отправленного платежного требования.

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

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

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

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

Request

/v1/payment-requests/outgoing/{externalId}/state

Модель
Пример

Наименование	Тип	Формат	Regexp	Обязательность	Описание
HEADER
Authorization	string	string	^([a-zA-Z0-9]){38}$	required	Access token пользователя, полученный через SSO.
PATH PARAMETERS
externalId	string	UUID	^([0-9A-Fa-f]{8})-([0-9A-Fa-f]{4})-([0-9A-Za-z]{4})-([0-9A-Fa-f]{12}))$	required	Идентификатор документа, присвоенный вами при создании исходящего платежного требования

GET /fintech/api/v1/payment-requests/outgoing/db7d9e97-fc35-456b-a8a0-b864b0ee6dfb/state HTTP/1.1
Authorization: Bearer xbgDF3brf456ghi789jkl012mNKFtEpqr678

Responses

200 (OK)

Модель
Пример

Наименование	Тип	Обязательность	Описание
PaymentDocState {
bankComment	string	optional	Банковский комментарий к статусу документа,
bankStatus	string	optional	Статус документа,
channelInfo	string	optional	Комментарий, специфичный для документа, полученного по данному каналу,
crucialFieldsHash	string	optional	Hash от ключевых полей документа
}

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
 
{
    "bankStatus": "CREATED",
    "bankComment": null,
    "channelInfo": null,
    "crucialFieldsHash": "0c78790070b8487a4d73151bdab59899"
}

400 (Bad request)

Cause	Message	Description
DESERIALIZATION_FAULT	Неверный формат запроса	Данные в request указаны в неправильном формате. Атрибуты request, в которых найдены ошибки, указаны в responce в массиве fields с описанием проблемы. Описание типа, формата и regexp атрибутов находится в request метода. Скорректируйте заполнение атрибутов и повторите запрос.
VALIDATION_FAULT	Ошибка валидации	Данные не соответствуют требованиям валидации. Сведения о некорректных атрибутах request содержатся в массивах fieldNames и checks. Подробные требования к атрибутам описаны в request метода, включая типы, форматы и регулярные выражения. Необходимо скорректировать заполнение атрибутов и повторить запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
ResourceFault {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
checks	Array[Check]	optional	Список проверок, приведших к ошибке,
fieldNames	Array[string]	optional	Названия полей с некорректным значением (только для VALIDATION_FAULT)
}
Check [
{
level	string	optional	Уровень результата = ['ERROR', 'WARNING'],
message	string	optional	Сообщение,
fields	Array[string]	optional	Названия полей (при наличии связи с моделью)
}
]

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
  
{
    "cause": "VALIDATION_FAULT",
    "referenceId": "0d6a80ba-7d35-4858-8443-9a77039ad9f1",
    "message": "Параметр \"externalId\" не соответствует регулярному выражению: [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}",
    "checks": [],
    "fieldNames": null
}

401 (Unauthorized Error)

Cause	Message	Description
UNAUTHORIZED	accessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-х	Указан некорректный или просроченный access_token. Используйте refresh_token для обновления access_token и повторите запрос.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "UNAUTHORIZED",
    "referenceId": "014ec3a1-3e41-4805-9e22-d07947b012af",
    "message": "accessToken not found by value = 3513f959-bbd5-490a-9f9f-67fb7380fae5-2"
}

403 (Forbidden)

Cause	Message	Description
ACTION_ACCESS_EXCEPTION	Операция не может быть выполнена: доступ к ресурсу запрещен	Используемый в запросе access_token не имеет разрешения на доступ к нужному сервису Sber API. В ссылке авторизации СберБизнес ID, в параметре scope, не указана операция `PAYMENT_REQUEST_OUT`. Необходимо добавить эту операцию в scope. Пользователю потребуется пройти авторизацию заново. Вы получите новые токены access_token и refresh_token. Сделайте повторный запрос с новым access_token.
		Вы использовали access_token пользователя Клиента, а не пользователя вашей организации. Нужно использовать access_token пользователя вашей организации.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 403 Forbidden
Content-Type: application/json;charset=UTF-8
 
{
    "cause": "ACTION_ACCESS_EXCEPTION",
    "referenceId": "7535c2bb-7706-4b16-9882-d68aedbf2fef",
    "message": "Операция не может быть выполнена: доступ к ресурсу запрещен"
}

404 (Not found)

Cause	Message	Description
NOT_FOUND	Документ с указанным ID не найден

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 404 Not Found
Content-Type: application/json;charset=UTF-8
  
{
    "cause": "NOT_FOUND",
    "referenceId": "1bd1b8b9-1bd3-4159-9909-d30536211114",
    "message": "Документ с указанным ID не найден"
}

500 (Internal Server Error)

Cause	Message	Description
UNKNOWN_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 500 Internal Server Error
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNKNOWN_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a65d",
  "message": "Внутренняя ошибка сервера"
}

503 (Service Temporarily Unavailable)

Cause	Message	Description
UNAVAILABLE_RESOURCE_EXCEPTION	Внутренняя ошибка сервера	Сделайте повторный запрос. Если ошибка повторится, подготовьте логи запроса и направьте в службу Технической поддержки Банка.

Модель
Пример

Наименование	Тип	Обязательность	Описание
Notice {
cause	string	optional	Причина или основание сообщения,
referenceId	string	optional	Уникальный идентификатор ошибки (UUID),
message	string	optional	Сообщение,
}

HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: application/json;charset=UTF-8
 
{
  "cause": "UNAVAILABLE_RESOURCE_EXCEPTION",
  "referenceId": "9e209109-4b0d-408c-a2fd-e1983c20a67d",
  "message": "Внутренняя ошибка сервера"
}

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

bankStatus (string)

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

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

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

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

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

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

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

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

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

Если НДС не указан, то по умолчанию будут использованы эти значения:
```
"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 («Исполнен»). Создавать новое платежное поручение и отправлять повторно Клиенту не требуется.

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

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

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

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

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

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

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

Получить сведения о подписчиках (/v1/partner-info/advance-acceptances)﻿

Request﻿

Responses﻿

Отправить запрос на безакцептное списание (/v1/payment-requests/outgoing)﻿

Request﻿

digestSignatures﻿

Responses﻿

Получить статус запроса (/v1/payment-requests/outgoing/{externalId}/state)﻿

Request﻿

Responses﻿

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

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

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

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

FAQ﻿

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

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

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

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

Получить сведения о подписчиках (/v1/partner-info/advance-acceptances)

Request

Responses

Отправить запрос на безакцептное списание (/v1/payment-requests/outgoing)

Request

digestSignatures

Responses

Получить статус запроса (/v1/payment-requests/outgoing/{externalId}/state)

Request

Responses

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

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

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

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

FAQ