Подтверждение операций¶
Для обеспечения безопасности и соблюдения регуляторных требований к кредитным организациям клиент должен подтверждать выполнение операций, которые предполагают доступ QIWI к его денежным средствам.
Процесс подтверждения включает три этапа:
- аутентификация личности клиента с помощью OTP;
- выпуск клиентского токена;
- авторизация операций с помощью клиентского токена.
На основании успешной аутентификации личности клиента 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
; - время, через которое можно запросить повторную отправку OTP —
resendDelaySeconds
.
Сценарий «Аутентификация с помощью 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
.