Saltar al contenido principal
Un plugin multiplataforma de Flutter que encapsula los SDK nativos de iOS y Android y ofrece una API de Dart unificada para la verificación de identidad.

Repositorio de GitHub

Consulta el código fuente y los ejemplos en GitHub

Paquete de pub.dev

didit_sdk

SDK nativo: Es el enfoque recomendado para apps de Flutter. El SDK envuelve los SDK nativos de iOS y Android mediante platform channels para ofrecer la mejor experiencia de usuario, una gestión optimizada de la cámara y compatibilidad completa con NFC.


Requisitos

Requisitos de plataforma

El consentimiento biométrico requiere la versión nativa 4.10.0 o posterior. Para las personas amparadas por la legislación de Illinois, Texas o Colorado, Didit puede solicitar un consentimiento biométrico explícito antes de la primera captura facial. Las versiones del SDK de Flutter que fijan los SDK nativos de iOS y Android en 4.10.0 o posterior muestran ese paso. Las versiones anteriores no pueden mostrarlo: sus sesiones se ejecutan como hasta ahora y la decisión indica que el consentimiento no se recopiló (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Actualiza si verificas a personas en esos estados.

Instalación

O añádelo manualmente a tu pubspec.yaml:
Después ejecuta:

Variantes del SDK nativo

didit_sdk incluye el SDK nativo completo. Para distribuir un binario más pequeño, usa como dependencia un paquete de variante: expone exactamente la misma API de Dart y fija el SDK nativo correspondiente en ambas plataformas:
Usa como dependencia exactamente uno de estos paquetes e importa desde el que hayas elegido, por ejemplo package:didit_sdk_core/sdk_flutter.dart.

Configuración de iOS

El plugin es compatible con los dos gestores de dependencias de iOS de Flutter: Swift Package Manager y CocoaPods.

Swift Package Manager

Si tu versión de Flutter tiene habilitada la compatibilidad con Swift Package Manager (actívala con flutter config --enable-swift-package-manager en Flutter 3.24+), el plugin se integra automáticamente como paquete de Swift. No hace falta configurar el Podfile: la dependencia nativa DiditSDK se resuelve desde GitHub por sí sola. Establece en Xcode el deployment target de iOS de tu app (target Runner y proyecto) en el valor mínimo correspondiente al paquete elegido: 15.0 para didit_sdk y didit_sdk_nfc, 13.0 para didit_sdk_core y didit_sdk_autodetection.

CocoaPods

Con didit_sdk, el plugin selecciona la variante del SDK nativo de iOS a partir de $DiditSdkIosVariant, una variable global de Ruby que defines en el ios/Podfile de tu app (el pod DiditSDK no está en el trunk de CocoaPods):
Si usas un paquete de variante (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), este fija directamente su subspec nativo e ignora $DiditSdkIosVariant: mantén la línea pod y el deployment target de tu Podfile acordes con esa variante (por ejemplo, pod 'DiditSDK/Core', :podspec => ... con platform :ios, '13.0').
Las variantes all y nfc requieren un deployment target de iOS 15.0+; core y autodetection pueden usar iOS 13.0. Al cambiar de variante, limpia primero CocoaPods (rm -rf Pods Podfile.lock) para que no se reutilice la variante anterior del SDK.
La etiqueta de la URL del podspec debe coincidir con la versión del SDK nativo de iOS que fija tu versión de didit_sdk (4.9.1 fija la versión nativa 4.9.1). Si la URL apunta a una etiqueta anterior, pod install no logra resolver la dependencia: CocoaPods encuentra un podspec que declara esa versión anterior, mientras que el plugin exige una coincidencia exacta. Cuando actualices didit_sdk, cambia la etiqueta de esta URL a la misma versión.

Configuración de Android

De forma predeterminada, el plugin depende del SDK completo de Android, que incluye NFC. Para compilar sin NFC, añade esto a android/gradle.properties:
Esto cambia la dependencia de me.didit:didit-sdk a me.didit:didit-sdk-core, lo que elimina el módulo lector NFC y sus dependencias JMRTD/SCUBA/BouncyCastle. Cuando NFC está habilitado (opción predeterminada), añade esta regla de empaquetado a android/app/build.gradle.kts para resolver un archivo de metadatos duplicado procedente de BouncyCastle:
Sin esta regla, la compilación falla con un error mergeDebugJavaResource. La regla no es necesaria cuando diditSdkAndroidNfcEnabled=false.
El SDK nativo de Android se resuelve desde un repositorio Maven remoto en GitHub (desde la versión 3.4.0 del plugin): no hace falta ninguna configuración manual de Maven en tu app.

Permisos

iOS

Añade las siguientes claves al Info.plist de tu aplicación:
Si falta alguna clave de privacidad obligatoria de iOS, iOS cierra la aplicación en cuanto el SDK intenta acceder a ese recurso protegido. Por ejemplo, si falta NSCameraUsageDescription, la aplicación falla cuando el usuario pulsa el botón para tomar fotos de la cámara de documentos.

Configuración de NFC

Para habilitar la lectura NFC de pasaportes y documentos de identidad con chip:
  1. Añade la capacidad NFC en Xcode:
    • Selecciona tu target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Añade los identificadores ISO7816 a Info.plist:
D392F000260100000001 permite que el SDK lea la tarjeta My Number de Japón mediante JPKI: sin él, iOS no comunica la tarjeta al SDK. La lectura de la tarjeta My Number todavía no está habilitada en producción, y el identificador no afecta a los demás documentos, así que puedes añadirlo ya.
  1. Añade un archivo de entitlements con la lectura de etiquetas NFC habilitada:
Asegúrate de que el perfil de aprovisionamiento de la aplicación incluya la capacidad NFC Tag Reading. Si el bundle ID no está configurado para NFC en tu cuenta de Apple Developer, Xcode fallará al firmar por falta del entitlement com.apple.developer.nfc.readersession.formats. Esta configuración de NFC no es necesaria para las variantes core o autodetection ($DiditSdkIosVariant), ni para los paquetes didit_sdk_core / didit_sdk_autodetection: ninguno de ellos lee chips.

Android

Los siguientes permisos están declarados en el AndroidManifest.xml del SDK y se fusionan automáticamente: Las características de hardware de cámara y NFC se declaran como opcionales (android:required="false"), de modo que tu aplicación puede instalarse en dispositivos que no las tengan. Cuando diditSdkAndroidNfcEnabled=false, el SDK no añade el permiso ni la característica NFC de Android.

Permisos en tiempo de ejecución

El SDK gestiona automáticamente las solicitudes de permisos en tiempo de ejecución de Android. Cuando el usuario llega a un paso que requiere acceso a la cámara:
  1. El SDK solicita el permiso de cámara si aún no se ha concedido
  2. Si el usuario deniega el permiso, se muestra un mensaje de error con un botón Try Again
  3. Si el usuario concede el permiso, el flujo de verificación continúa
No necesitas solicitar el permiso de cámara en el código de tu aplicación antes de invocar startVerification(): el SDK lo gestiona internamente.

Inicio rápido


Métodos de integración

El SDK admite dos métodos de integración:

Método 1: token de sesión (recomendado para producción)

Crea una sesión en tu backend con la API de creación de sesiones de verificación y luego pasa el token al SDK:
Este enfoque te da control total sobre:
  • La asociación de las sesiones con tus usuarios (vendor_data)
  • La definición de metadatos personalizados
  • La configuración de callbacks por sesión

Método 2: ID de workflow (integración más sencilla)

Para integraciones más sencillas, el SDK puede crear sesiones directamente con el ID de tu flujo de verificación (workflow), sin necesidad de backend:
Los parámetros avanzados de sesión (contact_details, expected_details, metadata) solo se admiten con el método de token de sesión, en el que tu backend llama a la API de creación de sesiones que admite todos los parámetros. Pasa el session_token devuelto a DiditSdk.startVerification().

Configuración

Personaliza el comportamiento del SDK pasando un objeto DiditConfig:
Con startVerificationWithWorkflow, pasa config como parámetro con nombre:

Opciones de configuración

Opciones de cámara

Las opciones de cámara coinciden con las opciones de cámara del Web SDK. Cada lente es CameraLens.front o CameraLens.back. Si el dispositivo no tiene la lente solicitada, el SDK usa la primera cámara disponible. El selector de cámara también se oculta en los dispositivos que solo tienen una cámara. Establece una opción del selector en false para restringir al usuario a la lente por defecto de ese paso.
Temas y colores: los colores, los fondos y la configuración de la pantalla inicial se definen en tu configuración de Marca blanca en la Didit Console, no en la configuración del SDK. Así se garantiza una imagen de marca coherente en todas las plataformas.

Idiomas compatibles

El SDK es compatible con 54 idiomas. Si no se especifica ningún idioma, el SDK usa la configuración regional del dispositivo, con inglés como alternativa.
Ver todos los idiomas compatibles →

Parámetros avanzados de sesión

Los parámetros como contact_details, expected_details y metadata solo son compatibles mediante el método de token de sesión. Tu backend invoca POST /v3/session/ con compatibilidad con todos los parámetros y, después, pasa el session_token devuelto al SDK.
El método startVerificationWithWorkflow de Dart solo acepta workflowId, vendorData y config. Las versiones anteriores a la 3.4.0 exponían los parámetros contactDetails, expectedDetails y metadata, pero se eliminaron porque el endpoint de Unilink no los tiene en cuenta.

Gestión de resultados

Tanto startVerification como startVerificationWithWorkflow devuelven un Future<VerificationResult>. El resultado es una clase sellada: usa la coincidencia de patrones para determinar el desenlace.

Casos de resultado

Propiedades de SessionData

Tipos de error

El enum VerificationErrorType expone los siguientes casos:

Pérdida de conexión

Si el dispositivo pierde la conexión durante la verificación, el SDK muestra una pantalla de “Sin conexión a internet” en lugar de dejar un paso cargando. Sigue comprobando la conexión en segundo plano y cierra la pantalla por sí solo en cuanto vuelve a poder comunicarse con Didit, y el usuario continúa desde el paso en el que estaba. La pantalla ofrece Try Again y, salvo que el botón de cierre esté desactivado, Exit Verification. Al salir, la verificación termina con un resultado VerificationFailed cuyo tipo de error es networkError, para que tu aplicación sepa que el usuario salió debido a la pérdida de conexión.

Ejemplo completo de gestión de resultados


Ejemplo de extremo a extremo (sesión en el backend → Flutter SDK → webhook)

La integración lista para producción: tu backend crea la sesión, tu aplicación Flutter recibe el session_token y el SDK ejecuta el flujo. La decisión final se entrega a tu backend mediante webhook: nunca confíes únicamente en el resultado del lado del cliente.

1. Backend: crea la sesión

2. Flutter: intercambia el token e inicia el SDK

3. Backend: recibe la decisión final mediante webhook

Consulta la guía de webhooks para ver los detalles de la verificación de firma HMAC.

Ejemplo completo


Última modificación el 1 de noviembre de 2026