Перейти к основному содержанию
Отчёт «Проверка телефона» фиксирует полный результат проверки номера через OTP: кому был отправлен код, какой оператор и канал использовались для доставки, сколько потребовалось попыток, является ли номер одноразовым или VoIP, а также любые межсессионные совпадения со списком блокировки или сессиями других пользователей. На этой странице описана структура JSON, возвращаемая endpoint решения, что позволяет анализировать результаты проверки OTP, метаданные оператора и флаги риска для каждого верифицированного номера.
Отчёт Didit о проверке телефона, показывающий результат проверки OTP, метаданные оператора и флаги риска

Обзор

Отчёт по номеру телефона формируется каждый раз, когда узел сценария выполняет функцию Проверка телефона. Каждый отчёт представляет одну проверку через OTP для одного номера телефона и содержит:
  • Номер телефона, разбитый на префикс, национальный номер и полный формат E.164, а также код страны ISO и название страны.
  • Метаданные оператора (name, type), определённые по сети назначения.
  • Логические флаги риска (is_disposable, is_virtual), полученные на основе анализа типа линии.
  • Фактически использованный канал доставки (verification_method) и количество попыток отправки OTP.
  • Хронологический журнал lifecycle[] для каждого события отправки, повторной попытки, доставки и проверки введённого кода.
  • Массив matches[], отображающий совпадения этого же номера в других сессиях с любым статусом — в KYC, KYB и отдельных API-верификациях — либо в вашем списке блокировки.
  • Массив warnings[] — события риска, зафиксированные в процессе верификации (см. Предупреждения проверки телефона).
  • Идентификатор node_id, указывающий, какой узел графа сценария сформировал данный отчёт (только для сессий V3).
При использовании сценариев с размещённой страницей верификации Didit берёт обмен OTP на себя. Для прямой интеграции через API тот же процесс состоит из двух вызовов: POST /v3/phone/send/ для отправки кода и POST /v3/phone/check/ для проверки введённого пользователем значения. Неподтверждённый OTP действителен в течение 5 минут с момента первой отправки (повторные попытки не продлевают этот интервал). В сессиях сценария пользователям по умолчанию предоставляется 2 попытки отправки OTP (phone_max_retries) и 2 попытки ввода кода (phone_max_check_attempts) — оба параметра настраиваются индивидуально для каждого узла сценария; исчерпание любого из этих лимитов завершает шаг со статусом Declined и причиной VERIFICATION_CODE_ATTEMPTS_EXCEEDED. Отдельный API проверки телефона допускает 3 попытки ввода кода на одну верификацию.

Где это отображается в ответах API

Endpoint решения (GET /v3/session/{sessionId}/decision/) возвращает отчёты по номерам телефонов в массиве под ключом во множественном числе phone_verifications. Этот массив содержит по одной записи для каждого узла «Проверка телефона» в графе сценария — обычно одну, но сценарии с повышением уровня проверки (step-up) могут содержать несколько таких записей.
Значение null означает, что шаг «Проверка телефона» ещё не выполнялся. Если ваш сценарий может запрашивать несколько номеров телефонов, перебирайте массив в цикле (вместо чтения только phone_verifications[0]).

Схема

Каноническая схема с подробным описанием каждого поля приведена на странице Data models.

Значения статуса

Типы событий жизненного цикла

Массив lifecycle[] отсортирован хронологически. Каждое событие содержит type, timestamp, details и тарифицируемую комиссию fee (при наличии): Payload details зависит от семейства событий:
  • События отправки (PHONE_VERIFICATION_MESSAGE_SENT, PHONE_VERIFICATION_RETRY_MESSAGE_SENT, PHONE_VERIFICATION_BLOCKED) — { status, reason, channel, actual_channel }. Поле status принимает значения Success, Retry или Blocked; reason равен null, если отправка не была заблокирована (invalid_phone_number, repeated_attempts, suspicious, spam, unknown); channel представляет собой запрошенный канал, а actual_channel указывает на канал, через который сообщение было фактически доставлено (например, при отправке в WhatsApp с переключением на SMS при сбое).
  • События доставки (PHONE_DELIVERY_DELIVERED, PHONE_DELIVERY_UNDELIVERABLE) — { channel, status } со status delivered или undeliverable.
  • События проверки кода (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } со status Approved, Declined, Failed или Expired or Not Found.
  • События итогового статуса — null, за исключением PHONE_VERIFICATION_DECLINED / PHONE_VERIFICATION_IN_REVIEW, которые содержат { "reason": "<risk code>" } (например, PHONE_NUMBER_IN_BLOCKLIST).
Поле fee в событии отправки представляет собой полную стоимость этой отправки: тариф оператора или WhatsApp плюс комиссия Didit в размере $0.02, либо только комиссия Didit в размере $0.02 за код WhatsApp, отправленный с вашего собственного номера WhatsApp Business. До подтверждения доставки это предварительная стоимость, а затем фактическая сумма списания. Бесплатными гарантированно являются только отправки со статусом Blocked: любая другая отправка тарифицируется в момент финализации верификации или по истечении срока её действия, даже если доставка не была подтверждена или сообщение оказалось недоставляемым. События доставки, проверки и изменения статуса всегда имеют fee: 0.

Совпадения между сессиями

Массив matches[] фиксирует другие сессии в том же приложении, где встречался тот же номер — в рамках KYC, KYB и верификаций через отдельный API независимо от их статуса — плюс совпадения со списками блокировки, настроенными в списках management-api. Сессии с тем же vendor_data, что и у текущей сессии, исключаются (один и тот же конечный пользователь не сопоставляется с самим собой), а размер массива ограничен 5 записями. Если номер находится в вашем списке блокировки, но ни одна из найденных сессий не заблокирована, в начало массива добавляется синтетическая запись с source: "list_entry" (все поля сессии равны null).

Примеры

Одобрено — одноразовый код WhatsApp, мобильный оператор связи

Отклонено — номер VoIP из списка блокировки

Пользователь ввёл корректный одноразовый код, однако на этапе финализации номер был обнаружен в списке блокировки приложения (автоматическое отклонение), а также был определён тип линии VoIP (для voip_number_action оставлено значение NO_ACTION, поэтому событие зафиксировано как information). Поскольку ни одна из найденных сессий не находится в списке блокировки, попадание в список отображается как синтетическое совпадение list_entry.

Связанные разделы

Последнее изменение 7 ноября 2026 г.