Dépôt GitHub
Consultez le code source et les exemples sur GitHub
Package pub.dev
didit_sdk
SDK natif : C’est l’approche recommandée pour les applications Flutter. Le SDK encapsule les SDK natifs iOS et Android via des canaux de plateforme pour offrir la meilleure expérience utilisateur, une gestion optimisée de la caméra et une prise en charge complète du NFC.
Prérequis
Prérequis par plateforme
Le consentement biométrique nécessite la version 4.10.0 ou ultérieure des SDK natifs. Pour les personnes soumises aux lois de l’Illinois, du Texas ou du Colorado, Didit peut demander un consentement biométrique explicite avant la première capture du visage. Une version du SDK Flutter qui épingle les SDK natifs iOS et Android en 4.10.0 ou ultérieure affiche cette étape. Les versions antérieures ne peuvent pas l’afficher : leurs sessions se déroulent comme auparavant, et la décision indique que le consentement n’a pas été recueilli (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Mettez à jour si vous vérifiez des personnes dans ces États.Installation
pubspec.yaml :
Variantes du SDK natif
didit_sdk embarque le SDK natif complet.
Pour livrer un binaire plus léger, dépendez plutôt d’un package de variante : il expose exactement la même API Dart et épingle le SDK natif correspondant sur les deux plateformes :
package:didit_sdk_core/sdk_flutter.dart.
Configuration iOS
Le plugin prend en charge les deux gestionnaires de dépendances iOS de Flutter : Swift Package Manager et CocoaPods.Swift Package Manager
Si la prise en charge de Swift Package Manager est activée dans votre version de Flutter (à activer avecflutter config --enable-swift-package-manager sur Flutter 3.24+), le plugin est utilisé automatiquement comme package Swift.
Aucune configuration du Podfile n’est nécessaire : la dépendance native DiditSDK se résout seule depuis GitHub.
Dans Xcode, réglez la cible de déploiement iOS de votre application (cible Runner et projet) sur le minimum requis par le package choisi : 15.0 pour didit_sdk et didit_sdk_nfc, 13.0 pour didit_sdk_core et didit_sdk_autodetection.
CocoaPods
Avecdidit_sdk, le plugin sélectionne la variante du SDK natif iOS à partir de $DiditSdkIosVariant, une variable globale Ruby que vous définissez dans le fichier ios/Podfile de votre application (le pod DiditSDK n’est pas disponible sur CocoaPods trunk) :
didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), il épingle directement sa sous-spécification native et ignore $DiditSdkIosVariant : gardez la ligne pod de votre Podfile et la cible de déploiement alignées sur cette variante (par exemple pod 'DiditSDK/Core', :podspec => ... avec platform :ios, '13.0').
Les variantes
all et nfc nécessitent une cible de déploiement iOS 15.0+ ; core et autodetection peuvent cibler iOS 13.0. Lors d’un changement de variante, nettoyez d’abord CocoaPods (rm -rf Pods Podfile.lock) pour que la variante précédente du SDK ne soit pas réutilisée.Configuration Android
Par défaut, le plugin dépend du SDK Android complet, NFC inclus. Pour compiler sans NFC, ajoutez ceci àandroid/gradle.properties :
me.didit:didit-sdk par me.didit:didit-sdk-core, ce qui supprime le module de lecture NFC et ses dépendances JMRTD, SCUBA et BouncyCastle.
Lorsque le NFC est activé (par défaut), ajoutez cette règle de packaging à android/app/build.gradle.kts pour résoudre un fichier de métadonnées en double provenant de BouncyCastle :
mergeDebugJavaResource. Cette règle n’est pas nécessaire lorsque diditSdkAndroidNfcEnabled=false.
Le SDK natif Android se résout depuis un dépôt Maven GitHub distant (depuis le plugin 3.4.0) : aucune configuration Maven manuelle n’est nécessaire dans votre application.
Autorisations
iOS
Ajoutez les clés suivantes au fichierInfo.plist de votre application :
Configuration NFC
Pour activer la lecture NFC des passeports et des cartes d’identité équipés d’une puce :-
Ajoutez la capacité NFC dans Xcode :
- Sélectionnez votre cible > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
Ajoutez les identifiants ISO7816 au fichier
Info.plist:
D392F000260100000001 permet au SDK de lire la carte My Number du Japon via JPKI : sans cet identifiant, iOS ne signale pas la carte au SDK. La lecture de la carte My Number n’est pas encore activée en production, et cet identifiant n’a aucun effet sur les autres documents : vous pouvez donc l’ajouter dès maintenant.
- Ajoutez un fichier d’entitlements avec la lecture des tags NFC activée :
com.apple.developer.nfc.readersession.formats.
Cette configuration NFC n’est pas nécessaire pour les variantes core ou autodetection ($DiditSdkIosVariant), ni pour les packages didit_sdk_core et didit_sdk_autodetection, car aucun d’entre eux ne lit les puces.
Android
Les autorisations suivantes sont déclarées dans le fichierAndroidManifest.xml du SDK et fusionnées automatiquement :
Les fonctionnalités matérielles de caméra et de NFC sont déclarées comme facultatives (
android:required="false"), afin que votre application puisse être installée sur des appareils dépourvus de ces fonctionnalités. Lorsque diditSdkAndroidNfcEnabled=false, le SDK n’ajoute ni l’autorisation NFC ni la fonctionnalité NFC Android.
Autorisations à l’exécution
Le SDK gère automatiquement les demandes d’autorisations Android à l’exécution. Lorsque l’utilisateur atteint une étape qui nécessite l’accès à la caméra :- Le SDK demande l’autorisation d’accès à la caméra si elle n’a pas encore été accordée
- Si l’utilisateur refuse l’autorisation, un message d’erreur s’affiche avec un bouton Try Again
- Si l’utilisateur accorde l’autorisation, le parcours de vérification se poursuit
startVerification() : le SDK gère cela en interne.
Démarrage rapide
Méthodes d’intégration
Le SDK prend en charge deux méthodes d’intégration :Méthode 1 (token de session, recommandée en production)
Créez une session sur votre backend à l’aide de l’API de création d’une session de vérification, puis transmettez le token au SDK :- L’association des sessions à vos utilisateurs (
vendor_data) - La définition de métadonnées personnalisées
- La configuration des callbacks par session
Méthode 2 (ID de workflow, intégration simplifiée)
Pour des intégrations plus simples, le SDK peut créer directement des sessions à partir de votre ID de workflow, sans backend :Les paramètres avancés de session (
contact_details, expected_details, metadata) ne sont pris en charge que par la méthode du token de session, où votre backend appelle l’API de création de session avec la prise en charge complète des paramètres. Transmettez le session_token renvoyé à DiditSdk.startVerification().Configuration
Personnalisez le comportement du SDK en passant un objetDiditConfig :
startVerificationWithWorkflow, passez config comme paramètre nommé :
Options de configuration
Options de caméra
Les options de caméra correspondent aux options de caméra du SDK Web. Chaque objectif estCameraLens.front ou CameraLens.back.
Si l’appareil ne dispose pas de l’objectif demandé, le SDK utilise la première caméra disponible.
Le bouton de changement de caméra est aussi masqué sur les appareils qui n’ont qu’une seule caméra.
Définissez une option de changement de caméra sur false pour verrouiller l’utilisateur sur l’objectif par défaut de cette étape.
Thème et couleurs : les couleurs, les arrière-plans et les réglages de l’écran d’introduction se configurent dans vos paramètres de marque blanche dans la Didit Console, et non dans la configuration du SDK. Cela garantit une identité visuelle cohérente sur toutes les plateformes.
Prise en charge des langues
Le SDK prend en charge 54 langues. Si aucune langue n’est spécifiée, le SDK utilise les paramètres régionaux de l’appareil, avec l’anglais comme langue de repli.Paramètres de session avancés
Les paramètres commecontact_details, expected_details et metadata sont uniquement pris en charge avec la méthode du token de session. Votre backend appelle POST /v3/session/ avec la prise en charge complète des paramètres, puis transmet le session_token renvoyé au SDK.
La méthode Dart
startVerificationWithWorkflow n’accepte que workflowId, vendorData et config. Les versions antérieures à la 3.4.0 exposaient les paramètres contactDetails, expectedDetails et metadata, mais ils ont été supprimés, car l’endpoint Unilink ne les prend pas en compte.Gestion des résultats
startVerification et startVerificationWithWorkflow renvoient toutes deux un Future<VerificationResult>. Le résultat est une classe scellée : utilisez la correspondance de motifs pour déterminer le résultat.
Cas de résultat
Propriétés de SessionData
Types d’erreur
L’énumérationVerificationErrorType expose les cas suivants :
Perte de connexion
Si l’appareil perd sa connexion pendant la vérification, le SDK recouvre le parcours d’un écran « Pas de connexion Internet » au lieu de laisser une étape se charger indéfiniment. Il continue de vérifier la connexion en arrière-plan et ferme l’écran automatiquement dès que Didit redevient joignable. L’utilisateur reprend alors à l’étape où il se trouvait. L’écran propose Réessayer et, sauf si le bouton de fermeture est désactivé, Quitter la vérification. Quitter met fin à la vérification avec un résultatVerificationFailed dont le type d’erreur est networkError, ce qui permet à votre application de savoir que l’utilisateur est parti à cause de la connexion.
Exemple complet de gestion des résultats
Exemple de bout en bout (session backend → SDK Flutter → webhook)
Il s’agit de l’intégration prête pour la production : votre backend crée la session, votre application Flutter reçoit lesession_token, et le SDK exécute le parcours. La décision finale est transmise à votre backend par webhook. Ne faites jamais confiance au seul résultat côté client.