Отправка уведомлений клиентам

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

Отправки уведомлений клиентам

Ресурс /v1/notify-messages позволяет Партнеру отправлять уведомления клиентам СББОЛ с целью информирования.

Шаги

1. Получить AccessToken.

2. Отправить запрос.

Для отправки уведомления необходимо отправить POST-запрос (/v1/notify-messages), в котором передать авторизационный токен к данным клиента (Access Token). Авторизационный токен передается в параметре Authorization заголовка запроса.

Чтобы получить доступ к ресурсу, необходимо передать в scope сервис NOTIFY_MESSAGES.

Модель запроса

Header Parameters Описание
Authorization String
Access token организации-клиента, полученный через SSO.
Пример: Bearer c76fb018-27c9-43f7-a751-62646eda7e1a-1
Body Описание
Notification {
attributes (string, optional) Дополнительные параметры сообщения,
codeMessageKind (integer) Код вида сообщения,
datetimeSince (string) Дата и время, начиная с которой должно быть отправлено сообщение,
datetimeUntil (string, optional) Дата и время, до которого должно быть отправлено сообщение (дата, указанная в параметре datetimeUntil должна совпадать с датой, указанной в параметре datetimeSince),
externalId (string) Идентификатор уведомления, присвоенный партнёром (UUID)
}

Пример запроса

{

"attributes": "CONTRACT_DATE=10.01.2020, CONTRACT_NUM=10012020, INFO_LIST_DATE=01.05.2020, LOGIN=test",

"codeMessageKind": 8705,

"datetimeSince": "2018-12-31T23:59:59",

"datetimeUntil": "2018-12-31T23:59:59",

"externalId": "22a6dd81-103a-4d3a-8e9b-0ba4b527f5f6"

}

Модель ответа

Только http-код

Получение статуса уведомления

Ресурс /v1/notify-messages/{externalId}/state позволяет Партнеру получить статус уведомления отправленного клиенту.

Шаги

1. Получить AccessToken.

2. Отправить запрос.

Для получения статус необходимо отправить GET-запрос (/v1/notify-messages/{externalId}/state), в котором передать авторизационный токен к данным клиента (Access Token) и идентификатор уведомления (externalID). Авторизационный токен передается в параметре Authorization заголовка запроса.

Чтобы получить доступ к ресурсу, необходимо передать в scope сервис NOTIFY_MESSAGES.

Модель запроса

Header Parameters Описание
Authorization String
Access token полученный через SSO.
Пример: Bearer c76fb018-27c9-43f7-a751-62646eda7e1a-1
Path Parameters Описание
externalId String
Идентификатор уведомления, присвоенный партнером

Пример запроса

curl -X GET --header 'Accept: application/json' --header

'Authorization: Bearer f8ad3141-b7e8-4924-92de-3de4fd0a464e-1'

'https://edupirfintech.sberbank.ru:9443/fintech/api/v1/service-package'

Модель ответа

string (Возвращается один из статусов перечисленных ниже)

Возможные статусы

Статус Описание статуса
DEFERRED Отложен
NEW Новое
POSTED Отправлено (отправлено в шлюз)
RECEIVED Получено (доставлено провайдеру)
READED Прочитано (доставлено абоненту)
ERROR Ошибка
DELAYED Просрочено
IN_PROGRESS Обрабатывается

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

Подписание запроса транспортной подписью

Content-Type может содержать одно из двух значений:

  • application/json – запрос без подписи
  • application/jose – запрос, подписанный транспортной подписью

Если Content-Type имеет значение application/jose, то запрос должен содержать данные (реквизитный состав платежного документа) в виде компактной сериализации RFC 7515: JSON Web Signature (JWS).

JWS состоит из:

1. Заголовка (Header)
2. JSON-документа с реквизитным составом платежного поручения (Payload)
3. Подписи запроса (Signature)

Формирование компактной сериализации JWS

JWS формируется из трех составляющих:

Base64Url(Header) || ’.’ ||  Base64Url(Payload) || ’.’ || Base64Url(Signature)

Signature - это подпись данных приватной частью ключевой пары клиента (используется приватный ключ парный сертификату клиента с UUID, указанному в Заголовке (Header) в параметре kid).
Подпись вычисляется по алгоритму указанному в Заголовке (Header) в параметре alg, в данном случае gost34.10-2012, и вычисляется от исходных данных:

Base64Url(Header) || ‘.’ || Base64Url(Payload).

Формирование исходных данных для вычисления подписи описано в спецификации RFC 7515: JSON Web Signature (JWS).

Следует отметить, что при кодировании JWS используется преобразование Base64Url, отличающееся от Base64 преобразования.
Условно это преобразование можно представить следующим образом:

Base64Url(x) := Base64(x).Split(‘=’)[0].Replace(‘+’, ’-’).Replace(‘/’, ’_’)

здесь функция Split(x), разбивает строку на части ([i] означает взятие i–ой части), используя символ разделитель x, функция Replace(x,y) заменяет все вхождения символа x на символ y.

Преобразование BASE64URL, отличается от BASE64 преобразования:

BASE64URL BASE64
- (minus) +
_ (underline) /
  • В BASE64URL не используется (опускается) padding, т.е. не добавляются знаки ‘=’ на конце закодированного содержимого Padding of Encoded Data.

В ответе на запрос сервер возвращает JSON-документ, который содержит реквизитный состав подготовленного черновика рублевого платежного поручения в статусе Создан.

Коды возврата

Код возврата Описание кода возврата Причина возникновения
400 DESERIALIZATION_FAULT
Неверный формат запроса Неверный формат запроса
WORKFLOW_FAULT
Для внешнего сервиса недоступны операции по счету: 40702810ХХХХХХХХХХХХ Для внешнего сервиса недоступны операции по счету: счет не добавлен в список разрешенных в оферте; внешний сервис заблокирован в СББОЛ; счет указан неверно. Отсутствует доступный открытый рублевый расчетный счет у организации плательщика
Документ с такими реквизитами уже существует Документ с такими реквизитами уже существует. Проверка по номер документа в течении года.
Не указан идентификатор сертификата подписи Не указан идентификатор сертификата подписи(параметр kid заголовка JWS)
Некорректный формат параметра kid заголовка JWS Некорректный формат параметра kid заголовка JWS(ожидается UUID)
VALIDATION_FAULT
Ошибка валидации Ошибка валидации данных запроса с указанием некорректных значений. Значения полей модели или параметров запроса не соответствуют допустимым и определенным в модели.
SIGN_CHECK_EXCEPTION
Подлинность подписи не установлена/Сертификат не обнаружен или не является активным Ошибка возникает, если не удалось установить подлинность подписи
401 UNAUTHORIZED
accessToken not found by value =хххххххх-хххх-хххх-хххх-хххххххххххх-х Указан некорректный или просроченный access_token.
403 ACTION_ACCESS_EXCEPTION
Операция не может быть выполнена: доступ к ресурсу запрещен У пользователя нет прав на использование соответствующего сервиса SberBusinessAPI, доступ к которому не предусмотрен настройками scope; У пользователя отсутствует оферта с внешним сервисом.
415 JWS_EXCEPTED
В соответствии с текущими настройками сервиса с clientId=%s необходимо использовать запрос в формате JWS Compact Serialization Ошибка возникает, если в настройках внешних сервисов выставлен флаг «Требуется подпись для внешнего сервиса»
500 UNKNOWN_EXCEPTION
Внутренняя ошибка сервера
503 UNAVAILABLE_RESOURCE_EXCEPTION
Сервис временно недоступен Проводятся технические работы

Заметили ошибку?

Выделите текст и нажмите Ctrl + Enter, чтобы сообщить нам о ней