Flutter SDK: Identitätsprüfung in Ihre App integrieren (DE)

Eine Flutter SDK-Integration für die Identitätsprüfung sollte dauerhafte Anmeldeinformationen und die endgültige Autorisierung in Ihrem Backend behalten, während die mobile App einen nativen Erfassungsablauf mit einem kurzlebigen Sitzungstoken startet. Das Didit Flutter SDK stellt eine Dart-API über die nativen iOS- und Android-Verifizierungs-SDKs bereit, die dem Endpunkt typisierte Abschluss-, Abbruch- oder Fehlerergebnisse zurückgibt. Die vollständige Entscheidung verbleibt weiterhin beim Backend-Webhook oder -Abruf.

Dieser Leitfaden verwendet ausschließlich Dart-Methoden und Ergebnistypen, die anhand der aktuellen lokalen SDK-Quelle und Tests verifiziert wurden. Details zu nativen Abhängigkeiten ändern sich mit den Releases, daher wird die Plattformkonfiguration nach Zuständigkeit beschrieben und auf den kanonischen SDK-Leitfaden verlinkt, anstatt einen versionsabhängigen Podfile- oder Gradle-Block zu kopieren.

Wichtige Erkenntnisse

• Produktionssitzungen im Backend erstellen. Bewahren Sie den API-Schlüssel nicht auf dem Gerät auf und senden Sie nur das vom SDK benötigte Sitzungstoken.
• Verwenden Sie das typisierte Dart-Ergebnis für die Benutzererfahrung, nicht für die Autorisierung. VerificationCompleted bedeutet, dass der SDK-Ablauf beendet wurde; prüfen Sie den Status zur Anzeige und warten Sie auf die maßgebliche Backend-Entscheidung.
• Behandeln Sie den Abbruch, typisierte Fehler und unerwartete Plattformfehler separat. Sie benötigen unterschiedliche Wiederherstellungs- und Analyseansätze.
• Betrachten Sie die native Einrichtung als Release-Infrastruktur. iOS-Datenschutzschlüssel, NFC-Berechtigungen (Near-Field Communication), Deployment-Ziele, Android-Abhängigkeiten, Packaging und Berechtigungen müssen auf realen Geräten getestet werden.
• Gestalten Sie den gesamten Lebenszyklus. Sitzungserstellung, App-Übergabe, Erfassung, Webhook-Verifizierung, idempotente Statusänderungen, Überprüfung, Wiederholungen und Beobachtbarkeit bilden eine Integration.

Was das Didit Flutter SDK leistet

Das didit_sdk-Paket kapselt native iOS- und Android-SDKs hinter einer gemeinsamen Dart-Schnittstelle. Es startet die Benutzeroberfläche zur Verifizierung als nativen Vollbild-Flow und kehrt zurück, wenn der Benutzer den Vorgang abschließt, abbricht oder ein Fehler auftritt.

Das SDK kann Workflows mit ID-Verifizierung, Liveness-Erkennung und anderen konfigurierten Prüfungen starten. Der Workflow bestimmt, welche Schritte angezeigt werden; der Flutter-Aufruf codiert sie nicht fest.

Die für den Lebenszyklus relevante öffentliche Dart-Oberfläche ist:

DiditSdk.startVerification(token, config: ...)
DiditSdk.startVerificationWithWorkflow(workflowId, vendorData: ..., config: ...)

Für die Produktion ist startVerification mit einem vom Backend erstellten Token vorzuziehen. Die Workflow-ID-Methode ist einfacher, gibt dem Backend jedoch weniger Kontrolle über erweiterte Parameter.

Architektur: Backend, Flutter-App, SDK und Webhook

Der Produktionsablauf hat vier Vertrauensgrenzen:

Komponente	Besitzt	Darf nicht besitzen
Ihr Backend	API-Schlüssel, Workflow-Wahl, Kundenreferenz, Sitzungserstellung, endgültiger Kundenstatus	Kamera-Schnittstelle
Flutter-App	Übergabeanfrage, Lade- und Wiederherstellungs-UI, SDK-Start, lokale Analysen	Permanenter API-Schlüssel oder endgültige Autorisierung
Didit Flutter SDK	Native Erfassung und konfigurierter Verifizierungs-Flow	Ihre Produktberechtigungsentscheidung
Webhook/Abruf-Worker	Authentifizierte Ergebniserfassung, Deduplizierung, Abstimmung	Unverifizierte Client-Annahmen

Die Reihenfolge ist:

1. Die angemeldete Flutter-App fordert Ihr Backend auf, die Verifizierung zu starten.
2. Ihr Backend erstellt eine Verifizierungssitzung mit dem beabsichtigten Workflow und einer stabilen internen Kundenreferenz.
3. Das Backend gibt das bereichsbezogene session_token an die App zurück.
4. Die App übergibt dieses Token an DiditSdk.startVerification.
5. Das SDK präsentiert den nativen Flow und gibt ein typisiertes Ergebnis für die sofortige Benutzererfahrung zurück.
6. Ihr Backend empfängt und verifiziert das Ergebnisereignis, gleicht den kanonischen Status ab und aktualisiert den Kunden gemäß Ihrer Richtlinie.
7. Die App liest den Kundenstatus Ihres Backends, bevor sie Zugriff gewährt oder die endgültige Genehmigung erteilt.

Diese Architektur vertraut keinem Erfolgsbildschirm auf dem Gerät.

Für den serverseitigen Vertrag und die Ereignisgrenze, siehe den Leitfaden zur API-Integrationsbewertung für die ID-Verifizierung.

Paket installieren

Verwenden Sie den Paketbefehl, anstatt eine Version zu kopieren, die veralten kann:

flutter pub add didit_sdk

Importieren Sie dann die öffentliche Bibliothek:

import 'package:didit_sdk/sdk_flutter.dart';

Lesen Sie vor dem Upgrade das Änderungsprotokoll und die offizielle Flutter SDK-Dokumentation. Überprüfen Sie die deklarierten Plattformanforderungen mit Ihrer App und Ihren CI-Images.

Befolgen Sie die Flutter-Release-Anweisungen für native Abhängigkeiten; das Mischen beliebiger Versionen kann zu Inkompatibilitäten führen.

iOS und Android konfigurieren

iOS-Verantwortlichkeiten

Die Identitätserfassung kann geschützte Hardware und Daten verwenden. Abhängig vom konfigurierten Workflow und der SDK-Variante kann die iOS-Einrichtung Folgendes erfordern:

• ein geeignetes Deployment-Ziel;
• Beschreibungen zur Kamera- und Mikrofonnutzung;
• Beschreibung zur Foto-Bibliotheksnutzung, falls Uploads erlaubt sind;
• NFC-Nutzungsbeschreibung und -Berechtigungen, wenn das Chip-Lesen aktiviert ist;
• kompatible CocoaPods-Konfiguration;
• Signaturfähigkeiten und Bereitstellung, die zur NFC-Nutzung passen;
• registrierte benutzerdefinierte Schriftarten, falls eine app-spezifische Schriftart konfiguriert ist.

Fehlende Datenschutz-Strings können eine iOS-App beenden. Testen Sie den genauen Workflow auf einem physischen Gerät.

NFC-Unterstützung kann das minimale Deployment-Ziel erhöhen oder native Abhängigkeiten hinzufügen. Wählen Sie die SDK-Variante, die zu Ihrem Workflow passt, und befolgen Sie die aktuellen Dokumente für deren Podfile-Konfiguration.

Android-Verantwortlichkeiten

Unter Android überprüfen Sie:

• Mindest-SDK- und Java-Anforderungen;
• Repositories und Abhängigkeiten, die durch das Plugin hinzugefügt wurden;
• Kamera-, Netzwerk- und NFC-Manifesteinträge;
• Laufzeitverhalten der Kamera-Berechtigung;
• Gradle- und Kotlin-Kompatibilität;
• Verpackungsregeln für native oder kryptografische Abhängigkeiten;
• die SDK-Variante all, core, autodetection oder nfc;
• Minifizierung des Release-Builds und Ressourcenverhalten.

Ihr Produkt benötigt weiterhin einen Kontext für Berechtigungen, Wiederherstellung nach Ablehnung, Barrierefreiheit und Support-Anweisungen. Testen Sie Ablehnung, Unterbrechung, Hintergrundbetrieb, Rotation und Prozesserstellung.

Sitzungen im Backend erstellen

Ihr Backend sollte die Sitzungs-API mit einem serverseitigen API-Schlüssel aufrufen. Verknüpfen Sie jede Sitzung mit:

• Ihrem stabilen Kundenidentifikator;
• dem ausgewählten Workflow;
• Umgebung;
• Rückruf- oder Rückkehrverhalten, wo zutreffend;
• erforderlichem Gebietsschema oder Kontaktdaten;
• erwarteten Kundendetails, wo die Richtlinie diese verwendet;
• interner Korrelation und Richtlinienmetadaten.

Betten Sie den Didit API-Schlüssel niemals in Dart, App-Assets, lesbare Remote-Konfigurationen oder eine mobile Anfrage ein.

Geben Sie nur das Sitzungstoken und den minimalen Startstatus zurück. Halten Sie es von Analysen, Absturzberichten, Protokollen, der Zwischenablage und langfristiger Speicherung fern.

Startanfragen idempotent machen

Ein Kunde kann zweimal tippen, die Konnektivität verlieren, nachdem Ihr Backend eine Sitzung erstellt hat, oder den Bildschirm erneut öffnen, während ein Versuch aktiv ist. Verwenden Sie eine stabile Anforderungs-ID und Backend-Logik, die den vorhandenen geeigneten Versuch zurückgibt, anstatt getrennte Duplikate zu erstellen.

Der Ladebutton Ihrer App sollte offensichtliche wiederholte Taps blockieren, aber serverseitige Idempotenz bleibt notwendig, da Clients Wiederholungen durchführen und Prozesse neu starten.

Verifizierung aus Dart starten

Dieses vollständige Dart-Beispiel verwendet nur den SDK-Import, die Methode, die Ergebnisklassen, die Sitzungsfelder, die Status-Enum und die Fehlerfelder, die in der Paketquelle verifiziert wurden:

import 'package:didit_sdk/sdk_flutter.dart';

Future<void> runIdentityVerification(String sessionToken) async {
  try {
    final result = await DiditSdk.startVerification(
      sessionToken,
      config: const DiditConfig(
        loggingEnabled: false,
      ),
    );

    switch (result) {
      case VerificationCompleted(:final session):
        switch (session.status) {
          case VerificationStatus.approved:
            print('Flow completed with approved client status.');
          case VerificationStatus.pending:
            print('Flow completed and still needs a backend decision.');
          case VerificationStatus.declined:
            print('Flow completed with declined client status.');
        }
        print('Session ID: ${session.sessionId}');
        return;
      case VerificationCancelled():
        print('The user cancelled the verification flow.');
        return;
      case VerificationFailed(:final error):
        print('SDK error: ${error.type.name}: ${error.message}');
        return;
    }
  } catch (error, stackTrace) {
    print('Unexpected platform error: $error');
    print(stackTrace);
  }
}

Das Beispiel zeigt die Typstruktur. Eine echte App sollte den Bildschirmstatus aktualisieren und den Backend-Status aktualisieren, niemals ein Konto nur aus dieser Funktion entsperren.

Warum VerificationCompleted nicht immer eine Genehmigung ist

VerificationCompleted enthält SessionData, dessen status einer der folgenden ist:

• VerificationStatus.approved;
• VerificationStatus.pending;
• VerificationStatus.declined.

Der SDK-Flow kann beendet werden, während die Verifizierung noch ausstehend oder abgelehnt ist. Eine menschliche Überprüfung oder eine asynchrone Prüfung kann den Backend-Status auch nach der Rückkehr des App-Aufrufs ändern. Nennen Sie Ihren lokalen UI-Status „Flow abgeschlossen“ statt „Identität genehmigt“, bis Ihr Backend das Richtlinienergebnis bestätigt.

Es gibt keinen Flutter-Initialisierungsaufruf

Die verifizierte öffentliche Flutter-Oberfläche bietet keine separate Initialisierungsmethode. Kopieren Sie kein Android-natives Initialisierungsmuster in Dart. Wenn Android notInitialized über das Flutter-Ergebnis meldet, behandeln Sie dies als Integrations- oder Native-Bridge-Problem und überprüfen Sie die Paketeinrichtung.

Typisierte Fehler und Wiederherstellung handhaben

Die verifizierten Fehlertypen des SDK sind:

Fehlertyp	Bedeutung für die App-Richtlinie	Sichere Wiederherstellung
sessionExpired	Das Token kann die beabsichtigte Sitzung nicht mehr starten	Backend um eine neue, gültige Sitzung bitten
networkError	Der native Flow konnte einen Netzwerkbetrieb nicht abschließen	Kontext beibehalten und eine begrenzte Wiederholung anbieten
cameraAccessDenied	Erforderlicher Kamerazugriff ist nicht verfügbar	Erklären, warum er benötigt wird, und Einstellungen oder alternativen Weg aufzeigen
notInitialized	Android native Integration oder Bridge ist nicht bereit	Release-Kontext protokollieren und Einrichtung prüfen
apiError	Das SDK oder der Dienst hat einen API-Fehler zurückgegeben	Nur bei Sicherheit wiederholen; Backend-Status abgleichen
retryBlocked	Der Flow verhindert einen weiteren automatischen Versuch	Schleife stoppen und Backend- oder Support-Richtlinie befolgen
unknown	Der native Fehler konnte keinem bekannten Dart-Typ zugeordnet werden	Einen sicheren Fallback und Korrelationsdaten beibehalten

Native Plattformen können unterschiedliche Details offenlegen. Behalten Sie einen unknown-Pfad bei.

Fehler von Kundenergebnissen trennen

Ein Netzwerkfehler ist keine Ablehnung; die Verweigerung des Kamerazugriffs ist kein Betrug; die Stornierung ist keine fehlgeschlagene Identifizierung. Halten Sie die Kategorien getrennt in:

• Benutzernachrichten;
• Wiederholungsregeln;
• Produktzugriff;
• Support-Tools;
• Analysen;
• Betrugs- und Konversionsberichten.

Wiederholungen begrenzen

Lassen Sie das Backend entscheiden, ob eine vorhandene Sitzung fortgesetzt werden kann oder eine neue erforderlich ist. Vermeiden Sie eine unbegrenzte Schleife, die das SDK wiederholt mit einem abgelaufenen oder blockierten Token aufruft. Verfolgen Sie die Anzahl der Versuche und die Ursache, ohne das Token oder den Identitätsnachweis zu protokollieren.

Backend-Ereignisse als Wahrheit verwenden

Das SDK gibt ein kompaktes Client-Ergebnis zurück. Vollständige Nachweise und der endgültige Status kommen über die serverseitige Integration. Ihr Webhook-Handler sollte:

1. die Rohdatenanforderung in der Form empfangen, die durch das dokumentierte Signaturschema erforderlich ist;
2. das Ereignis authentifizieren und die Aktualität überprüfen;
3. seinen Ereignisidentifikator deduplizieren;
4. es der erwarteten Sitzung und dem Kunden zuordnen;
5. ältere Ereignisse daran hindern, spätere Endzustände zu überschreiben;
6. den kanonischen Sitzungsstatus abrufen, wenn eine Abstimmung erforderlich ist;
7. Ihre Richtlinie anwenden und den Grund speichern;
8. innerhalb des Antwortbudgets des Anbieters zurückkehren;
9. langsame nachgeschaltete Arbeiten asynchron verarbeiten.

Gehen Sie von einer mindestens einmaligen Zustellung aus. Doppelte und ungeordnete Ereignisse sind normales Verhalten verteilter Systeme. Speichern Sie das Anbieterereignis und den internen Übergang separat, damit ein Audit beides rekonstruieren kann.

Die App sollte Ihr Backend nur für ihren eigenen Produktstatus abfragen oder Ihren normalen Echtzeitkanal verwenden. Sie sollte keinen Anbieter-API-Schlüssel offenlegen, um den endgültigen Datensatz direkt abzurufen.

Einen robusten Flutter-Bildschirmlebenszyklus aufbauen

Explizite lokale Zustände modellieren

Ein Verifizierungsbildschirm kann verwenden:

• Leerlauf;
• Sitzung anfordern;
• SDK starten;
• SDK-Flow offen;
• Backend-Entscheidung abgleichen;
• Überprüfung abwarten;
• genehmigt;
• abgelehnt;
• wiederherstellbarer Fehler;
• abgebrochen.

Speichern Sie nur das, was sicher ist. Fragen Sie nach dem Prozessende das Backend, ob bereits eine aktive oder beendete Sitzung existiert. Verlassen Sie sich nicht auf einen In-Memory-Booleschen Wert, um zu entscheiden, ob ein weiterer Versuch erstellt werden soll.

Widget-Lebenszyklus respektieren

Nach dem erwarteten Aufruf überprüfen Sie mounted vor setState, Dialogen oder Navigation. Halten Sie den Geschäftsstatus außerhalb der transienten Benutzeroberfläche.

Hintergrundbetrieb und Abbruch handhaben

Testen Sie App-Wechsel, Bildschirmsperre, Navigation und Prozessbeendigung. Definieren Sie das Verhalten beim Fortsetzen, Neustarten und Abgleichen.

Berechtigungswiederherstellung gestalten

Erklären Sie die Notwendigkeit von Kamera oder NFC. Nach dauerhafter Verweigerung zeigen Sie eine Anleitung zu den Einstellungen oder einen zugänglichen alternativen Weg.

Konfiguration ohne Richtlinienlecks

Die offline verifizierte Flutter DiditConfig-Oberfläche bietet languageCode, fontFamily, loggingEnabled, showCloseButton, showExitConfirmation, closeOnComplete, defaultDocumentCamera, defaultLivenessCamera, showDocumentCameraSwitchButton und showLivenessCameraSwitchButton. Die Kamerafelder verwenden CameraLens.front oder CameraLens.back; alle Optionen sind in Dart typisiert und den nativen SDKs zugeordnet.

Halten Sie sich an drei Regeln:

1. Aktivieren Sie die ausführliche Protokollierung nur für die Entwicklung oder einen kontrollierten Diagnose-Build.
2. Verwenden Sie die UI-Konfiguration nicht als Ersatz für die Backend-Richtlinie.
3. Testen Sie jede unterstützte Sprache, benutzerdefinierte Schriftart, das Schließverhalten und die Kamerarichtlinie auf beiden Plattformen, einschließlich des Fallback-Verhaltens, wenn ein angefordertes Objektiv oder Asset nicht verfügbar ist.

Die Workflow-Zusammensetzung und das Produkt-Branding gehören in die Konsole oder den vom Backend verwalteten Workflow und nicht in ein Labyrinth mobiler Feature-Flags. Dies gewährleistet die Ausrichtung von iOS-, Android-, Web- und Supportansichten.

Integration testen

Dart- und Widget-Tests

Kapseln Sie den SDK-Start hinter einem Anwendungsdienst, damit Bildschirmtests Folgendes zurückgeben können:

• abgeschlossen und genehmigt;
• abgeschlossen und ausstehend;
• abgeschlossen und abgelehnt;
• abgebrochen;
• jeder typisierte Fehler;
• eine unerwartet geworfene Plattformausnahme.

Überprüfen Sie die Bereinigung des Ladestatus, die Überprüfung der Montage, die Sichtbarkeit von Wiederholungen, die Aktualisierung des Backends und die Analysekategorien. Fügen Sie keine echten Sitzungstoken in Fixtures ein.

Native Integrationstests

Führen Sie Debug- und Release-Builds auf physischen iOS- und Android-Geräten aus. Decken Sie ab:

• erstmalige und zuvor entschiedene Berechtigungen;
• unterstützte und nicht unterstützte Kameras;
• NFC-fähige und nicht-NFC-Varianten, wo verwendet;
• schwaches Licht, Unschärfe, Blendung und Ausrichtung;
• langsame, verlorene und wiederhergestellte Konnektivität;
• Hintergrundbetrieb und Prozesserstellung;
• Abbruch und wiederholter Start;
• Sitzungsablauf und Blockierung von Wiederholungen;
• verschiedene Gebietsschemas, Schriftgrößen, Bildschirmleser und reduzierte Bewegung;
• App-Signierung, Minifizierung und Auflösung von Produktionsabhängigkeiten.

Ein Emulator ist nützlich für Status- und Fehlertests, kann aber nicht jede Kamera, NFC, Biometrie und Gerätezustandsbedingung darstellen.

End-to-End-Backend-Tests

Verwenden Sie deterministische Sandbox-Fälle für jeden dokumentierten Kundenstatus. Spielen Sie signierte Testereignisse erneut ab, senden Sie Duplikate ungeordnet, verzögern Sie die Überprüfung und gleichen Sie nach einem simulierten verpassten Webhook ab. Bestätigen Sie, dass die App niemals Zugriff gewährt, bevor sich Ihr Backend-Status ändert.

Für das Design biometrischer Tests und Angriffsvektoren siehe den Leitfaden zum Liveness-Test.

Checkliste für Sicherheit und Datenschutz

Stellen Sie vor der Veröffentlichung sicher, dass:

• permanente Anbieterzugangsdaten nur im Backend existieren;
• die App ein bereichsbezogenes Sitzungstoken über einen authentifizierten Kanal empfängt;
• Token und Nachweise nicht in Protokollen, Analysen, URLs und Absturzberichten enthalten sind;
• Backend-Erstellungsanfragen idempotent sind und an eine stabile Kundenreferenz gebunden sind;
• der Client-Abschluss niemals direkt eine Berechtigung gewährt;
• Webhook-Signatur-, Aktualitäts-, Duplikat-, Reihenfolge- und Abstimmungstests bestanden werden;
• iOS-Datenschutzbeschreibungen und Android-Berechtigungswege klare Zwecktexte verwenden;
• NFC-Funktionen und -Varianten mit dem Workflow und der Release-Signierung übereinstimmen;
• Debug-Protokollierung für die Produktion deaktiviert ist;
• Aufbewahrung, Zustimmung, Datenschutzerklärung, Löschung und Supportpfade Ihrer Rolle und dem Gesetz entsprechen;
• SDK, native Abhängigkeit, Betriebssystem und Gerätekompatibilität nach dem Start überwacht werden;
• Entscheidungen zur Rückgängigmachung und erzwungenen Aktualisierung Verantwortliche haben.

Häufige Integrationsfehler des Flutter SDK

API-Schlüssel in Dart versenden

Mobile Anwendungen können keine dauerhaften Server-Anmeldeinformationen schützen. Erstellen Sie Sitzungen in Ihrem Backend und übergeben Sie ein bereichsbezogenes Token.

Dem abgeschlossenen Callback vertrauen

Das Client-Ergebnis ist der Zustand der Benutzeroberfläche. Bestätigen Sie den maßgeblichen Status und wenden Sie die Richtlinie im Backend an.

Methoden von einer anderen Plattform erfinden

Flutter bietet nicht jede native SDK-Methode unter demselben Namen an. Kompilieren Sie gegen das Paket und überprüfen Sie dessen öffentlichen Dart-Quellcode, bevor Sie Integrationscode schreiben.

Veraltete native Konfiguration kopieren

SDK-Varianten, Bereitstellungsziele und Paketmanager-Einrichtung ändern sich. Befolgen Sie die Dokumentation für das installierte Release und notieren Sie es in Ihrer mobilen Release-Checkliste.

Jeden Fehler als Ablehnung behandeln

Berechtigungs-, Netzwerk-, Ablauf-, API-Fehler, Stornierung und Kundenentscheidung erfordern unterschiedliche Wiederherstellungs- und Analyseansätze.

Nur auf einem Emulator testen

Kamera, NFC, Berechtigungen, Signierung und native Abhängigkeiten erfordern physische Geräte- und Release-Build-Abdeckung.

Didit in einem Flutter-Identitätsworkflow verwenden

Das Didit Flutter SDK wird als kostenlos aufgeführt. Es kann Workflows starten, die ID-Verifizierung, Liveness-Erkennung und andere konfigurierte Prüfungen enthalten, während Teams bedingte Pfade über den Workflow Orchestrator verwalten.

Veröffentlichte Modulraten sind auf der Preisseite verfügbar. Das SDK übernimmt die native Erfassungserfahrung; Ihr Backend bleibt für die Sitzungserstellung, die authentifizierte Ergebnisverarbeitung, den Kundenstatus und Produktentscheidungen verantwortlich.

Häufig gestellte Fragen

Welche Methode startet die Verifizierung?

Für eine vom Backend erstellte Produktionssitzung rufen Sie DiditSdk.startVerification(sessionToken) auf. Das SDK bietet auch DiditSdk.startVerificationWithWorkflow(...) für den einfacheren Workflow-ID-Integrationsmodus.

Sollte die Flutter-App den Didit API-Schlüssel enthalten?

Nein. Bewahren Sie den API-Schlüssel im Backend auf. Die App sollte nur das bereichsbezogene Sitzungstoken erhalten, das für ihren Verifizierungsversuch erforderlich ist.

Bedeutet VerificationCompleted genehmigt?

Nicht unbedingt. Ihr Sitzungsstatus kann genehmigt, ausstehend oder abgelehnt sein. Verwenden Sie das Ergebnis für den sofortigen Schnittstellenstatus und bestätigen Sie die maßgebliche Entscheidung über Ihr Backend.

Wie sollte der Abbruch gehandhabt werden?

Behandeln Sie es als ein eigenständiges Benutzerergebnis. Bewahren Sie den Backend-Sitzungsstatus, bieten Sie einen klaren Wiederaufnahme- oder Neustartpfad gemäß der Richtlinie an und bezeichnen Sie den Abbruch nicht als Betrug oder Ablehnung.

Hat das Flutter SDK eine Initialisierungsmethode?

Die verifizierte öffentliche Dart-API bietet keine separate Initialisierungsmethode. Befolgen Sie die nativen Einrichtungsanweisungen des Pakets und verwenden Sie die dokumentierten Startmethoden.

Kann Flutter NFC für Identitätsdokumente verwenden?

Das native SDK kann NFC unterstützen, wenn die ausgewählte Paketvariante, das Gerät, die iOS- oder Android-Konfiguration, die Signaturfähigkeiten und der Workflow dies alle ermöglichen. Befolgen Sie die aktuelle Release-Dokumentation und testen Sie auf physischen Geräten.

Was sollte die App tun, während ein Fall überprüft wird?

Zeigen Sie einen wahrheitsgemäßen ausstehenden Status an, ermöglichen Sie dem Kunden ein sicheres Verlassen und lesen Sie den endgültigen Produktstatus von Ihrem Backend, wenn das authentifizierte Ergebnis eintrifft.

Primäre Referenzen

• Didit Flutter SDK Dokumentation
• Didit Flutter SDK Quellcode-Repository
• Didit Session API Dokumentation
• Didit Webhook Dokumentation
• Flutter Dokumentation: Plattformintegration
• OWASP Mobile Application Security Verification Standard

Eine starke Flutter SDK-Integration hält jede Grenze explizit: Das Backend erstellt den Versuch, die App startet einen bereichsbezogenen nativen Flow, typisierte Ergebnisse steuern die Wiederherstellung, authentifizierte Serverereignisse steuern den Kundenstatus, und Tests auf realen Geräten beweisen, dass Berechtigungen, Lebenszyklus, native Abhängigkeiten und Fehlerpfade außerhalb der „Happy Path“-Demo funktionieren.