Перейти к основному содержанию
Кроссплатформенный плагин Flutter, который оборачивает нативные SDK для iOS и Android и предоставляет единый Dart API для верификации личности.

Репозиторий на GitHub

Исходный код и примеры на GitHub

Пакет на pub.dev

didit_sdk

Нативный SDK: Это рекомендуемый подход для приложений на Flutter. SDK оборачивает нативные SDK для iOS и Android через платформенные каналы, что обеспечивает лучший пользовательский опыт, оптимизированную работу с камерой и полную поддержку NFC.


Требования

Требования к платформам

Биометрическое согласие требует нативный SDK версии 4.10.0 или новее. Для пользователей, на которых распространяется законодательство Иллинойса, Техаса или Колорадо, Didit может запросить явное биометрическое согласие перед первым захватом лица. Релиз Flutter SDK, который закрепляет нативные SDK для iOS и Android версии 4.10.0 или новее, отображает этот шаг. Более ранние версии не могут его показать: их сессии работают как прежде, а решение сообщает, что согласие не было собрано (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Если вы верифицируете пользователей в этих штатах, обновите SDK.

Installation

Или добавьте его вручную в pubspec.yaml:
Затем выполните:

Варианты нативного SDK

didit_sdk включает полный нативный SDK. Чтобы собрать более компактный бинарный файл, подключите вместо него пакет-вариант: он предоставляет точно такой же Dart API и фиксирует соответствующий нативный SDK на обеих платформах:
Подключите ровно один из этих пакетов и импортируйте из выбранного, например package:didit_sdk_core/sdk_flutter.dart.

Настройка iOS

Плагин поддерживает оба менеджера зависимостей iOS во Flutter: Swift Package Manager и CocoaPods.

Swift Package Manager

Если в вашей версии Flutter включена поддержка Swift Package Manager (включается командой flutter config --enable-swift-package-manager в Flutter 3.24+), плагин подключается как Swift-пакет автоматически. Конфигурация Podfile не требуется: нативная зависимость DiditSDK разрешается из GitHub самостоятельно. Установите минимальную версию развёртывания iOS для вашего приложения в Xcode (цель Runner и проект) в соответствии с выбранным пакетом: 15.0 для didit_sdk и didit_sdk_nfc, 13.0 для didit_sdk_core и didit_sdk_autodetection.

CocoaPods

Для didit_sdk плагин выбирает вариант нативного SDK для iOS из $DiditSdkIosVariant, глобальной переменной Ruby, которую вы задаёте в ios/Podfile вашего приложения (пода DiditSDK не опубликована в CocoaPods trunk):
Если вы используете пакет-вариант (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), он фиксирует свой нативный subspec напрямую и игнорирует $DiditSdkIosVariant. Строка pod в вашем Podfile и минимальная версия развёртывания должны соответствовать этому варианту (например, pod 'DiditSDK/Core', :podspec => ... с platform :ios, '13.0').
Варианты all и nfc требуют минимальную версию развёртывания iOS 15.0+; core и autodetection могут использовать iOS 13.0. При переключении вариантов сначала очистите CocoaPods (rm -rf Pods Podfile.lock), чтобы не использовался ранее собранный вариант SDK.
Тег в URL podspec должен совпадать с версией нативного SDK для iOS, которую фиксирует ваш релиз didit_sdk (4.13.2 фиксирует нативный 4.13.2). Если URL указывает на более старый тег, pod install завершится ошибкой разрешения зависимостей: CocoaPods найдёт podspec, объявляющий более старую версию, тогда как плагин требует точного совпадения. При обновлении didit_sdk измените тег в этом URL на ту же версию.

Настройка Android

По умолчанию плагин подключает полный нативный SDK для Android, включая NFC. Чтобы собрать приложение без NFC, добавьте в android/gradle.properties следующую строку:
Это переключает зависимость с me.didit:didit-sdk на me.didit:didit-sdk-core, убирая модуль считывания NFC и его зависимости JMRTD/SCUBA/BouncyCastle. Если NFC включён (по умолчанию), добавьте в android/app/build.gradle.kts следующее правило упаковки, чтобы устранить дублирующийся файл метаданных из BouncyCastle:
Без этого правила сборка завершается ошибкой mergeDebugJavaResource. Правило не нужно, если задано diditSdkAndroidNfcEnabled=false.
Нативный SDK для Android загружается из удалённого Maven-репозитория на GitHub (начиная с плагина 3.4.0), поэтому дополнительная настройка Maven в вашем приложении не требуется.

Разрешения

iOS

Добавьте следующие ключи в Info.plist вашего приложения:
Если отсутствует какой-либо обязательный ключ конфиденциальности iOS, iOS завершит работу приложения, как только SDK попытается обратиться к защищённому ресурсу. Например, при отсутствии NSCameraUsageDescription приложение аварийно завершится, когда пользователь нажмёт кнопку съёмки в камере документов.

Настройка NFC

Чтобы включить чтение NFC для паспортов и ID-карт с чипами:
  1. Добавьте возможность NFC в Xcode:
    • Выберите ваш target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Добавьте идентификаторы ISO7816 в Info.plist:
D392F000260100000001 позволяет SDK читать карту My Number Card (Япония) через JPKI: без него iOS не передаёт карту в SDK. Чтение My Number Card пока не включено в продакшне, а этот идентификатор не влияет на другие документы, поэтому его можно добавить уже сейчас.
  1. Добавьте файл entitlements с включённым чтением NFC-тегов:
Убедитесь, что профиль подготовки приложения включает возможность NFC Tag Reading. Если bundle ID не настроен для NFC в вашем аккаунте Apple Developer, Xcode завершится ошибкой подписи из-за отсутствующего права com.apple.developer.nfc.readersession.formats. Эта настройка NFC не нужна для вариантов core и autodetection ($DiditSdkIosVariant), а также для пакетов didit_sdk_core и didit_sdk_autodetection: ни один из них не читает чипы.

Android

Следующие разрешения объявлены в AndroidManifest.xml SDK и объединяются автоматически: Функции камеры и NFC объявлены как необязательные (android:required="false"), поэтому приложение можно установить на устройства без этих функций. Если diditSdkAndroidNfcEnabled=false, SDK не добавляет разрешение и функцию NFC для Android.

Разрешения во время выполнения

SDK автоматически обрабатывает запросы разрешений Android во время выполнения. Когда пользователь доходит до шага, которому нужен доступ к камере:
  1. SDK запрашивает разрешение на камеру, если оно ещё не предоставлено
  2. Если пользователь отклоняет разрешение, отображается сообщение об ошибке с кнопкой Try Again
  3. Если пользователь предоставляет разрешение, процесс верификации продолжается
Запрашивать разрешение на камеру в коде приложения перед вызовом startVerification() не нужно: SDK управляет этим самостоятельно.

Быстрый старт


Способы интеграции

SDK поддерживает два способа интеграции:

Способ 1: токен сессии (рекомендуется для продакшна)

Создайте сессию на вашем бэкенде с помощью API создания сессии верификации, затем передайте токен в SDK:
Этот подход даёт вам полный контроль над:
  • Связыванием сессий с вашими пользователями (vendor_data)
  • Настройкой пользовательских метаданных
  • Настройкой обратных вызовов для каждой сессии

Способ 2: ID сценария (более простая интеграция)

Для более простых интеграций SDK может создавать сессии напрямую по ID вашего сценария, без бэкенда:
Расширенные параметры сессии (contact_details, expected_details, metadata) поддерживаются только при использовании способа с токеном сессии, когда ваш бэкенд вызывает API создания сессии с полной поддержкой параметров. Передайте полученный session_token в DiditSdk.startVerification().

Конфигурация

Настройте поведение SDK, передав объект DiditConfig:
Для startVerificationWithWorkflow передайте config как именованный параметр:

Параметры конфигурации

Параметры камеры

Параметры камеры совпадают с параметрами камеры Web SDK. Каждый объектив задается значением CameraLens.front или CameraLens.back. Если на устройстве нет запрошенного объектива, SDK использует первую доступную камеру. Переключатель камеры также скрывается на устройствах, где есть только одна камера. Установите для переключателя значение false, чтобы зафиксировать пользователя на объективе по умолчанию для этого шага.
Темы и цвета: цвета, фоны и настройки вступительных экранов задаются через ваши настройки White label в Didit Console, а не в конфигурации SDK. Так обеспечивается единый брендинг на всех платформах.

Поддержка языков

SDK поддерживает 54 языка. Если язык не указан, SDK использует локаль устройства, а в качестве запасного варианта английский.
Посмотреть все поддерживаемые языки →

Расширенные параметры сессии

Такие параметры, как contact_details, expected_details и metadata, поддерживаются только через метод Session Token. Ваш бэкенд вызывает POST /v3/session/ с полной поддержкой параметров, а затем передает возвращенный session_token в SDK.
Метод Dart startVerificationWithWorkflow принимает только workflowId, vendorData и config. Версии до 3.4.0 поддерживали параметры contactDetails, expectedDetails и metadata, но они были удалены, потому что эндпоинт Unilink их не учитывает.

Обработка результатов

Оба метода, startVerification и startVerificationWithWorkflow, возвращают Future<VerificationResult>. Результат представлен sealed-классом: используйте сопоставление с образцом (pattern matching), чтобы определить исход.

Типы результатов

Свойства SessionData

Типы ошибок

Перечисление VerificationErrorType содержит следующие значения:

Потеря соединения

Если во время верификации устройство теряет соединение, SDK перекрывает поток экраном «Нет подключения к интернету» вместо того, чтобы оставлять шаг в состоянии загрузки. SDK продолжает проверять соединение в фоновом режиме и сам закрывает экран, как только Didit снова становится доступен. Пользователь продолжает с того шага, на котором остановился. На экране есть кнопки Повторить и, если кнопка закрытия не отключена, Выйти из верификации. Выход завершает верификацию результатом VerificationFailed с типом ошибки networkError, поэтому ваше приложение узнает, что пользователь ушел из-за потери соединения.

Полный пример обработки результатов


Пример сквозной интеграции (сессия на бэкенде → Flutter SDK → Webhook)

Готовая к продакшену интеграция: ваш бэкенд создает сессию, ваше Flutter-приложение получает session_token, а SDK запускает поток. Итоговое решение доставляется на ваш бэкенд через webhook. Никогда не полагайтесь только на результат на стороне клиента.

1. Бэкенд: создание сессии

2. Flutter: обмен токеном и запуск SDK

3. Бэкенд: получение итогового решения через webhook

Подробности проверки подписи HMAC см. в руководстве по Webhooks.

Полный пример


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