Решение об успешности платежа¶

BaaS поддерживает несколько вариантов проведения платежа:

синхронный — когда финальный статус проведения платежа известен сразу и возвращается в ответе на платёжный запрос;
асинхронный — когда платёж находится в обработке после получения запроса (и отправки ответа на запрос) и приобретает финальный статус несколько позже.

Синхронный вариант проведения платежа¶

Пример — выплата на кошелёк, перевод между кошельками и др.

Для принятия решения об успешности платежа партнёр может основываться на значении поля status, полученном в ответе на соответствующий платёжный запрос. Запросы и ответы описаны в документации Payments API.

Последовательность действий для принятия решения об успешности платежа на примере совершения перевода между кошельками приведена ниже.

%%{init: {
    "sequence" : {
        "wrap":true,
        "messageFontSize":14,
        "noteFontSize":14,
        "actorMargin":
        85 }}}%%
sequenceDiagram
    participant С as Клиент
    participant P as Партнёр
    participant B as BaaS
    С->>P: Перевод на кошелёк в интерфейсе
    Note right of С: «Перевести»
    P->>+B: Сценарий «Перевод между кошельками» (Payments API)
    Note right of P: transactionId
    B->>-P: 
    Note left of B: status:SUCCESS
    P->>С: Коммуникация с клиентом

Сценарий «Перевод между кошельками» см. здесь.

Обратите внимание

Синхронный вариант означает, что финальный статус проведения платежа (SUCCESS или DECLINED) известен сразу и возвращается в ответе на платёжный запрос. Тем не менее в редких случаях BaaS может вернуть статус PROCESSING. В такой ситуации партнёр должен выполнять одно из следующих действий до получения финального статуса:

отправлять запрос на совершение операции (повторный запрос должен быть идентичен исходному — методы Payments API являются идемпотентными);
запрашивать статус операции.

Асинхронный вариант проведения платежа¶

Пример — пополнение с банковской карты (см. пример запроса), перевод на банковскую карту (см. пример запроса) и др.

Для принятия решения об успешности платежа партнёру нужно дождаться уведомления от BaaS и следовать описанной ниже логике.

Если статус в уведомлении имеет финальное успешное значение status:SUCCESS, партнёру необходимо однократно выполнить запрос статуса к платформе самостоятельно. Это позволит избежать ложных уведомлений, т.е. устранить риски компрометации данных в случае утечки “секрета”, который используется при вычислении цифровой подписи уведомления. В конечном итоге партнёру следует основываться на значении поля status в ответе на запрос статуса соответствующего платежа. Запросы и ответы описаны в документации Payments API.

Последовательность действий для принятия решения об успешности платежа на примере совершения перевода на банковскую карту приведена ниже.

%%{init: {
    "sequence" : {
        "wrap":true,
        "messageFontSize":15,
        "noteFontSize":14,
        "actorMargin":
        85 }}}%%
sequenceDiagram
    participant С as Клиент
    participant P as Партнёр
    participant B as BaaS
    С->>P: Перевод на карту в интерфейсе
    Note right of С: «Перевести»
    P->>+B: Сценарий «Перевод на банковскую карту» (Payments API)
    Note right of P: transactionId
    B->>-P: 
    Note left of B: status:PROCESSING
    rect rgb(255, 238, 223)
    B->>+P: Сценарий «Уведомление об операциях домена PAYMENTS» (History&Notifications API)
    P-->>-B: 
    Note left of B: transactionId, status:SUCCESS
    end
    rect rgb(230, 230, 230)
    P->>+B: Запрос на получение статуса перевода (Payments API)
    Note right of P: transactionId
    B-->>-P: Ответ на запрос получения статуса
    Note left of B: transactionId, status:SUCCESS
    end
    P->>С: Коммуникация с клиентом

Упомянутые на диаграмме сценарии см. в статьях: