Vai al contenuto principale
Un plugin Flutter multipiattaforma che incapsula gli SDK nativi per iOS e Android, offrendo un’API Dart unificata per la verifica dell’identità.

Repository GitHub

Visualizza il codice sorgente e gli esempi su GitHub

Pacchetto pub.dev

didit_sdk

SDK nativo: È l’approccio consigliato per le app Flutter. L’SDK incapsula gli SDK nativi per iOS e Android tramite i canali della piattaforma, per offrire la migliore esperienza utente, una gestione ottimizzata della fotocamera e il pieno supporto NFC.


Requisiti

Requisiti della piattaforma

Il consenso biometrico richiede la versione nativa 4.10.0 o successiva. Per le persone soggette alle leggi dell’Illinois, del Texas o del Colorado, Didit può chiedere un consenso biometrico esplicito prima della prima acquisizione del volto. Una release dell’SDK Flutter che fissa gli SDK nativi iOS e Android alla versione 4.10.0 o successiva mostra questo passaggio. Le versioni precedenti non possono mostrarlo: le loro sessioni proseguono come prima, e la decisione riporta il consenso come non raccolto (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Esegui l’aggiornamento se verifichi persone in questi stati.

Installazione

Oppure aggiungilo manualmente al tuo pubspec.yaml:
Poi esegui:

Varianti dell’SDK nativo

didit_sdk include l’SDK nativo completo. Per ottenere un binario più leggero, dipendi invece da un pacchetto alternativo: espone esattamente la stessa API Dart e fissa l’SDK nativo corrispondente su entrambe le piattaforme:
Dichiara una dipendenza da uno solo di questi pacchetti e importa da quello che hai scelto, ad esempio package:didit_sdk_core/sdk_flutter.dart.

Configurazione iOS

Il plugin supporta entrambi i gestori di dipendenze iOS di Flutter: Swift Package Manager e CocoaPods.

Swift Package Manager

Se la tua versione di Flutter ha il supporto a Swift Package Manager abilitato (attivalo esplicitamente con flutter config --enable-swift-package-manager su Flutter 3.24+), il plugin viene utilizzato automaticamente come pacchetto Swift. Non serve alcuna configurazione del Podfile: la dipendenza nativa DiditSDK viene risolta autonomamente da GitHub. Imposta il deployment target iOS della tua app in Xcode (target Runner e progetto) al minimo previsto per il pacchetto scelto: 15.0 per didit_sdk e didit_sdk_nfc, 13.0 per didit_sdk_core e didit_sdk_autodetection.

CocoaPods

Con didit_sdk, il plugin seleziona la variante dell’SDK nativo iOS da $DiditSdkIosVariant, una variabile globale Ruby che imposti nel file ios/Podfile della tua app (il pod DiditSDK non è disponibile su CocoaPods trunk):
Se utilizzi un pacchetto alternativo (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), esso fissa direttamente il proprio subspec nativo e ignora $DiditSdkIosVariant: mantieni la riga pod del tuo Podfile e il deployment target allineati a quella variante (ad esempio pod 'DiditSDK/Core', :podspec => ... con platform :ios, '13.0').
Le varianti all e nfc richiedono un deployment target iOS 15.0+; core e autodetection possono avere come target iOS 13.0. Quando cambi variante, pulisci prima CocoaPods (rm -rf Pods Podfile.lock) in modo che la variante SDK precedente non venga riutilizzata.
Il tag nell’URL del podspec deve corrispondere alla versione dell’SDK nativo iOS fissata dalla tua release di didit_sdk (4.13.2 fissa l’SDK nativo 4.13.2). Se l’URL punta a un tag più vecchio, pod install non riesce a risolvere la dipendenza: CocoaPods trova un podspec che dichiara quella versione più vecchia, mentre il plugin richiede una corrispondenza esatta. Quando aggiorni didit_sdk, aggiorna il tag in questo URL alla stessa versione.

Configurazione Android

Per impostazione predefinita il plugin dipende dall’SDK Android completo, NFC incluso. Per compilare senza NFC, aggiungi questa riga a android/gradle.properties:
Questo sostituisce la dipendenza da me.didit:didit-sdk con me.didit:didit-sdk-core, rimuovendo il modulo di lettura NFC e le sue dipendenze JMRTD/SCUBA/BouncyCastle. Quando l’NFC è abilitato (impostazione predefinita), aggiungi questa regola di packaging a android/app/build.gradle.kts per risolvere un file di metadati duplicato di BouncyCastle:
Senza questa regola la compilazione fallisce con un errore mergeDebugJavaResource. La regola non serve quando diditSdkAndroidNfcEnabled=false.
L’SDK nativo Android viene risolto da un repository Maven remoto su GitHub (dalla versione 3.4.0 del plugin): nella tua app non serve alcuna configurazione Maven manuale.

Permessi

iOS

Aggiungi le seguenti chiavi al file Info.plist della tua app:
Se manca una qualsiasi chiave obbligatoria relativa alla privacy di iOS, iOS termina l’app non appena l’SDK tenta di accedere a quella risorsa protetta. Ad esempio, se manca NSCameraUsageDescription, l’app si blocca quando l’utente tocca il pulsante di scatto della fotocamera per i documenti.

Configurazione NFC

Per abilitare la lettura NFC di passaporti e carte d’identità dotati di chip:
  1. Aggiungi la funzionalità NFC in Xcode:
    • Seleziona il tuo target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Aggiungi gli identificatori ISO7816 a Info.plist:
D392F000260100000001 consente all’SDK di leggere la Japan My Number Card tramite JPKI: senza questo identificatore, iOS non segnala la carta all’SDK. La lettura della My Number Card non è ancora abilitata in produzione e l’identificatore non modifica nulla per gli altri documenti, quindi puoi aggiungerlo fin da ora.
  1. Aggiungi un file di entitlements con la lettura dei tag NFC abilitata:
Assicurati che il profilo di provisioning dell’app includa la funzionalità NFC Tag Reading. Se il bundle ID non è configurato per NFC nel tuo account Apple Developer, Xcode non riuscirà a firmare l’app e segnalerà un entitlement com.apple.developer.nfc.readersession.formats mancante. Questa configurazione NFC non è necessaria per le varianti core o autodetection ($DiditSdkIosVariant), né per i pacchetti didit_sdk_core / didit_sdk_autodetection: nessuno di questi legge i chip.

Android

L’SDK dichiara i seguenti permessi nel proprio AndroidManifest.xml e vengono uniti automaticamente: Le funzionalità hardware di fotocamera e NFC sono dichiarate come facoltative (android:required="false"), quindi la tua app può essere installata anche su dispositivi privi di queste funzionalità. Quando diditSdkAndroidNfcEnabled=false, l’SDK non aggiunge l’autorizzazione e la funzionalità NFC di Android.

Autorizzazioni di runtime

L’SDK gestisce automaticamente le richieste di autorizzazione di runtime di Android. Quando l’utente arriva a un passaggio che richiede l’accesso alla fotocamera:
  1. L’SDK chiede l’autorizzazione ad accedere alla fotocamera se non è già stata concessa
  2. Se l’utente nega il permesso, viene mostrato un messaggio di errore con un pulsante Try Again
  3. Se l’utente concede il permesso, il flusso di verifica prosegue
Non è necessario richiedere l’autorizzazione ad accedere alla fotocamera nel codice della tua app prima di chiamare startVerification(): l’SDK se ne occupa internamente.

Avvio rapido


Metodi di integrazione

L’SDK supporta due metodi di integrazione:

Metodo 1: Session Token (consigliato per la produzione)

Crea una sessione sul tuo backend con l’API Create Verification Session, poi passa il token all’SDK:
Questo approccio ti offre il pieno controllo su:
  • Associazione delle sessioni ai tuoi utenti (vendor_data)
  • Impostazione di metadati personalizzati
  • Configurazione dei callback per ogni sessione

Metodo 2: Workflow ID (integrazione più semplice)

Per integrazioni più semplici, l’SDK può creare le sessioni direttamente con il tuo workflow ID, senza bisogno di un backend:
I parametri avanzati della sessione (contact_details, expected_details, metadata) sono supportati solo con il metodo Session Token, in cui il tuo backend chiama l’API Create Session con il supporto completo dei parametri. Passa il session_token restituito a DiditSdk.startVerification().

Configurazione

Personalizza il comportamento dell’SDK passando un oggetto DiditConfig:
Per startVerificationWithWorkflow, passa config come parametro denominato:

Opzioni di configurazione

Opzioni della fotocamera

Le opzioni della fotocamera corrispondono alle opzioni della fotocamera del Web SDK. Ogni obiettivo è CameraLens.front o CameraLens.back. Se il dispositivo non dispone dell’obiettivo richiesto, l’SDK usa la prima fotocamera disponibile. Il selettore della fotocamera è inoltre nascosto sui dispositivi che hanno una sola fotocamera. Imposta un’opzione del selettore su false per bloccare l’utente sull’obiettivo predefinito di quel passaggio.
Tema e colori: i colori, gli sfondi e le impostazioni della schermata introduttiva si configurano tramite le tue impostazioni White label nella Didit Console, non nella configurazione dell’SDK. Così l’identità del marchio resta coerente su tutte le piattaforme.

Supporto linguistico

L’SDK supporta 54 lingue. Se non viene specificata alcuna lingua, l’SDK usa la lingua del dispositivo, con l’inglese come lingua di ripiego.
Visualizza tutte le lingue supportate →

Parametri avanzati della sessione

I parametri come contact_details, expected_details e metadata sono supportati solo tramite il metodo con session token. Il tuo backend chiama POST /v3/session/ con il supporto completo dei parametri, poi passa il session_token restituito all’SDK.
Il metodo Dart startVerificationWithWorkflow accetta solo workflowId, vendorData e config. Le versioni precedenti alla 3.4.0 esponevano i parametri contactDetails, expectedDetails e metadata, ma sono stati rimossi perché l’endpoint Unilink non li rispetta.

Gestione dei risultati

Sia startVerification sia startVerificationWithWorkflow restituiscono un Future<VerificationResult>. Il risultato è una classe sealed: usa il pattern matching per determinare l’esito.

Casi del risultato

Proprietà di SessionData

Tipi di errore

L’enum VerificationErrorType espone i seguenti casi:

Connessione persa

Se il dispositivo perde la connessione durante la verifica, l’SDK mostra una schermata “Nessuna connessione a Internet” al posto del flusso, invece di lasciare un passaggio in caricamento. Continua a controllare in background e chiude automaticamente la schermata appena Didit torna raggiungibile, e l’utente prosegue dal passaggio in cui si trovava. La schermata offre Riprova e, se il pulsante di chiusura non è disattivato, Esci dalla verifica. Uscire termina la verifica con un risultato VerificationFailed il cui tipo di errore è networkError, così la tua app sa che l’utente è uscito a causa della connessione.

Esempio completo di gestione dei risultati


Esempio end-to-end (sessione backend → Flutter SDK → webhook)

Questa è l’integrazione pronta per la produzione: il tuo backend crea la sessione, la tua app Flutter riceve il session_token e l’SDK esegue il flusso. La decisione finale viene inviata al tuo backend tramite webhook: non fidarti mai del solo risultato lato client.

1. Backend: crea la sessione

2. Flutter: scambia il token e avvia l’SDK

3. Backend: ricevi la decisione finale tramite webhook

Consulta la guida ai webhook per i dettagli sulla verifica della firma HMAC.

Esempio completo


Ultima modifica il 7 novembre 2026