Saltar al contingut principal
Un plugin multiplataforma de Flutter que encapsula els SDK natius d’iOS i Android i ofereix una API unificada en Dart per a la verificació d’identitat.

Repositori de GitHub

Consulta el codi font i els exemples a GitHub

Paquet de pub.dev

didit_sdk

SDK natiu: Aquesta és l’opció recomanada per a les aplicacions de Flutter. El SDK encapsula els SDK natius d’iOS i Android mitjançant canals de plataforma per oferir la millor experiència d’usuari, una gestió de la càmera optimitzada i un suport complet per a NFC.


Requisits

Requisits de plataforma

El consentiment biomètric necessita el SDK natiu 4.10.0 o posterior. Per a persones cobertes per la legislació d’Illinois, Texas o Colorado, Didit pot demanar un consentiment biomètric explícit abans de la primera captura facial. Una versió del SDK de Flutter que fixa el SDK natiu d’iOS i Android 4.10.0 o posterior mostra aquest pas. Les versions anteriors no poden mostrar-lo: les seves sessions funcionen com abans i la decisió indica que el consentiment no s’ha recollit (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Actualitza si verifiques persones en aquests estats.

Instal·lació

O afegeix-lo manualment al teu pubspec.yaml:
Després, executa:

Variants del SDK natiu

didit_sdk inclou el SDK natiu complet. Per reduir la mida del binari, depèn d’un paquet de variant en lloc d’aquest: exposa exactament la mateixa API de Dart i fixa el SDK natiu corresponent a totes dues plataformes.
Depèn d’exactament un d’aquests paquets i importa des del que hagis triat, per exemple package:didit_sdk_core/sdk_flutter.dart.

Configuració d’iOS

El plugin admet els dos gestors de dependències d’iOS de Flutter: Swift Package Manager i CocoaPods.

Swift Package Manager

Si la teva versió de Flutter té activat el suport de Swift Package Manager (activa-ho amb flutter config --enable-swift-package-manager a Flutter 3.24+), el plugin es consumeix automàticament com a paquet Swift. No cal cap configuració del Podfile: la dependència nativa DiditSDK es resol sola des de GitHub. Defineix l’objectiu de desplegament d’iOS de la teva aplicació a Xcode (target Runner i projecte) com a mínim per al paquet que hagis triat: 15.0 per a didit_sdk i didit_sdk_nfc, 13.0 per a didit_sdk_core i didit_sdk_autodetection.

CocoaPods

Amb didit_sdk, el plugin selecciona la variant del SDK natiu d’iOS a partir de $DiditSdkIosVariant, una variable global de Ruby que defineixes al teu ios/Podfile (el pod DiditSDK no és al trunk de CocoaPods):
Si uses un paquet de variant (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), aquest fixa directament el seu subspec natiu i ignora $DiditSdkIosVariant. Mantén la línia pod del teu Podfile i l’objectiu de desplegament coherents amb aquesta variant (per exemple pod 'DiditSDK/Core', :podspec => ... amb platform :ios, '13.0').
Les variants all i nfc requereixen un objectiu de desplegament d’iOS 15.0+; core i autodetection poden apuntar a iOS 13.0. En canviar de variant, neteja primer CocoaPods (rm -rf Pods Podfile.lock) perquè no es reutilitzi la variant anterior del SDK.
L’etiqueta de la URL del podspec ha de coincidir amb la versió del SDK natiu d’iOS que fixa la teva versió de didit_sdk (4.13.2 fixa el natiu 4.13.2). Si la URL apunta a una etiqueta anterior, pod install falla en resoldre: CocoaPods troba un podspec que declara aquella versió anterior, mentre que el plugin requereix una coincidència exacta. En actualitzar didit_sdk, canvia l’etiqueta d’aquesta URL a la mateixa versió.

Configuració d’Android

Per defecte, el plugin depèn del SDK complet d’Android, inclòs NFC. Per compilar sense NFC, afegeix això a android/gradle.properties:
Això canvia la dependència de me.didit:didit-sdk a me.didit:didit-sdk-core, i elimina el mòdul lector NFC i les seves dependències de JMRTD/SCUBA/BouncyCastle. Quan NFC està activat (per defecte), afegeix aquesta regla d’empaquetatge a android/app/build.gradle.kts per resoldre un fitxer de metadades duplicat de BouncyCastle:
Sense aquesta regla, la compilació falla amb un error de mergeDebugJavaResource. La regla no cal quan diditSdkAndroidNfcEnabled=false.
El SDK natiu d’Android es resol des d’un repositori Maven remot de GitHub (des del plugin 3.4.0): no cal cap configuració manual de Maven a la teva aplicació.

Permisos

iOS

Afegeix les claus següents al fitxer Info.plist de la teva aplicació:
Si falta alguna clau de privacitat obligatòria d’iOS, iOS tanca l’aplicació en el moment en què el SDK intenta accedir a aquest recurs protegit. Per exemple, si falta NSCameraUsageDescription, l’aplicació es bloqueja quan l’usuari toca el botó de fer una foto de la càmera de documents.

Configuració de NFC

Per activar la lectura NFC de passaports i targetes d’identitat amb xip:
  1. Afegeix la capacitat NFC a Xcode:
    • Selecciona el teu objectiu > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Afegeix els identificadors ISO7816 a Info.plist:
D392F000260100000001 permet que el SDK llegeixi la targeta My Number del Japó a través de JPKI: sense aquest identificador, iOS no informa el SDK de la targeta. La lectura de My Number Card encara no està habilitada en producció, i l’identificador no canvia res per a la resta de documents, així que el pots afegir ara.
  1. Afegeix un fitxer d’entitlements amb la lectura d’etiquetes NFC activada:
Assegura’t que el perfil d’aprovisionament de l’aplicació inclou la capacitat NFC Tag Reading. Si el bundle ID no està configurat per a NFC al teu compte d’Apple Developer, Xcode fallarà en la signatura perquè falta el dret com.apple.developer.nfc.readersession.formats. Aquesta configuració de NFC no és necessària per a les variants core o autodetection ($DiditSdkIosVariant), ni per als paquets didit_sdk_core / didit_sdk_autodetection: cap d’aquests llegeix xips.

Android

Els permisos següents es declaren al fitxer AndroidManifest.xml del SDK i es fusionen automàticament: Les funcionalitats de maquinari de càmera i NFC es declaren com a opcionals (android:required="false"), de manera que la teva aplicació es pot instal·lar en dispositius sense aquestes funcionalitats. Quan diditSdkAndroidNfcEnabled=false, el SDK no afegeix el permís ni la funcionalitat NFC d’Android.

Permisos en temps d’execució

El SDK gestiona automàticament les sol·licituds de permisos en temps d’execució d’Android. Quan l’usuari arriba a un pas que requereix accés a la càmera:
  1. El SDK demana el permís de càmera si encara no s’ha concedit
  2. Si l’usuari denega el permís, es mostra un missatge d’error amb un botó Torna-ho a provar
  3. Si l’usuari concedeix el permís, el flux de verificació continua
No cal que sol·licitis el permís de càmera al codi de la teva aplicació abans de cridar startVerification(): el SDK ho gestiona internament.

Inici ràpid


Mètodes d’integració

El SDK admet dos mètodes d’integració:

Mètode 1: token de sessió (recomanat per a producció)

Crea una sessió al teu backend amb l’API de creació de sessions de verificació i després passa el token al SDK:
Aquest enfocament et dona control total sobre:
  • Associar les sessions amb els teus usuaris (vendor_data)
  • Definir metadades personalitzades
  • Configurar funcions de retorn per sessió

Mètode 2: ID del flux de treball (integració més senzilla)

Per a integracions més senzilles, el SDK pot crear sessions directament amb el teu ID de flux de treball, sense necessitat de backend:
Els paràmetres avançats de sessió (contact_details, expected_details, metadata) només són compatibles amb el mètode de token de sessió, en què el teu backend crida l’API de creació de sessions amb suport complet per als paràmetres. Passa el session_token retornat a DiditSdk.startVerification().

Configuració

Personalitza el comportament de l’SDK passant un objecte DiditConfig:
Per a startVerificationWithWorkflow, passa config com a paràmetre amb nom:

Opcions de configuració

Opcions de càmera

Les opcions de càmera coincideixen amb les opcions de càmera de l’SDK web. Cada objectiu és CameraLens.front o CameraLens.back. Si el dispositiu no té l’objectiu sol·licitat, l’SDK utilitza la primera càmera que tingui. El selector de càmera també s’amaga en dispositius que només tenen una càmera. Estableix una opció del selector a false per bloquejar l’usuari en l’objectiu per defecte d’aquest pas.
Personalització visual i colors: els colors, els fons i la configuració de les pantalles d’introducció es configuren a través de la configuració de Marca blanca a la Didit Console, i no a la configuració de l’SDK. Així es garanteix una imatge de marca coherent a totes les plataformes.

Suport d’idiomes

L’SDK admet 54 idiomes. Si no s’especifica cap idioma, l’SDK utilitza la configuració regional del dispositiu, amb l’anglès com a alternativa.
Consulta tots els idiomes admesos →

Paràmetres avançats de sessió

Paràmetres com contact_details, expected_details i metadata només són compatibles amb el mètode del token de sessió. El backend crida POST /v3/session/ amb suport complet de paràmetres i després passa el session_token retornat a l’SDK.
El mètode Dart startVerificationWithWorkflow només accepta workflowId, vendorData i config. Les versions anteriors a la 3.4.0 exposaven els paràmetres contactDetails, expectedDetails i metadata, però es van eliminar perquè l’endpoint de Unilink no els té en compte.

Gestió de resultats

Tant startVerification com startVerificationWithWorkflow retornen un Future<VerificationResult>. El resultat és una classe segellada: utilitza la coincidència de patrons per determinar el resultat.

Casos de resultat

Propietats de SessionData

Tipus d’error

L’enumeració VerificationErrorType exposa els casos següents:

Connexió perduda

Si el dispositiu perd la connexió durant la verificació, l’SDK mostra una pantalla «Sense connexió a Internet» per sobre del flux en lloc de deixar un pas en estat de càrrega. Segueix comprovant la connexió en segon pla i tanca la pantalla automàticament en el moment en què es pot contactar amb Didit de nou, i l’usuari continua des del pas on era. La pantalla ofereix Torna-ho a provar i, tret que el botó de tancar estigui desactivat, Surt de la verificació. Sortir finalitza la verificació amb un resultat VerificationFailed el tipus d’error del qual és networkError, de manera que la teva aplicació sap que l’usuari ha sortit per la connexió.

Exemple complet de gestió de resultats


Exemple de principi a fi (backend, SDK de Flutter i webhook)

La integració preparada per a producció: el backend crea la sessió, l’aplicació de Flutter rep el session_token i l’SDK executa el flux. La decisió final es lliura al backend mitjançant un webhook: no confiïs mai només en el resultat del client.

1. Backend: crea la sessió

2. Flutter: intercanvia i inicia l’SDK

3. Backend: rep la decisió final mitjançant webhook

Consulta la guia de webhooks per veure els detalls de la verificació de la signatura HMAC.

Exemple complet


Darrera modificació el 7 de novembre del 2026