Перейти к содержанию

Проведение операций домена CARDS

Описание операции домена CARDS см. в статье «Термины и бизнес-сущности». В этом разделе мы расскажем о проведении финансовых операций домена CARDS.

Обработка таких операций условно делится на 2 этапа:

Процесс успешной обработки финансовой операции домена CARDS в упрощённом виде описан ниже.

Онлайн-операция

Здесь описан успешный сценарий обработки финансовой операции домена CARDS.

  1. Клиент совершает операцию — пополняет карту QIWI с карты другого банка, покупает товар или услугу в интернете, снимает наличные в банкомате и др.
  2. Платёжная система, которая обслуживает карту, отправляет QIWI (BaaS) запрос на авторизацию операции.
  3. BaaS совершает действие, которое приводит к движению денежных средств, в рамках запроса на авторизацию — зачисляет средства на баланс клиента, резервирует средства на балансе клиента, списывает их и др.
  4. BaaS создаёт запись об успешном совершении действия в рамках онлайн-операции определённого типа.
  5. BaaS отправляет платёжной системе ответ об успешной авторизации операции.
  6. BaaS отправляет партнёру уведомление об успешном совершении действия в рамках онлайн-операции определённого типа, если такая возможность настроена.

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

В рамках одной и той же онлайн-операции может быть совершено несколько действий. Количество и последовательность действий зависят от типа операции. Список типов операций см. в документации History&Notifications API.

Клиент может совершить отмену (например, отменить заказ на покупку товара). В этом случае платёжная система, которая обслуживает карту, отправит QIWI запрос на отмену операции. QIWI (BaaS) совершит необходимое действие, создаст запись о его выполнении для уже существующей операции и уведомит об этом партнёра, если такая возможность настроена.

Пример записи в BaaS о получении запроса на отмену покупки в интернете приведён ниже. В примере запрос получен по операции покупки c идентификатором txn1, в рамках которой BaaS ранее зарезервировал денежные средства на карте клиента.

Пример

txnId txnType actionId actionType actionStatus
txn1 PURCHASE_E_POS act1 HOLD SUCCESS
txn1 PURCHASE_E_POS act2 REVERSAL SUCCESS

Описание полей см. в документации History&Notifications API.

Пример успешной покупки и отмены покупки в интернет-магазине с помощью карты QIWI изображён на диаграмме ниже.

%%{init: {
    "sequence" : {
        "wrap":true,
        "messageFontSize":15,
        "noteFontSize":13,
        "actorMargin":
        75 }}}%%
sequenceDiagram
    participant С as Клиент
    participant I as Интернет-магазин
    participant PS as Платёжная система
    participant B as BaaS
    С->>I: Покупка товара
    Note right of С: «Оплатить»
    I->>PS: Запрос на авторизацию покупки txn1
    Note right of I: Через систему банка-эквайера
    PS->>B: Запрос на авторизацию покупки txn1
    B->>B: HOLD
    B->>PS: 200 OK
    PS->>I: 200 OK
    Note left of PS: Через систему банка-эквайера
    I->>С: Коммуникация с клиентом
    Note right of С: Заказ подтверждён, средства зарезервированы на карте
    С->>I: Отмена заказа
    Note right of С: «Отменить»
    I->>PS: Запрос на авторизацию отмены покупки txn1
    Note right of I: Через систему банка-эквайера
    PS->>B: Запрос на авторизацию отмены покупки txn1
    B->>B: REVERSAL
    B->>PS: 200 OK
    PS->>I: 200 OK
    Note left of PS: Через систему банка-эквайера
    I->>С: Коммуникация с клиентом
    Note right of С: Заказ отменён, средства доступны для использования

Список возможных действий и их описание см. в документации History&Notifications API.

Офлайн-операция

Платёжная система, которая обслуживает карту, отправляет QIWI клиринговый файл. В этом файле содержатся записи об операциях, совершённых на стороне платёжной системы.

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

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

Для каждой записи из клирингового файла BaaS выполняет определённое действие (например, списывает денежные средства с карты клиента) и уведомляет об этом партнёра, если такая возможность настроена.

Пример записи в BaaS о получении авторизационного клиринга приведён ниже. В примере клиринг получен по операции совершения покупки в интернете c идентификатором txn1, а BaaS ранее зарезервировал средства для этой покупки в рамках получения запроса на авторизацию.

Пример

txnId txnType actionId actionType actionStatus
txn1 PURCHASE_E_POS act1 HOLD SUCCESS
txn1 PURCHASE_E_POS act2 CAPTURE_HOLD SUCCESS

Описание полей см. в документации History&Notifications API.

Пример записи в BaaS о получении безавторизационного клиринга по операции совершения покупки в интернете будет содержать лишь одну строку с actionType:CAPTURE_HOLD.

Пример успешной покупки в интернет-магазине с помощью карты QIWI изображён на диаграмме ниже.

%%{init: {
    "sequence" : {
        "wrap":true,
        "messageFontSize":15,
        "noteFontSize":13,
        "actorMargin":
        75 }}}%%
sequenceDiagram
    participant С as Клиент
    participant I as Интернет-магазин
    participant PS as Платёжная система
    participant B as BaaS
    С->>I: Покупка товара
    Note right of С: «Оплатить»
    I->>PS: Запрос на авторизацию покупки txn1
    Note right of I: Через систему банка-эквайера
    PS->>B: Запрос на авторизацию покупки txn1
    B->>B: HOLD
    B->>PS: 200 OK
    PS->>I: 200 OK
    Note left of PS: Через систему банка-эквайера
    I->>С: Коммуникация с клиентом
    Note right of С: Заказ подтверждён
    PS->>B: Клиринговый файл с записью о покупке txn1
    B->>B: CAPTURE_HOLD

Список возможных действий и их описание см. в документации History&Notifications API.

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

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

В рамках одной покупки может поступить несколько отдельных записей в одном или разных файлах клиринга. Записи могут содержать разные суммы. Такой случай в терминологии BaaS называется мультиклирингом.

Пример мультиклиринга

  1. Клиент совершил покупку двух авиабилетов в рамках одного бронирования на общую сумму 20 000 руб.
  2. BaaS авторизовал покупку с идентификатором txn1 на сумму 20 000 руб., захолдировал денежные средства на счёте клиента и отправил партнёру уведомление.
  3. Платёжная система отправила QIWI файл клиринга на следующий день после авторизации покупки. В файле была запись о совершении покупки txn1 на сумму 10 000 руб и признак multiClearingData, говорящий о том что расчёты по операции txn1 ещё не закончены.
  4. QIWI (BaaS) списал 10 000 руб. со счёта клиента и отправил партнёру уведомление.
  5. Платёжная система отправила QIWI ещё один файл клиринга на следующий день после отправки файла из п.3. В файле была запись о совершении покупки txn1 на сумму 10 000 руб. и отсутствовал признак multiClearingData.
  6. QIWI (BaaS) списал 10 000 руб. со счёта клиента и отправил партнёру уведомление.

Статусная модель

Жизненный цикл действия, которое приводит к движению средств, изображён на диаграмме ниже.

flowchart TD
    Start --> SUCCESS
    Start --> FAILED
Платёжная система отправляет запрос на авторизацию операции или клиринговый файл. BaaS выполняет движение денежных средств и создаёт запись об этом движении с одним из следующих статусов:

  • SUCCESS — когда действие выполнено успешно;
  • FAILED — когда действие не выполнено (в этом случае BaaS зафиксирует одну из перечисленных в документации History&Notifications API ошибок авторизации).