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

Подтверждение операций

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

Процесс подтверждения включает три этапа:

На основании успешной аутентификации личности клиента QIWI (BaaS) выпускает клиентский токен, который в дальнейшем используется для авторизации операций.

Процесс подтверждения в упрощённом виде изображён на диаграмме ниже.

%%{init: {
    "sequence" : {
        "messageFontSize":14,
        "noteFontSize":14,
         }}}%%
sequenceDiagram
    participant P as Партнёр
    participant B as BaaS
    critical Выполняется при создании клиента, выпуске карты и др.
    rect rgb(230, 230, 230)
    P->>+B: Сценарий «Аутентификация с помощью OTP»
    Note right of P: OTP
    B-->>-P: 
    Note left of B: confirmationId
    end
    end
    critical Выполняется только один раз при наличии успешной аутентификации
    rect rgb(255, 238, 223)
    P->>+B: Сценарий «Выпуск токена»
    Note right of P: confirmationId
    B-->>-P: 
    Note left of B: tokenValue
    end
    end
    loop Выполняется каждый раз при попытке совершить операцию
    rect rgb(230, 230, 230)
    P->>+B: Сценарий «Авторизация с помощью клиентского токена»
    Note right of P: tokenValue
    B-->>-P: 
    Note left of B: status:SUCCESS
    end
    end

Аутентификация с помощью OTP

При выполнении базовых банковских сценариев, таких как создание учётной записи клиента и выпуск карты, клиенту необходимо подтвердить свою личность. QIWI аутентифицирует клиента с помощью OTP.

Последовательность действий для аутентификации с помощью OTP изображена на диаграмме ниже. Этап, на котором эту последовательность необходимо выполнить, см. в статьях c описанием каждого отдельного сценария.

%%{init: {
    "sequence" : {
        "wrap":true,
        "messageFontSize":14,
        "noteFontSize":12,
        "actorMargin":
        125 }}}%%
sequenceDiagram
    participant С as Клиент
    participant P as Партнёр
    participant B as BaaS
    Note left of P: Партнёр получил номер телефона клиента на одном из этапов информационного взаимодействия
    P->>+B: Запрос на отправку OTP
    Note over P,B: productId, clientId, confirmationId:confirm1, confirmationType:SMS, confirmationOperationType, phoneNumber
    B->>-P: 
    Note over P,B: confirmationId:confirm1, resendAttemptsLeft, resendDelaySeconds, confirmationStatus:CREATED
    B->>С: SMS c OTP
    С->>P: Ввод OTP
    Note right of С: 123456
    P->>+B: Запрос на подтверждение OTP
    Note over P,B: productId, clientId, confirmationId:confirm1, confirmationCode:123456
    B->>-P: 
    Note over P,B: confirmationId:confirm1, confirmationStatus:CONFIRMED

Запросы описаны в документации Clients API.

Запрос на отправку OTP выполняется для определённого типа операции, описание см. в таблице ниже.

Сценарий Тип операции в запросе на отправку OTP
Создание клиента CREATE_TOKEN
Выпуск виртуальной карты ORDER_VIRTUAL_CARD
Изменение номера телефона клиента • CHANGE_PHONE_CONFIRM_OLD — для запроса на подтверждение текущего номера;
• CHANGE_PHONE_CONFIRM_NEW — для запроса на подтверждение нового номера
Перевыпуск токена REFRESH_TOKEN
Получение токена GET_TOKEN

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

Актуальный список типов операций см. в документации Clients API. Таблица выше приведена в качестве примера.

В ответе на запрос отправки OTP возвращаются:

  • количество оставшихся запросов на повторную отправку OTP — resendAttemptsLeft;
  • время, через которое можно запросить повторную отправку OTPresendDelaySeconds.

Сценарий «Аутентификация с помощью OTP» можно пройти в тестовой среде. Для этого необходимо:

  • отправлять запросы на URL-адреса тестовой среды;
  • использовать фиксированный набор тестовых данных (см. таблицу ниже).

    Номер телефона OTP
    78000008130 3182
    78000008110 111111

Срок жизни и время использования операции подтверждения

Срок жизни

В результате выполнения запроса на отправку OTP в BaaS создаётся операция подтверждения c идентификатором confirmationId. Эта операция имеет срок жизни — время, в течение которого можно ввести и подтвердить OTP.

Пример

Срок жизни установлен 2 минуты. Клиент получил SMS с OTP. По истечении 2 минут подтвердить этот OTP будет невозможно.

Время использования

В результате успешного подтверждения OTP confirmationId должен быть использован в том сценарии, для которого он создавался. Если партнёр не использовал confirmationId в течение определённого времени с момента подтверждения OTP, успешно завершить сценарий не удастся.

Пример

Время использования установлено 10 минут. Партнёр аутентифицирует клиента, чтобы выпустить для него банковскую карту.

Клиент получил SMS с OTP, в системе партнёра этому OTP соответствует confirmationId:confirm1. Клиент ввёл OTP из SMS в интерфейсе партнёра, OTP подтверждён. По истечении 10 минут создать заказ на выпуск карты c confirmationId:confirm1 будет невозможно.

Жизненный цикл операции подтверждения

flowchart TD
    Start --> CREATED
    Start --> errorCode
    CREATED --> CONFIRMED
    CREATED --> FAILED
    CONFIRMED --> USED

Партнёр отправляет запрос на отправку OTP. BaaS возвращает партнёру один из ответов:

  • HTTP 200 OK и confirmationStatus:CREATED — создана операция подтверждения, OTP успешно отправлен, ожидается аутентификация личности клиента;
  • HTTP 4xx/5xx и errorCode — данные не прошли валидацию или другие внутренние проверки ⇒ операция подтверждения не создана по причине, указанной в errorCode.

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

Клиент вводит код из SMS в интерфейсе партнёра, партнёр выполняет запрос на подтверждение OTP для операции в статусе CREATED и операция переходит в один из следующих статусов:

  • CONFIRMED — проверка OTP завершилась успешно, клиент аутентифицирован.
  • FAILED — клиент не аутентифицирован: превышено количество попыток подтверждения или срок жизни истёк.

Если операция в статусе CONFIRMED использована в целевом сценарии в течение заданного времени, её статус меняется на USED. Если не использована — остаётся CONFIRMED.

Одну операцию подтверждения (confirmationId) можно использовать для выполнения целевого сценария только один раз.

Выпуск токена

Клиентский токен используется для авторизации запросов на совершение операций и позволяет BaaS выполнять операции от имени аутентифицированного клиента.

Последовательность действий при создании клиентского токена изображена ниже.

%%{init: {
    "sequence" : {
        "messageFontSize":14,
        "noteFontSize":14,
         }}}%%
sequenceDiagram
    participant P as Партнёр
    participant B as BaaS
    critical Выполняется при создании клиента
    rect rgb(230, 230, 230)
    P->>+B: Сценарий «Аутентификация с помощью OTP»
    Note right of P: confirmationOperationType: CREATE_TOKEN, confirmationId:confirm1
    B-->>-P: 
    end
    end
    P->>+B: Запрос на выпуск токена
    Note right of P: productId, clientId, confirmationId:confirm1
    B->>B: Проверка confirmationId
    Note over B: Клиент аутентифицирован
    B->>-P: 
    Note left of B: tokenValue
    B->>B: Проверка confirmationId

Токен рекомендуется хранить на устройстве клиента: один клиент может иметь множество устройств, но один токен.

Перевыпуск токена

Последовательность действий при перевыпуске клиентского токена изображена ниже.

%%{init: {
    "sequence" : {
        "messageFontSize":14,
        "noteFontSize":14,
         }}}%%
sequenceDiagram
    participant P as Партнёр
    participant B as BaaS
    critical 
    rect rgb(230, 230, 230)
    P->>+B: Сценарий «Аутентификация с помощью OTP»
    Note right of P: confirmationOperationType: REFRESH_TOKEN, confirmationId:confirm2
    B-->>-P: 
    end
    end
    P->>+B: Запрос на выпуск токена
    Note right of P: productId, clientId, confirmationId:confirm2
    B->>B: Проверка confirmationId
    Note over B: Клиент аутентифицирован
    B->>-P: 
    Note left of B: tokenValue

Токен рекомендуется хранить на устройстве клиента: один клиент может иметь множество устройств, но один токен.

Авторизация с помощью клиентского токена

Запрос к API, содержащий заголовок QIWI-Client-Token, требует передачи значения клиентского токена. Чтобы понять, в каких запросах следует передавать QIWI-Client-Token: <значение токена>, см. описание HTTP Headers в документации API.

QIWI-Client-Token является дополнительным фактором авторизации: его использование не отменяет необходимости передавать Bearer Token в заголовке запроса Authorization.