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
pubspec.yaml:
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:
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 conflutter 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
Condidit_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):
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.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 aandroid/gradle.properties:
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:
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 alInfo.plist de tu aplicación:
Configuración de NFC
Para habilitar la lectura NFC de pasaportes y documentos de identidad con chip:-
Añade la capacidad NFC en Xcode:
- Selecciona tu target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
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.
- Añade un archivo de entitlements con la lectura de etiquetas NFC habilitada:
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 elAndroidManifest.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:- El SDK solicita el permiso de cámara si aún no se ha concedido
- Si el usuario deniega el permiso, se muestra un mensaje de error con un botón Try Again
- Si el usuario concede el permiso, el flujo de verificación continúa
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:- 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 objetoDiditConfig:
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 esCameraLens.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.Parámetros avanzados de sesión
Los parámetros comocontact_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
TantostartVerification 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 enumVerificationErrorType 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 resultadoVerificationFailed 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 elsession_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.