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

​
Как это работает

Предположим, пользователь A прошёл проверку пользователей в Service X и теперь регистрируется у партнёра Service Y. Если Service X согласен передать данные о A сервису Service Y, это можно сделать следующим образом:
  1. Генерация share token (Service X): Service X выполняет вызов API для генерации защищённого короткоживущего share_token для сессии верификации конкретного пользователя. Этот token предназначен исключительно для использования сервисом Service Y. См. Справочник API: Share Session API.
  2. Передача token партнёру (Service X -> Service Y): Service X безопасно передаёт сгенерированный share_token сервису Service Y по предварительно согласованному серверному каналу.
  3. Импорт сессии (Service Y): Service Y использует полученный share_token для вызова API импорта данных пользователя. Это создаёт полную копию сессии верификации, включая все документы и проверки, в собственной среде Service Y. См. Справочник API: Import Shared Session API.

​
Параметры импорта

При импорте сессии Service Y может управлять обработкой результатов с помощью следующих параметров:
  • trust_review: этот булев параметр определяет, доверяет ли Service Y проверке и финальному статусу (Approved/Declined) от Service X.
    • true: сессия копируется с исходным статусом. Пользователь мгновенно проходит онбординг (или отклоняется) в Service Y.
    • false: данные сессии копируются, но статус автоматически устанавливается в In Review. Это позволяет Service Y использовать собранные документы и данные, но провести собственный внутренний процесс проверки для принятия окончательного решения.
  • workflow_id: Service Y должен указать, с каким из его собственных сценариев верификации следует связать импортированную сессию.
  • vendor_data: Service Y может присвоить импортированной сессии собственный внутренний идентификатор пользователя.

​
Важные замечания

  • Только завершённые сессии: share token можно сгенерировать только для сессий с завершённым статусом (Approved, Declined, In Review).
  • Без дубликатов: конкретную сессию можно импортировать в данное партнёрское приложение только один раз. Последующие попытки будут отклонены.

​
Многоразовый KYC в сравнении с передачей KYC через API

Хотя обе функции обеспечивают повторное использование данных идентификации, они служат разным целям:

​
❗️ Важно: ограничения на передачу данных

Передача персональных данных пользователей между различными организациями регулируется строгими правовыми и нормативными требованиями. Перед использованием этой функции ваша организация несёт ответственность за обеспечение полного соответствия всем применимым законам о защите данных, таким как GDPR в Европейском союзе и UK GDPR в Великобритании. Вы должны:
  1. Установить законное основание: убедитесь, что у вас есть законное основание для передачи данных. Часто для этого требуется явное соглашение об обмене данными между вами и вашей партнёрской организацией.
  2. Обеспечить согласие пользователя: убедитесь, что ваши пользователи должным образом проинформированы и дали согласие на передачу своих данных вашим партнёрам, как указано в ваших условиях обслуживания и политике конфиденциальности.
  3. Корректно организовать трансграничную передачу: если данные передаются через границу (например, из ЕС в страну, не входящую в ЕС), вы должны обеспечить применение надлежащих мер защиты в соответствии с требованиями законодательства.
Didit предоставляет техническую возможность для обмена данными, но все юридические обязательства и обязательства по соблюдению требований, связанные с передаваемыми данными, лежат исключительно на вашей организации и ваших партнёрах. Мы настоятельно рекомендуем проконсультироваться с вашим юридическим консультантом перед внедрением этой функции.
Последнее изменение 7 ноября 2026 г.