GitHub-Repository
Quellcode und Beispiele auf GitHub ansehen
pub.dev-Paket
didit_sdk
Natives SDK: Dies ist der empfohlene Ansatz für Flutter-Apps. Das SDK kapselt die nativen iOS- und Android-SDKs über Plattform-Channels und bietet damit das beste Nutzererlebnis, eine optimierte Kamerasteuerung und volle NFC-Unterstützung.
Anforderungen
Plattformanforderungen
Die biometrische Einwilligung erfordert natives SDK 4.10.0 oder neuer. Für Personen, die unter die Gesetze von Illinois, Texas oder Colorado fallen, kann Didit vor der ersten Gesichtsaufnahme eine ausdrückliche biometrische Einwilligung einholen. Eine Flutter-SDK-Version, die die nativen iOS- und Android-SDKs auf Version 4.10.0 oder höher festlegt, zeigt diesen Schritt an. Ältere Versionen können den Schritt nicht anzeigen: Ihre Sitzungen laufen wie bisher weiter, und die Entscheidung meldet die Einwilligung als nicht erhoben (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Aktualisieren Sie das SDK, wenn Sie Personen in diesen Bundesstaaten verifizieren.Installation
pubspec.yaml hinzu:
Varianten des nativen SDK
didit_sdk enthält das vollständige native SDK.
Um ein kleineres Binary auszuliefern, binden Sie stattdessen ein Varianten-Paket ein. Es stellt exakt dieselbe Dart-API bereit und fixiert auf beiden Plattformen das passende native SDK:
package:didit_sdk_core/sdk_flutter.dart.
iOS-Einrichtung
Das Plugin unterstützt beide iOS-Abhängigkeitsmanager von Flutter: Swift Package Manager und CocoaPods.Swift Package Manager
Wenn in Ihrer Flutter-Version die Unterstützung für Swift Package Manager aktiviert ist (ab Flutter 3.24+ mitflutter config --enable-swift-package-manager aktivieren), wird das Plugin automatisch als Swift-Paket eingebunden.
Eine Podfile-Konfiguration ist nicht nötig. Die native DiditSDK-Abhängigkeit wird automatisch von GitHub aufgelöst.
Legen Sie das iOS-Deployment-Target Ihrer App in Xcode (Runner-Target und Projekt) auf das Minimum des gewählten Pakets fest: 15.0 für didit_sdk und didit_sdk_nfc, 13.0 für didit_sdk_core und didit_sdk_autodetection.
CocoaPods
Beididit_sdk wählt das Plugin die Variante des nativen iOS-SDK über $DiditSdkIosVariant aus, eine globale Ruby-Variable, die Sie in der ios/Podfile Ihrer App setzen (das DiditSDK-Pod ist nicht im CocoaPods-Trunk verfügbar):
didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), fixiert es sein natives Subspec direkt und ignoriert $DiditSdkIosVariant. Halten Sie in diesem Fall die pod-Zeile und das Deployment-Target Ihrer Podfile passend zur Variante (zum Beispiel pod 'DiditSDK/Core', :podspec => ... mit platform :ios, '13.0').
Die Varianten
all und nfc erfordern ein Deployment-Target von iOS 15.0+; core und autodetection können auf iOS 13.0 abzielen. Beim Wechseln der Variante bereinigen Sie zuerst CocoaPods (rm -rf Pods Podfile.lock), damit die bisherige SDK-Variante nicht wiederverwendet wird.Android-Einrichtung
Standardmäßig hängt das Plugin vom vollständigen Android-SDK inklusive NFC ab. Um ohne NFC zu bauen, fügen Sie Folgendes zuandroid/gradle.properties hinzu:
me.didit:didit-sdk zu me.didit:didit-sdk-core, und das NFC-Lesemodul sowie seine Abhängigkeiten JMRTD/SCUBA/BouncyCastle entfallen.
Wenn NFC aktiviert ist (Standard), fügen Sie diese Packaging-Regel zu android/app/build.gradle.kts hinzu, um eine doppelte Metadatendatei von BouncyCastle aufzulösen:
mergeDebugJavaResource-Fehler fehl. Die Regel ist nicht nötig, wenn diditSdkAndroidNfcEnabled=false ist.
Das native Android-SDK wird ab Plugin-Version 3.4.0 aus einem entfernten GitHub-Maven-Repository aufgelöst. Eine manuelle Maven-Konfiguration in Ihrer App ist nicht nötig.
Berechtigungen
iOS
Fügen Sie derInfo.plist Ihrer App folgende Schlüssel hinzu:
NFC-Konfiguration
So aktivieren Sie das NFC-Auslesen für Pässe und Ausweise mit Chips:-
NFC Capability in Xcode hinzufügen:
- Wählen Sie Ihr Target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
ISO7816-Identifier zur
Info.plisthinzufügen:
D392F000260100000001 ermöglicht dem SDK das Auslesen der japanischen My Number Card über JPKI. Ohne diesen Identifier meldet iOS die Karte nicht an das SDK. Das Auslesen der My Number Card ist in der Produktion noch nicht aktiviert, und der Identifier wirkt sich nicht auf andere Dokumente aus. Sie können ihn daher bereits jetzt hinzufügen.
- Eine Entitlements-Datei hinzufügen, in der das Lesen von NFC-Tags aktiviert ist:
com.apple.developer.nfc.readersession.formats-Entitlement fehl.
Diese NFC-Konfiguration ist nicht erforderlich für die Varianten core oder autodetection ($DiditSdkIosVariant) oder für die Pakete didit_sdk_core / didit_sdk_autodetection. Keine dieser Varianten bzw. Pakete liest Chips aus.
Android
Die folgenden Berechtigungen sind in derAndroidManifest.xml des SDK deklariert und werden automatisch zusammengeführt:
Die Hardware-Funktionen für Kamera und NFC sind als optional deklariert (
android:required="false"). Ihre App kann daher auch auf Geräten ohne diese Funktionen installiert werden. Ist diditSdkAndroidNfcEnabled=false gesetzt, fügt das SDK die Android-NFC-Berechtigung und die NFC-Funktion nicht hinzu.
Laufzeitberechtigungen
Das SDK verarbeitet Laufzeitberechtigungsanfragen unter Android automatisch. Erreicht der Nutzer einen Schritt, der Kamerazugriff benötigt:- Fordert das SDK die Kameraberechtigung an, sofern sie noch nicht erteilt wurde.
- Verweigert der Nutzer die Berechtigung, wird eine Fehlermeldung mit der Schaltfläche Try Again angezeigt.
- Erteilt der Nutzer die Berechtigung, wird der Verifizierungsablauf fortgesetzt.
startVerification() aufrufen. Das SDK übernimmt dies intern.
Schnellstart
Integrationsmethoden
Das SDK unterstützt zwei Integrationsmethoden:Methode 1: Sitzungs-Token (für die Produktion empfohlen)
Erstellen Sie eine Sitzung in Ihrem Backend über die Create Verification Session API und übergeben Sie das Token dann an das SDK:- Die Zuordnung von Sitzungen zu Ihren Benutzern (
vendor_data) - Die Festlegung benutzerdefinierter Metadaten
- Die Konfiguration von Callbacks pro Sitzung
Methode 2: Workflow-ID (einfachere Integration)
Für einfachere Integrationen kann das SDK Sitzungen direkt mit Ihrer Workflow-ID erstellen. Ein Backend ist dafür nicht erforderlich:Erweiterte Sitzungsparameter (
contact_details, expected_details, metadata) werden nur über die Methode mit Sitzungs-Token unterstützt. Dabei ruft Ihr Backend die Create Session API auf, die alle Parameter vollständig unterstützt. Übergeben Sie das zurückgegebene session_token an DiditSdk.startVerification().Konfiguration
Passen Sie das Verhalten des SDK an, indem Sie einDiditConfig-Objekt übergeben:
startVerificationWithWorkflow übergeben Sie config als benannten Parameter:
Konfigurationsoptionen
Kameraoptionen
Die Kameraoptionen entsprechen den Kameraoptionen des Web SDK. Jedes Objektiv ist entwederCameraLens.front oder CameraLens.back.
Wenn das Gerät nicht über das angeforderte Objektiv verfügt, verwendet das SDK die erste verfügbare Kamera.
Der Kameraumschalter wird außerdem auf Geräten mit nur einer Kamera ausgeblendet.
Setzen Sie eine Umschalter-Option auf false, damit der Benutzer auf das Standardobjektiv dieses Schritts festgelegt wird.
Gestaltung und Farben: Farben, Hintergründe und Einstellungen des Einführungsbildschirms konfigurieren Sie über Ihre White-Label-Einstellungen in der Didit Console und nicht in der SDK-Konfiguration. So bleibt das Branding auf allen Plattformen einheitlich.
Sprachunterstützung
Das SDK unterstützt 54 Sprachen. Wenn keine Sprache angegeben ist, verwendet das SDK die Gerätesprache, und Englisch dient als Ausweichsprache.Erweiterte Sitzungsparameter
Parameter wiecontact_details, expected_details und metadata werden nur über die Sitzungs-Token-Methode unterstützt. Ihr Backend ruft POST /v3/session/ mit voller Parameterunterstützung auf und übergibt anschließend den zurückgegebenen session_token an das SDK.
Die Dart-Methode
startVerificationWithWorkflow akzeptiert nur workflowId, vendorData und config. Versionen vor 3.4.0 stellten die Parameter contactDetails, expectedDetails und metadata bereit. Diese wurden entfernt, weil der Unilink-Endpoint sie nicht berücksichtigt.Ergebnisse verarbeiten
SowohlstartVerification als auch startVerificationWithWorkflow geben ein Future<VerificationResult> zurück. Das Ergebnis ist eine versiegelte Klasse (sealed class). Verwenden Sie Pattern Matching, um das Ergebnis zu bestimmen.
Ergebnisfälle
SessionData-Eigenschaften
Fehlertypen
Die EnumVerificationErrorType stellt die folgenden Fälle bereit:
Verbindungsverlust
Wenn das Gerät während der Verifizierung die Verbindung verliert, blendet das SDK einen Bildschirm mit der Meldung „No internet connection“ über dem Ablauf ein, anstatt einen Schritt im Ladezustand hängen zu lassen. Das SDK prüft im Hintergrund weiter die Verbindung und schließt den Bildschirm automatisch, sobald Didit wieder erreichbar ist. Der Benutzer macht dann an dem Schritt weiter, an dem er zuvor war. Der Bildschirm bietet Try Again und, sofern die Schließen-Schaltfläche nicht deaktiviert ist, Exit Verification. Beim Verlassen endet die Verifizierung mit einemVerificationFailed-Ergebnis, dessen Fehlertyp networkError ist. So erkennt Ihre App, dass der Benutzer den Ablauf aufgrund des Verbindungsverlusts verlassen hat.
Vollständiges Beispiel zur Ergebnisverarbeitung
End-to-End-Beispiel (Backend-Sitzung → Flutter SDK → Webhook)
Dies ist die produktionsreife Integration: Ihr Backend erstellt die Sitzung, Ihre Flutter-App empfängt densession_token, und das SDK führt den Ablauf aus. Die endgültige Entscheidung wird per Webhook an Ihr Backend übermittelt. Vertrauen Sie niemals allein dem clientseitigen Ergebnis.