Native SDKs für iOS, Android, React Native und Flutter binden den Ablauf in Ihre App ein und sind der einzige Weg zu NFC. Web-SDKs ergänzen das Frontend.
Native SDKs gibt es für iOS, Android, React Native und Flutter; Web-SDKs betten den Ablauf in Ihr Frontend ein. Nutzen Sie ein natives SDK, wenn Sie NFC oder das beste Kameraverhalten benötigen - eine WebView bietet keines von beidem. Ergebnisse kommen weiterhin per Webhook zurück, nicht vom SDK.
#Warum ein SDK statt eines Redirects
Ein gehostetes Redirect ist der geringste Aufwand und für die meisten Abläufe wirklich ausreichend. Ein SDK lohnt sich, wenn:
- Sie NFC benötigen. Der Chip in einem Reisepass oder Ausweis kann von einer Browserseite aus nicht ausgelesen werden. Ein natives SDK ist der einzige Weg. Siehe NFC-Chip-Verifizierung.
- Sie möchten nicht, dass der Nutzer Ihre App verlässt. Ein Redirect nach draußen und zurück ist auf Mobilgeräten ein echter Abbruchpunkt.
- Sie möchten das beste Kameraverhalten. Nativer Kamerazugriff ist zuverlässiger als der eines Browsers, besonders auf älteren Geräten.
#Was verfügbar ist
| Plattform | Hinweise |
|---|---|
| iOS | Als XCFramework verteilt |
| Android | Über Maven verteilt |
| React Native | Umschließt die nativen Module; unterstützt die New Architecture |
| Flutter | Umschließt die nativen Module |
| JavaScript / Web | Bettet den gehosteten Ablauf in Ihr Web-Frontend ein |
| In-Context-iFrame | Rendert den Ablauf innerhalb Ihrer Seite, statt weiterzuleiten |
iOS unterstützt Swift Package Manager und CocoaPods; ergänze bei Bedarf Kamera- und NFC-Berechtigungen in Info.plist. Android wird über Maven verteilt. React Native unterstützt Expo mit einem Development Build inklusive nativer Module, nicht mit Expo Go.
Versionsanforderungen und Plattform-Mindestwerte ändern sich mit neuen Releases, prüfen Sie also die aktuelle SDK-Dokumentation statt einer Momentaufnahme dieser Hilfeseite - und wenn Sie eine bestimmte Framework-Version einsetzen (etwa ein bestimmtes Expo-SDK), bestätigen Sie die Kompatibilität mit Ihrem Didit-Ansprechpartner, bevor Sie sich in einem Sprint darauf festlegen.
#Eine WebView ist kein natives SDK
Den gehosteten Web-Ablauf in eine WebView einzupacken, wirkt, als gäbe es Ihnen eine In-App-Erfahrung. Sie gibt Ihnen den Anschein davon:
- Kein NFC. Der Chip lässt sich weiterhin nicht auslesen.
- Kamera-Berechtigungen sind schwieriger. Der Kamerazugriff einer WebView hängt von der Konfiguration der Host-App ab, und ihn falsch einzurichten erzeugt genau die "die Kamera hat sich nie geöffnet"-Meldungen, die in Probleme mit Liveness-Prüfung und Gesichtsabgleich beheben behandelt werden.
- Die Locale gehört der App, nicht dem Nutzer. Eine WebView meldet die Locale der Host-App, übergeben Sie also
languageexplizit beim Erstellen der Session. Siehe die Verifizierungssprache festlegen.
Wenn Sie sich schon die Mühe eines In-App-Ablaufs machen, nutzen Sie das native SDK.
#Ergebnisse kommen weiterhin von Webhooks
Das überrascht viele: Das SDK teilt Ihrer App mit, dass der Nutzer den Ablauf abgeschlossen hat. Es ist nicht die maßgebliche Quelle für die Verifizierungsentscheidung.
Die Entscheidung wird serverseitig erzeugt, nachdem die Prüfungen gelaufen sind, und erreicht Sie per Webhook. Gewähren Sie niemals Zugriff allein aufgrund des Completion-Callbacks des SDK - ein clientseitiges Signal ist trivial fälschbar, und die Prüfungen sind unter Umständen noch nicht einmal abgeschlossen, wenn er ausgelöst wird.
"Das SDK hat fertig gemeldet" mit "der Nutzer ist verifiziert" gleichzusetzen, ist der folgenreichste Fehler, der bei einer mobilen Integration möglich ist. Bestätigen Sie es auf Ihrem Server, über den Webhook oder den Decision-Endpoint, bevor Sie irgendetwas freischalten.
#Eine Verbraucher-App, oder Ihre eigene?
Es gibt keine separate Verbraucher-App von Didit, an die eine gehostete Session Nutzer für einen Schritt wie NFC übergibt. Wenn Sie alles - NFC und Nicht-NFC - innerhalb einer einzigen App-Erfahrung wollen, ist diese App Ihre eigene, mit eingebettetem SDK.
#Verteilung und Abhängigkeitskonflikte
Die Integration des nativen SDK kollidiert gelegentlich mit anderen Abhängigkeiten in einer Host-App - einer gemeinsam genutzten transitiven Bibliothek, oder einer Subspec, die eine Version fixiert, die auch etwas anderes fixiert. Wenn Sie darauf stoßen, ist das ein konkretes, reproduzierbares Problem, das eine Meldung mit Ihrem Dependency-Manifest wert ist, statt es durch Fixieren einer alten Version zu umgehen: die Korrektur gehört meist in das SDK.
#Auf einem Gerät testen
Wechseln Sie mit dem Schalter unter dem Anwendungsnamen zu Sandbox, erstellen Sie dort einen API-Schlüssel und verwenden Sie ihn. Prüfungen werden simuliert, nicht berechnet, und Sie können das Ergebnis wählen.
Kommen Sie nicht weiter? Sprechen Sie mit einem Menschen.
Geben Sie Ihre Organisations-ID und die Session-ID an, um die es geht.