Перейти к основному содержимому
Didit привлёк $7,5 млн на инфраструктуру для идентификации и борьбы с мошенничеством
Didit
В блог
Блог · 21 мая 2026 г.

Жизненный цикл сессии KYB: статусы и вебхуки (RU)

Отслеживайте верификацию KYB от начала до конца — статусы сессий, статусы по каждой функции, статусы бизнес-сущностей и вебхуки, которые поддерживают актуальность ваших записей, по цене 2,00 $ за компанию.

Автор: DiditОбновлено
kyb-session-lifecycle-webhooks.png

Верификация KYB — это не просто ответ «да/нет», это процесс с множеством меняющихся частей. Проверка реестра может быть одобрена мгновенно, в то время как проверка документов ожидает повторной подачи, а AML-проверка компании находится на рассмотрении аналитика. Чтобы интегрировать KYB эффективно, необходимо точно знать, в каком состоянии находится каждая часть верификации, и ваши собственные системы должны обновляться в тот момент, когда любое из этих состояний меняется. Именно для этого и служат жизненный цикл сессии и вебхуки.

API верификации бизнеса Didit предоставляет полную конечную машину состояний: статус общей сессии, статус каждой функции, отдельный набор статусов для бизнес-сущности после ее управления, и вебхуки, которые срабатывают при каждом изменении. Полная верификация компании стоит 2,00 $, и это руководство описывает весь жизненный цикл — каждый статус, каждый вебхук и API управления, который связывает все это воедино.

Основные выводы

  • Три уровня состояния. Верификация KYB имеет статус сессии, статусы по каждой функции и — после управления — статус бизнес-сущности.
  • Восемь статусов сессии. NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED, EXPIRED.
  • Шесть статусов функций для каждой из четырех функций KYB: NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED, AWAITING_USER.
  • Три статуса сущности под управлением: ACTIVE, FLAGGED, BLOCKED.
  • Вебхуки для всего. status.updated и data.updatedsession_kind: business) для сессий; business.status.updated и business.data.updated для управляемых сущностей.
  • Полный API управленияPOST /v3/businesses/create/, GET /v3/businesses/, GET /v3/businesses/{vendor_data}/, PATCH .../update-status/.

Что охватывает жизненный цикл KYB

Верификация KYB создает состояние на трех уровнях, и каждый из них отвечает на свой вопрос:

  • Сессия отвечает: «как проходит верификация в целом?»
  • Каждая функция отвечает: «в каком состоянии находится проверка реестра / AML компании / документов / ключевых лиц?»
  • Бизнес-сущность отвечает: «каково операционное состояние этой компании в нашей системе прямо сейчас?»

Вы читаете все три, и поддерживаете их синхронизацию с помощью вебхуков, а не через постоянные запросы. Верификация начинается как сессия, разрешает свои функции, приходит к общему результату, а затем — после того, как вы начинаете управлять компанией — имеет статус бизнес-сущности, который вы контролируете по мере изменения обстоятельств.

Почему это важно

Без детального состояния интеграция KYB превращается в догадки: один флаг «в ожидании» ничего не говорит о том, какая именно проверка задерживает процесс или какое действие может его разблокировать. Благодаря статусам для каждой функции вы можете действовать точно — попросить заявителя повторно отправить документ, поставить в очередь AML-совпадение сущности для рассмотрения аналитиком, предложить бенефициарному владельцу завершить свою KYC — вместо того, чтобы полностью отклонять верификацию.

Вебхуки важны, потому что KYB асинхронен. Данные реестра, оптическое распознавание документов и результаты скрининга поступают в разное время, а человеческий обзор занимает еще больше времени. Постоянный опрос на предмет изменений расточителен и медлителен; вебхуки передают изменение в тот момент, когда оно происходит, поэтому ваши записи отражают реальность без использования cron-заданий, нагружающих API.

Технические детали

Сессия KYB создается с использованием унифицированного API /v3/ и сообщает о своем состоянии жизненного цикла.

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "your_kyb_workflow_id",
    "vendor_data": "merchant_6601",
    "callback": "https://yourapp.com/kyb/callback"
  }'

Вебхук status.updated содержит статус сессии и статусы по каждой функции:

{
  "event": "status.updated",
  "session_kind": "business",
  "session_id": "kyb_3a90f1c2",
  "vendor_data": "merchant_6601",
  "status": "IN_REVIEW",
  "features": {
    "kyb_registry": "APPROVED",
    "kyb_company_aml": "IN_REVIEW",
    "kyb_documents": "RESUB_REQUESTED",
    "kyb_key_people": "APPROVED"
  }
}

Статусы сессии. NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED, EXPIRED.

Статусы функций. Каждая из kyb_registry, kyb_company_aml, kyb_documents и kyb_key_people сообщает один из следующих статусов: NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED, AWAITING_USER.

Вебхуки. Для сессий: status.updated (изменения жизненного цикла) и data.updated (обогащенные данные), оба содержат session_kind: "business". Для управляемых сущностей: business.status.updated и business.data.updated.

Цена. 2,00 $ за верификацию компании.

Управление бизнес-сущностью

После верификации компания становится сущностью, которой вы управляете через API бизнесов:

  • POST /v3/businesses/create/ — регистрация бизнес-сущности.
  • GET /v3/businesses/ — список управляемых бизнесов.
  • GET /v3/businesses/{vendor_data}/ — получение одного бизнеса по его ссылке vendor_data.
  • PATCH .../update-status/ — изменение статуса сущности.

Сущность имеет свой собственный статус, независимый от сессии верификации: ACTIVE (в хорошем состоянии), FLAGGED (на рассмотрении из-за сигнала риска) или BLOCKED (приостановлена). Это операционный уровень — компания может завершить сессию со статусом APPROVED, а затем быть FLAGGED, потому что мониторинг выявил что-то. Изменения в сущности вызывают события business.status.updated и business.data.updated, чтобы зависимые системы оставались актуальными.

Жизненный цикл от начала до конца

Типичная верификация проходит по уровням по порядку. Сессия открывается со статусом NOT_STARTED, переходит в IN_PROGRESS по мере выполнения функций, и каждая функция разрешается — реестр APPROVED, документы, возможно, RESUB_REQUESTED до получения чистой загрузки, AML компании IN_REVIEW до того, как аналитик очистит совпадение, ключевые лица APPROVED. Когда все функции улажены, сессия получает статус APPROVED, DECLINED или IN_REVIEW. Оттуда компания переходит в управление как ACTIVE сущность, и ее статус может позже измениться на FLAGGED или BLOCKED, как того требует текущий надзор — каждый переход отправляется вам через вебхук.

Сценарии использования

  • Маркетплейсы точно направляют продавцов: повторно отправить документ, завершить KYC бенефициарного владельца или удержать совпадение AML сущности — не отклоняя всю процедуру регистрации.
  • Финтех и банковские платформы поддерживают актуальность записей корпоративных счетов с помощью вебхуков вместо постоянных запросов, а также помечают или блокируют сущности по мере изменения рисков.
  • Кредитные провайдеры отслеживают статус каждой проверки андеррайтинга и обновляют статус заемщика через API управления.
  • Crypto B2B платформы поддерживают аудируемый жизненный цикл каждой контрагентной сущности от верификации до текущего состояния.

Как интегрироваться с Didit

  1. Создайте рабочий процесс. В Business Console создайте рабочий процесс KYB с необходимыми функциями.
  2. Создайте сессию. POST /v3/session/ с вашим workflow_id KYB и ссылкой vendor_data.
  3. Подпишитесь на вебхуки. Обрабатывайте status.updated и data.updated (session_kind: business) для сессий, а также business.status.updated / business.data.updated для управляемых сущностей.
  4. Управляйте сущностями. Используйте POST /v3/businesses/create/, GET /v3/businesses/, GET /v3/businesses/{vendor_data}/ и PATCH .../update-status/, чтобы поддерживать каждую компанию в статусе ACTIVE, FLAGGED или BLOCKED.

Поскольку все это построено на унифицированном API /v3/, та же модель жизненного цикла применяется к KYC, мониторингу и KYB — одна согласованная конечная машина состояний для всей платформы идентификации и борьбы с мошенничеством.

Часто задаваемые вопросы

Какие статусы у сессий KYB?

NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED и EXPIRED.

Какие статусы сообщают отдельные функции?

Каждая из kyb_registry, kyb_company_aml, kyb_documents и kyb_key_people сообщает один из следующих статусов: NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED или AWAITING_USER.

На какие вебхуки мне следует подписаться?

Для сессий: status.updated и data.updatedsession_kind: business). Для управляемых бизнес-сущностей: business.status.updated и business.data.updated.

Как изменить статус компании после верификации?

Используйте API управления — PATCH .../update-status/ — чтобы установить статус сущности на ACTIVE, FLAGGED или BLOCKED.

Сколько стоит верификация KYB?

2,00 $ за компанию за полную верификацию — реестр, бенефициарный владелец, должностные лица и AML компании.

Готовы начать?

Прочитайте обзор верификации бизнеса в документации, посмотрите, как это вписывается в остальную часть платформы на странице продукта «Верификация бизнеса», и проверьте прозрачные цены за каждый вызов на странице с ценами. Когда будете готовы, начните бесплатно — 500 бесплатных KYC-проверок каждый месяц и верификация бизнеса по 2,00 $ за компанию.

Инфраструктура для идентификации и борьбы с мошенничеством.

Единый API для KYC, KYB, мониторинга транзакций и проверки кошельков. Интеграция за 5 минут.

Попросите ИИ кратко изложить эту страницу
Жизненный цикл сессии KYB: статусы и вебхуки | Didit.