Mobile und Web-SDKs
Native SDKs für iOS, Android, React Native und Flutter binden den Ablauf in Ihre App ein und sind der einzige Weg, der NFC unterstützt. Web-SDKs betten ihn in Ihr Frontend ein.
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 |
- Wählen Sie Ihre Plattform, und die Seite liefert das Snippet für diesen Stack.
- Die nativen und Web-SDKs, jedes mit eigenem Quickstart, sind hier verlinkt.
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
Die Sandbox funktioniert über ein SDK genauso wie überall sonst - richten Sie die App auf den Schlüssel einer Sandbox-Anwendung, und jede Prüfung wird gemockt und nicht abgerechnet. Das ist der richtige Weg, um einen mobilen Ablauf zu proben, denn die SDK-Verhaltensweisen, die Sie am dringendsten testen müssen (Berechtigungsabfragen, Kamera-Lebenszyklus, Wechsel in den Hintergrund während der Aufnahme), sind Geräteverhaltensweisen, die Sie wiederholt kostenlos durchspielen können. Siehe Testen in der Sandbox.