Сервис «Корпоративные подписки»
Информация о сервисе
Корпоративные подписки – это сервис для организации расчетов с юридическими лицами (ЮЛ) и индивидуальными предпринимателями (ИП), который позволяет получать сведения о подписчиках и безакцептно списывать денежные средства за предоставление услуг или товаров.
Ядро механизма сервиса составляют платежные требования, которые используются в качестве платежных документов для расчетов между компаниями.
Платежное требование
Платежное требование - это документ, используемый для безналичных расчетов между юридическими лицами, в котором поставщик предъявляет должнику претензию за неуплату задолженности по договору. Банк на основании этого документа списывает сумму задолженности со счета плательщика в пользу получателя.
Основное различие между платежным требованием и платежным поручением заключается в инициаторе платежа. В платежном поручении инициатором является владелец счета, тогда как в платежном требовании - получатель денег (кредитор, поставщик, продавец или исполнитель услуг). Кредитор оформляет платежное требование и направляет его в банк для исполнения. Часто для выполнения платежного требования требуется акцепт (согласие) плательщика.
Платежные требования могут быть с предварительным акцептом или без него. Акцепт - это согласие должника оплатить задолженность в определенный срок. Если акцепт не предусмотрен договором, то срок составляет 5 рабочих дней. Без акцепта банк имеет право списать деньги с расчетного счета клиента в определенных случаях, например, по решению суда на основании исполнительных документов.
Другая часть механизма построена на предварительном акцепте (у себя мы его называем Заранее данный акцепт - ЗДА) на списание денежных средств со счета подписчика.
Терминология
- Заранее данный акцепт (далее по тексту - ЗДА) – временное согласие Клиента на списание денежных средств в счет оплаты предоставленных услуг или товаров по подписке. Наличие Заранее данного акцепта позволяет по запросу от вашей компании Банку списывать средства со счета Клиента без дополнительного согласования.
- Оформить Подписку – подписать Заявление на Заранее данный акцепт.
- Исходящее Платежное требование (далее по тексту - ИПТ) – расчетный документ, на основании которого Банк списывает денежные средства со счета Клиента-подписчика.
- Digest ИПТ – набор значимых полей платежного документа, который подписывается электронной подписью (ЭП).
Схема работы сервиса
- Графическое описание
- Текстовое описание
| Шаг | Что делаем | Подробности |
|---|---|---|
| 1 | Авторизуйте Пользователя с помощью СберБизнес ID | Подробно о подключении сервиса СберБизнес ID рассказали в соответствующем разделе документации. |
| 2 | Предложите оформить Подписку | С помощью access_token пользователя Клиента и ресурса /fintech/api/v1/acceptance-advances создайте черновик заявления на ЗДА в СберБизнес Клиента. |
| 3 | Переадресуйте Пользователя на страницу подписания документа | С использованием идентификатора созданного черновика заявления ЗДА из шага №2 вы формируете ссылку для подписания документа и перенаправляете по ней пользователя Клиента. Перейдя по ссылке в сервис, пользователь пройдет аутентификацию, выберет счет списания и подпишет черновик ЗДА для исполнения Банком. Ссылка переадресации выглядит следующим образом: {контур банка}/ic/ufs/advance-acceptance/index.html#/advance-acceptance-creator/{externalId}?backUrl={backUrl}Дополнительная информация о формировании ссылки. |
| 4 | Проверьте статус и корректность оформления Подписки | С помощью access_token пользователя Клиента и ресурса /fintech/api/v1/acceptance-advances/{externalId}/state вы получите статус заявления ЗДА. Вы можете разработать механизм проверки статуса и реакцию Платформы на каждый из них.Важно: ЗДА вступает в силу на следующий рабочий день с даты его подписания. С помощью access_token пользователя Клиента и ресурса /fintech/api/v1/acceptance-advances/{externalId} вы получите полные данные ЗДА. Этот шаг позволит вам разработать механизм проверки неизменности подписанного документа путем сравнения отправленных параметров ЗДА в шаге №2 с результатами из ответа на данном шаге. |
| 5 | Спишите плату за подписку | С помощью access_token пользователя вашей компании и ресурса /fintech/api/v1/payment-requests/outgoing необходимо сформировать и отправить в Банк подписанное ИПТ.Чтобы Банк мог начать обрабатывать платежный документ, документ должен быть подписан ЭП уполномоченным сотрудником, имеющим право подписи от лица компании. Подробно о работе с ЭП рассказали в соответствующем разделе документации. Важно: Владелец access_token пользователя вашей компании должен совпадать с владельцем ЭП, которую будете использовать для подписания ИПТ. |
| 6 | Проверьте статус оплаты | С помощью access_token пользователя вашей компании и ресурса /fintech/api/v1/payment-requests/outgoing/{externalId}/state вы получите статус платежного требования. Вы можете разработать механизм проверки статуса оплаты и реакцию Платформы на каждый из статусов. |
Варианты реализации
В рамках Платформы вы самостоятельно разрабатываете ролевую модель и настраиваете права доступа к функциональности.
Ниже, в качестве примера, приведена диаграмма вариантов использования:
Оформление подписки
Для наличия возможности без акцептного списания денежных средств со счета Клиента потребуется получить от него согласие на автоматические списания. Его получить можно при оформлении Подписки пользователем Клиента. Клиент становится подписчиком после заключения договора с вашей компанией или акцепта Оферты вашей Платформы и оформления ЗДА на списание платы за подписку на основании заключенного договора/акцепта Оферты.
Шаги
- Сформировать черновик ЗДА
- Подписать черновик ЗДА
- Проверить статус подписания ЗДА
- Проверить подписанный ЗДА
Участники usecase
- Пользователь - представитель ЮЛ/ИП, от лица которого он работает в рамках вашего сервиса (Платформы)
- Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
- Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа
Предварительные условия
- Пользователь имеет пользовательский профиль в СберБизнес своей компании
- Пользователь находится в пространстве Платформы
- Пользователь прошел авторизацию с помощью СберБизнес ID
Результат применения
- Платформа получила подтверждение оформления Подписки (подписан документ заявление на ЗДА)
Используемые запросы
| № | Метод | Точка вызова | Описание | Операция в scope | Шаг в схеме |
|---|---|---|---|---|---|
| 1 |  | /fintech/api/v1/acceptance-advances | Создание черновика заявления ЗДА | ACCEPTANCE_ADVANCE | 1. Сформировать черновик ЗДА |
| 2 | | /ic/sso/api/v2/oauth/token | Обновление токена доступа | openid | 1. Сформировать черновик ЗДА |
| 3 |  | /fintech/api/v1/acceptance-advances/{externalId}/state | Получение статуса заявления ЗДА | ACCEPTANCE_ADVANCE | 3. Проверить статус подписания ЗДА |
| 4 | | /fintech/api/v1/acceptance-advances/{externalId} | Получение заявления ЗДА | ACCEPTANCE_ADVANCE | 4. Проверить подписанный ЗДА |
Списание платы за подписку
Выставить платежное требование Клиенту можно не раньше даты, следующей за датой оформления Подписки.
Например, Пользователь Клиента оформил Подписку 15 января. На следующий день, 16 января, можно будет сформировать платежное требование для списания денежных средств. Если сформировать платежное требование в день оформления Подписки, то платежное требование исполнено не будет - оно встанет в "Картотеку" в СберБизнес Клиента на ручное подтверждение.
В схеме можно использовать автоматизированное подписание документа. Данная возможность доступна только при использовании ЭЦП сотрудника вашей компании.
Подробнее об использовании ЭЦП в Sber API можно почитать в одноименном разделе.
Шаги
- Проверить актуальность подписки
- Создать и подписать ИПТ
Участники usecase
- Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
- Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа
Предварительные условия
- Успешно выполнен сценарий "Оформление подписки"
- Платформа сохранила идентификатор (extertalId) заявления на ЗДА, созданного в сценарии "Оформление подписки"
- У Платформы есть access_token пользователя вашей компании
Результат применения
- Платформа создала ИПТ
Используемые запросы
| № | Метод | Точка вызова | Описание | Операция в scope | Шаг в схеме |
|---|---|---|---|---|---|
| 1 | | /fintech/api/v1/acceptance-advances/{externalId}/state | Получение статуса заявления ЗДА | ACCEPTANCE_ADVANCE | 1. Проверить актуальность подписки |
| 2 | | /ic/sso/api/v2/oauth/token | Обновление токена доступа | openid | 1. Проверить актуальность подписки и 2. Создать и подписать ИПТ |
| 3 | | /fintech/api/v1/payment-requests/outgoing | Создание платежного требования | PAYMENT_REQUEST_OUT | 2. Создать и подписать ИПТ |
Проверка статуса оплаты
Шаги
- Проверить статус оплаты
Участники usecase
- Платформа - любой web-ресурс (интернет-магазин, облачный сервис, мобильное приложение и т.д.) либо ваша внутренняя система (ERP, учетная система и др.), которую используют Пользователи
- Sber API - в контексте usecase представляет из себя запросы и ресурсы Sber API, к которым обращается Платформа
Предварительные условия
- Успешно выполнен сценарий "Списание платы за подписку"
- Платформа сохранила идентификатор (extertalId) ИПТ, созданного в сценарии "Списание платы за подписку"
- У Платформы есть access_token пользователя вашей компании
Результат применения
- ИПТ исполнено Банком
Используемые запросы
| № | Метод | Точка вызова | Описание | Операция в scope | Шаг в схеме |
|---|---|---|---|---|---|
| 1 | | /fintech/api/v1/payment-requests/outgoing/{externalId}/state | Получение статуса платежного требования | PAYMENT_REQUEST_OUT | 1. Проверить статус оплаты |
| 2 | | /ic/sso/api/v2/oauth/token | Обновление токена доступа | openid | 1. Проверить статус оплаты |
Переадресация на заявление ЗДА
Для начала обработки заявления на ЗДА Банком оно должно быть подписано. При создании документа с помощью запроса 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 в ссылке, пользователи не смогут после подписания вернуться на Платформу; - Если backUrl будет отличаться от адреса вашей платформы, который указали при регистрации в Банке, то при возврате клиента на backUrl он будет видеть ошибку. |
https://sbi.sberbank.ru:9443/ic/ufs/advance-acceptance/index.html#/advance-acceptance-creator/d4fbfe27-ee37-4451-b224-8113a06c44a3?backUrl=https%3A%2F%2Fwww.example.ru%2F
Дополнительная информация
Назначение платежа
Назначение должно раскрывать экономический смысл платежа.
- Сведения должны быть лаконичными — у поля есть ограничения по знакам 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".