Сервис «Корпоративные подписки»
Информация о сервисе
Корпоративные подписки – это сервис для организации расчетов с юридическими лицами (ЮЛ) и индивидуальными предпринимателями (ИП), который позволяет получать сведения о подписчиках и безакцептно списывать денежные средства за предоставление услуг или товаров.
Ядро механизма сервиса составляют платежные требования, которые используются в качестве платежных документов для расчетов между компаниями.
Платежное требование
Платежное требование - это документ, используемый для безналичных расчетов между юридическими лицами, в котором поставщик предъявляет должнику претензию за неуплату задолженности по договору. Банк на основании этого документа списывает сумму задолженности со счета плательщика в пользу получателя.
Основное различие между платежным требованием и платежным поручением заключается в инициаторе платежа. В платежном поручении инициатором является владелец счета, тогда как в платежном требовании - получатель денег (кредитор, поставщик, продавец или исполнитель услуг). Кредитор оформляет платежное требование и направляет его в банк для исполнения. Часто для выполнения платежного требования требуется акцепт (согласие) плательщика.
Платежные требования могут быть с предварительным акцептом или без него. Акцепт - это согласие должника оплатить задолженность в определенный срок. Если акцепт не предусмотрен договором, то срок составляет 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. Проверить статус оплаты |
Подписание заявления на ЗДА
Чтобы Сбер обработал сформированный черновик заявления ЗДА, клиенту необходимо его подписать. Клиент может его подписать в личном кабинете СберБизнес, либо сформируйте и направьте пользователю ссылку вида:
{контур банка}**/ic/ufs/advance-acceptance/index.html#/advance-acceptance-creator/{externalId}?backUrl={backUrl}
Ссылку можно разместить под кнопкой в вашем интерфейсе или отправить в явном виде. При переходе по ссылке откроется окно с функциональностью подписания заявления. После успешного подписания сервис вернет пользователя по указанному в ссылке URL.
- Модель ссылки
- Пример
Ссылка переадресации выглядит следующим образом:
{контур банка}/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://www.example.ru/
Отзыв согласия на ЗДА
Для отмены подписки на сервис клиенту необходимо отозвать согласие на ЗДА.
Существует два способа отзыва согласия на ЗДА:
- Клиент может самостоятельно отменить подписку в СберБизнесе. Для этого ему необходимо перейти в меню СберБизнеса: Запросы на оплату - Акцепты - Заявления на заранее данный акцепт;
- Р еализуйте сценарий отзыва согласия на ЗДА на вашей платформе. Для этого сформируйте и направьте пользователю ссылку вида:
{контур банка}/ic/ufs/advance-acceptance/index.html#/advance-acceptance-revoke/{externalId}
Например, ссылку можно разместить под кнопкой в вашем интерфейсе или отправить в явном виде. При переходе по ссылке откроется окно с функциональностью отзыва согласия.
- Модель ссылки
- Пример
| Переменная | Описание | Дополнительная информация |
|---|---|---|
{контур Банка} | адрес Банка, на который делается запрос для открытия страницы сервиса подписания заявления | Для корректного выбора контура Банка потребуется определить тип криптопрофиля пользователя Клиента. В рамках запроса /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} | уникальный иде нтификатор заявления | Данный идентификатор присваивает ваша Платформа на шаге создания черновика заявления на ЗДА. |
https://sbi.sberbank.ru:9443/ic/ufs/advance-acceptance/index.html#/advance-acceptance-revoke/d4fbfe27-ee37-4451-b224-8113a06c44a3
В таком случае при вызове метода /v1/partner-info/advance-acceptances в поле "active" вы получите значение "false".
Дополнительная информация
Назначение платежа
Назначение должно раскрывать экономический смысл платежа.
- Сведения должны быть лаконичными — у поля есть ограничения по знакам 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
Будет ли исполнено Банком платежное требование, отправленное выходные или праздничные дни?
Исходящие платежные требования, созданные после 16:50 часов (по Московскому времени) в пятницу, начинают обрабатываться в следующий понедельник.
Что происходит если денежных средств на счете клиента недостаточно?
В случае недостатка денежных средств на счете клиента для оплаты, банк ожидает поступления средств на счет клиента в полном объеме до конца календарного дня. Если деньги на счете клиента не появятся в полном объеме в течении указанного срока, платежное требование перейдет в статус REFUSEDBYBANK ("Отвергнут банком или Отклонен банком").