Passer au contenu principal
Un SDK React Native multiplateforme qui encapsule les SDK natifs iOS et Android et fournit une API TypeScript unifiée pour la vérification d’identité.

Dépôt GitHub

Consultez le code source et les exemples sur GitHub

Package npm

@didit-protocol/sdk-react-native

SDK natif : c’est l’approche recommandée pour les applications React Native et Expo. Le SDK encapsule les SDK natifs iOS et Android 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 de plateforme

Le consentement biométrique nécessite la version native 4.10.0 ou ultérieure. Pour les personnes couvertes par les lois de l’Illinois, du Texas ou du Colorado, Didit peut demander un consentement biométrique explicite avant la première capture de visage. Une version du SDK React Native qui verrouille les SDK natifs iOS et Android sur la version 4.10.0 ou une version 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 à niveau si vous vérifiez des personnes dans ces États.

Installation

Expo (recommandé)

Ajoutez ensuite le plugin de configuration à votre app.json (ou app.config.js). Le NFC est activé par défaut :
Le plugin configure automatiquement les deux plateformes :
  • Android : ajoute le dépôt Maven de Didit à Gradle, définit la propriété Gradle diditSdkAndroidNfcEnabled et applique les règles de dépendances et de packaging pour BouncyCastle
  • iOS : ajoute le podspec DiditSDK au Podfile (fixé à iOS 15 lorsque le NFC est activé)
Le plugin ne modifie pas Info.plist. Ajoutez les clés d’autorisation iOS et, pour le NFC, les identifiants de sélection ISO7816 sous ios.infoPlist dans le même fichier. D392F000260100000001 permet au SDK de lire la Japan My Number Card via JPKI :

Désactiver les dépendances NFC

Pour compiler sans prise en charge du NFC (binaire plus léger, aucune capacité NFC requise), transmettez les options du plugin :
Lorsque le NFC est désactivé, vous n’avez pas besoin de la capacité NFC iOS, des droits NFC ni de la configuration de provisioning liée au NFC.
Ce SDK utilise des modules natifs (caméra, NFC) qui ne sont pas disponibles dans Expo Go. Vous devez utiliser un build de développement ou exécuter npx expo prebuild pour générer les projets natifs.

React Native CLI

Configuration iOS

Ajoutez le pod DiditSDK à votre Podfile (il n’est pas disponible sur le dépôt CocoaPods trunk). Le bloc ci-dessous accepte une variable d’environnement DIDIT_SDK_IOS_NFC_ENABLED, qui vous permet de basculer vers le subspec sans NFC (DiditSDK/Core) au moment de l’installation :
La balise de l’URL du podspec doit correspondre à diditNativeSdkVersions.ios de la version du package installée. React Native 4.13.2 fixe le SDK natif iOS 4.13.2 et le SDK natif Android 4.13.2. Ne faites pas pointer le podspec vers main : le package dépend de cette version exacte du SDK natif iOS. Dès que main prend de l’avance, CocoaPods détecte deux exigences incompatibles pour DiditSDK et chaque pod install échoue. Le plugin de configuration Expo calcule cette URL pour vous ; seul le chemin React Native CLI pur doit la saisir manuellement.
Installez ensuite les dépendances :
Pour recompiler sans les dépendances NFC, nettoyez CocoaPods et relancez l’installation avec la variable d’environnement définie :

Configuration Android

Ajoutez le dépôt Maven de Didit à votre settings.gradle au niveau du projet :
Ajoutez ce qui suit dans android/app/build.gradle de votre application (à l’intérieur du bloc android { ... }) afin de résoudre les conflits de classes en double de BouncyCastle, ainsi que le doublon MANIFEST.MF OSGi que peuvent provoquer les dépendances transitives du DiditSDK :
Pour compiler sans les dépendances NFC Android (utilise l’artefact me.didit:didit-sdk-core au lieu de me.didit:didit-sdk), ajoutez ceci dans android/gradle.properties :
Supprimez cette propriété, ou définissez-la à true, pour utiliser le SDK Android complet avec le NFC.

Autorisations

iOS

Ajoutez les clés suivantes au fichier Info.plist de votre application. Si des clés de confidentialité iOS obligatoires sont manquantes, iOS arrêtera immédiatement l’application dès que le SDK tentera d’accéder à la ressource protégée.

Configuration NFC

Pour activer la lecture NFC des passeports et des cartes d’identité à puce :
  1. Ajoutez la fonctionnalité NFC dans Xcode :
    • Sélectionnez votre cible > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Ajoutez les identifiants ISO7816 à Info.plist :
D392F000260100000001 permet au SDK de lire la carte japonaise My Number via JPKI : sans cet identifiant, iOS ne transmet pas la carte au SDK. La lecture de la carte My Number n’est pas encore activée en production, et cet identifiant ne modifie rien pour les autres documents, vous pouvez donc l’ajouter dès maintenant.
  1. Ajoutez un fichier d’entitlements avec la lecture d’étiquettes NFC activée :
Assurez-vous que le profil de provisionnement de l’application inclut la fonctionnalité NFC Tag Reading. Cette configuration NFC n’est pas nécessaire lorsque le NFC est désactivé.

Android

Les autorisations suivantes sont déclarées dans le fichier AndroidManifest.xml du SDK et fusionnées automatiquement : Les fonctionnalités matérielles liées à la caméra et au NFC sont déclarées comme optionnelles (android:required="false"). Votre application peut donc être installée sur des appareils qui ne disposent pas de ces fonctionnalités.

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 pour la production)

Créez une session sur votre backend à l’aide de l’API de création de session de vérification, puis transmettez le token au SDK :
Cette approche vous offre un contrôle total sur :
  • 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 plus simple)

Pour des intégrations plus simples, le SDK peut créer des sessions directement à l’aide de votre ID de workflow :

Configuration

Personnalisez le comportement du SDK en transmettant un objet DiditConfig :
Pour startVerificationWithWorkflow, transmettez la configuration dans options.config :

Options de configuration

Options de caméra

Les options de caméra correspondent aux options de caméra du SDK Web. Chaque objectif correspond à CameraLens.Front ou CameraLens.Back. Si l’appareil ne dispose pas de l’objectif demandé, le SDK utilise la première caméra disponible. Le sélecteur de caméra est également masqué sur les appareils ne disposant que d’une seule caméra. Définissez une option de changement de caméra sur false pour contraindre l’utilisateur à l’objectif par défaut de cette étape.
Thèmes et couleurs : Les couleurs, les arrière-plans et les paramètres de l’écran d’introduction sont configurés dans vos paramètres de marque blanche sur la Console Didit, et non dans la configuration du SDK. Cela garantit une cohérence de marque sur toutes les plateformes.

Prise en charge linguistique

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 secours.
Voir toutes les langues prises en charge →

Options avancées

Ces options sont uniquement disponibles avec startVerificationWithWorkflow, où le SDK crée la session pour votre compte.

Coordonnées (préremplissage et notifications)

Fournissez des coordonnées pour préremplir les formulaires de vérification et activer les notifications par e-mail :

Informations attendues (validation croisée)

Fournissez les informations utilisateur attendues pour une validation croisée automatique avec les données extraites du document :
Tous les champs de ExpectedDetails sont optionnels. Consultez src/types.ts pour le type complet.

Métadonnées personnalisées

Enregistrez des métadonnées JSON personnalisées avec la session (non affichées à l’utilisateur) :

Traitement des résultats

startVerification et startVerificationWithWorkflow renvoient tous deux une Promise<VerificationResult>. Le résultat est une union discriminée — utilisez le champ type pour déterminer l’issue.

Cas de résultat

Propriétés de SessionData

Types d’erreur

Perte de connexion

Si l’appareil perd sa connexion pendant la vérification, le SDK affiche un écran « Pas de connexion Internet » par-dessus le flux au lieu de laisser une étape en chargement. Il continue à vérifier en arrière-plan et ferme automatiquement l’écran dès que Didit est de nouveau joignable, et l’utilisateur reprend à l’étape où il s’était arrêté. L’écran propose Réessayer et, lorsque showCloseButton est défini sur true (valeur par défaut), Quitter la vérification. Quitter interrompt la vérification avec un résultat failed dont l’erreur est networkError, afin que votre application sache que l’utilisateur est parti en raison de la connexion.

Exemple complet de traitement des résultats


Exemple de bout en bout (Session backend → SDK React Native → Webhook)

L’intégration prête pour la production : votre backend crée la session, votre application RN reçoit le session_token, et le SDK exécute le flux. La décision finale est transmise à votre backend par webhook — ne vous fiez jamais uniquement au résultat côté client.

1. Backend — créer la session

2. React Native — échanger et lancer le SDK

3. Backend — recevoir la décision finale par webhook

Consultez le guide sur les webhooks pour les détails sur la vérification de signature HMAC.

Exemple complet


Dernière modification le 7 novembre 2026