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

Обзор

Верификация подтверждения адреса (POA) принимает один PDF или изображение (TIFF, JPG, JPEG, PNG, WEBP, опционально в ZIP-архиве) размером до 15 МБ, выполняет классификацию типа документа, извлечение данных с помощью LLM и криминалистический анализ PDF/EXIF, после чего возвращает:
  • Извлечённый адрес — как в исходном виде, так и структурированный (street_1, city, region, postal_code, широта/долгота).
  • Метаданные документа — размер файла, тип контента, даты создания и изменения, даты EXIF, информацию о подписи и любые свидетельства манипуляций с наложением слоёв из криминалистического анализа PDF.
  • Оценки совпадения имени с верифицированным документом, удостоверяющим личность, и с ожидаемыми данными, указанными при создании сессии.
  • Дополнительные банковские поля (номер счёта, IBAN, сортировочный код, маршрутный номер, SWIFT/BIC, филиал), если документ является банковской выпиской.
Скриншот отчёта подтверждения адреса Didit с извлечёнными полями адреса и типом документа
При извлечении данных POA выполняется чтение неструктурированного текста, что добавляет задержку 5–15 секунд на каждый документ. Webhook срабатывает только тогда, когда весь шаг сценария завершается целиком — не опрашивайте endpoint с решением чаще одного раза в 5 секунд в течение этого интервала.

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

Endpoint с решением возвращает POA в виде массива во множественном числе poa_verifications[] в GET /v3/session/{sessionId}/decision/. Каждый элемент представляет собой одно выполнение узла POA в вашем сценарии; сессии с несколькими шагами POA (например, банковская выписка + счёт за коммунальные услуги) формируют по одной записи на каждое выполнение с собственным node_id.
Приведённая ниже структура повторяет каноническую схему — см. Модели данных.

Схема

Каноническую схему см. в разделе Подтверждение адреса в справочнике моделей данных.
Каждая запись в warnings[] представляет собой объект предупреждения: { feature, risk, additional_data, log_type, short_description, long_description, node_id }, при этом feature для данного отчёта всегда равен "PROOF_OF_ADDRESS".

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

Поле status использует перечисление статусов на уровне функции (FeatureStatusChoices). Пользовательские правила статусов, настроенные на узле сценария, могут дополнительно корректировать вычисленный статус; правила объединяются с приоритетом Declined > In Review > Approved. Полное сопоставление рисков и действий, включая поведение повторной попытки только на уровне сценария для FUTURE_ISSUE_DATE, см. в разделе Предупреждения подтверждения адреса.

Доказательства манипуляций с наложением в PDF

Если отправленный документ является PDF, document_metadata.overlay_manipulation может содержать криминалистические доказательства предполагаемого наложения текста:
  • detected: true, когда проверка нашла доказательства манипуляции.
  • analyzed: true, когда PDF вообще удалось проанализировать.
  • analysis_incomplete: присутствует и равно true только тогда, когда файл не удалось проверить полностью. Результаты того, что было проверено, сохраняются там, где это возможно, а для документа создаётся POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT.
  • signals: сработавшие проверки (duplicate_font_subset, glyph_fragmentation).
  • manipulated_regions: прямоугольники в координатах страницы вокруг предполагаемо отредактированного текста. Каждый прямоугольник использует систему координат страницы PDF (x, y, width, height, page_width, page_height), чтобы проверяющие могли выделить затронутую область в предпросмотре PDF.
Поле имеет значение null, если документ не является PDF или PDF не удалось проанализировать. Когда detected=true, система также выдаёт предупреждение SUSPECTED_DOCUMENT_MANIPULATION, additional_data которого повторяет сигналы и прямоугольники, описанные выше (за исключением случаев, когда приоритет получил более сильный сигнал, а именно изменение после цифровой подписи, is_tampered=true; тогда additional_data описывает вмешательство в цифровую подпись).

QR-коды и штрихкоды

Каждый отчёт POA включает поле detected_codes, охватывающее каждую обработанную страницу. Каждый элемент содержит: Поле detected_codes представляет собой пустой массив, если поддерживаемые коды не найдены. Didit никогда не угадывает payload: повреждённые или нечитаемые коды могут возвращаться со своим местоположением и со значением parsed_payload: null, при этом сбои при обнаружении кодов не приводят к сбою верификации POA.

Примеры

Одобрена — банковская выписка

Отклонена — манипуляции с наложением слоёв + несовпадение имени

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

Поля document_file и extra_files[] представляют собой предварительно подписанные URL, срок действия которых истекает приблизительно через 4 часа. Повторно вызовите endpoint с решением, чтобы обновить URL-адреса. Сохраняйте на своей стороне только статус верификации и разобранные поля адреса — минимизируйте объём хранимых данных документов.
Последнее изменение 7 ноября 2026 г.