Zum Hauptinhalt springen
Die Ausweisverifizierung ist eine Funktion mit drei Methoden. Sie wählen, welche Methoden ein Land nutzen darf; der Endbenutzer erhält diejenigen davon, die für das von ihm ausgewählte Land gelten, und die Sitzung zeichnet auf, welche Methode das Ergebnis tatsächlich geliefert hat. Die Dokumentaufnahme bleibt unverändert. Alles, was Sie bereits über documents_allowed konfigurieren — akzeptierte Typen, Untertypen, Erfassungsregeln, Schwellenwerte, Warnungen — funktioniert weiterhin genau wie zuvor, und ein Workflow, der keine Angaben zu Methoden enthält, bleibt auf die Dokumentaufnahme beschränkt.

​
So funktioniert jede Methode

​
Dokumentaufnahme

Im Rest dieses Abschnitts wird Folgendes dokumentiert: Der Benutzer fotografiert das Dokument, Didit liest es aus, prüft es auf Echtheit und gibt die extrahierten Felder zurück. Verfügbar in jedem von Didit unterstützten Land für $0.15 pro Prüfung. Beginnen Sie bei der Übersicht zur Ausweisverifizierung.

​
Abfrage ohne Dokument

Der Benutzer gibt seine nationale Ausweisnummer und einige persönliche Daten ein, und Didit gleicht diese mit der maßgeblichen Quelle für dieses Land ab. Es wird kein Dokument fotografiert. Diese Quelle ist in den meisten Ländern ein staatliches Register, aber nicht in allen: In Kanada, Frankreich, Indonesien, den Niederlanden, Norwegen, Singapur, dem Vereinigten Königreich und den Vereinigten Staaten handelt es sich stattdessen um eine Datei einer Kreditauskunftei, eines Finanzdienstleisters, eines Versorgungsunternehmens oder eine Datei mit Wohnsitzdaten. Da sich die Herkunft und die geltenden Einwilligungsvorschriften damit unterscheiden, wird die genaue Quelle pro Land in der folgenden Tabelle und unter Abfrage ohne Dokument namentlich genannt — niemals verallgemeinert. Gibt die Quelle ein Porträtfoto zurück — derzeit in Südafrika, Nigeria, Argentinien und Panama, bei allen vier handelt es sich um staatliche Register —, wird der Benutzer zusätzlich um ein Selfie gebeten. Auf diesem Selfie wird eine passive Liveness-Erkennung durchgeführt und es erfolgt ein Gesichtsabgleich mit dem Registerporträt, alles innerhalb der Abfrage und im Abfragepreis enthalten. Liefert die Quelle ausschließlich Daten zurück, gibt es kein Gesicht, mit dem ein Gesichtsabgleich durchgeführt werden kann, sodass kein Selfie aufgenommen wird; führen Sie Liveness-Erkennung und Gesichtsabgleich als eigene Workflow-Schritte aus, falls Sie diese benötigen. Vollständige länderspezifische Anfragefelder, Formatierungsregeln und Einwilligungsregelungen finden Sie unter Abfrage ohne Dokument.

​
Wallet

Der Benutzer meldet sich mit einer digitalen Identität an, die er bereits besitzt, beispielsweise einer nationalen eID oder einer Bankidentität. Die Wallet authentifiziert ihn und teilt anschließend signierte Identitätsattribute mit Didit. Je nach Wallet gibt der Benutzer möglicherweise einen persönlichen Identifikationscode oder eine Telefonnummer ein; für die Wallet-Prüfung ist kein Dokumentenfoto erforderlich. Der Ablauf der Anmeldung hängt von der Wallet ab: eine App-Weiterleitung, ein QR-Code oder ein Abgleichcode, der auf dem Smartphone des Benutzers bestätigt wird. Smart-ID und Mobile-ID verwenden einen Abgleichcode. Attribute pro Wallet, Verfügbarkeit in der Produktionsumgebung und Fehlerverhalten finden Sie unter Digitale ID-Wallets.

​
Vertrauensstufen

Jedes Ergebnis der Ausweisverifizierung enthält eine Vertrauensstufe, die von der Methode abgeleitet wird, die es erzeugt hat. Die Stufe ist eine ehrliche Beschreibung dessen, was tatsächlich nachgewiesen wurde, keine Rangfolge:
Vertrauensstufen sind ein Label für Administratoren. Sie erscheinen in der Sitzungs-Payload, in der Konsole und in Exporten. Endbenutzer sehen die Stufe, den Preis oder den Namen der abgefragten Quelle niemals.

​
Methoden pro Land konfigurieren

Methoden befinden sich unter dem Schlüssel methods in der Konfiguration der Funktion Ausweisverifizierung (OCR), nach dem ISO 3166-1 alpha-3-Ländercode aufgeschlüsselt. Wird der Schlüssel weggelassen, ein Land ausgelassen oder eine Methode innerhalb eines Landes weggelassen, ist für dieses Land nur die Dokumentaufnahme aktiv.
Beide oben genannten Länder sind im veröffentlichten Katalog für Abfragen als available gekennzeichnet. Im Beispiel sind Wallets deaktiviert, damit es nicht davon abhängt, dass in Ihrer Umgebung eine Wallet aktiviert ist. Ein Workflow, der eine als Demnächst markierte Wallet aktiviert, wird abgelehnt, einschließlich der übrigen Konfiguration dieses Speichervorgangs. Sobald der Katalog eine Wallet in einem Land als available ausweist, sieht der Wallet-Block für dieses Land wie folgt aus:
Prüfen Sie den Katalog, bevor Sie die Anfrage senden. Voraussetzung: Die Wallet wird für dieses Land als verfügbar geführt, wie unter Digitale ID-Wallets aufgeführt. Zwei Regeln, die die API beim Speichern durchsetzt:
  • Verfügbarkeit wird serverseitig bestimmt. Eine Methode oder eine Wallet, die im Funktionskatalog für dieses Land nicht als available markiert ist, wird abgelehnt. Lesen Sie den Katalog zuerst aus — über den Reiter Länder in der Konsole oder mit dem MCP-Tool didit_workflow_get_id_verification_methods_catalog.
  • Wallets sind eine Positivliste, niemals eine Rangfolge. providers legt fest, welche Wallets ein Land anbieten darf. Die von Ihnen übermittelte Reihenfolge hat keine Bedeutung und wird normalisiert; die Auswahl trifft der Endbenutzer.
Die vollständige Referenz aller Felder einschließlich Standardwerten und Validierung finden Sie unter Workflow-Funktionskonfigurationen.

​
Fallback: Was passiert, wenn eine Methode ohne Dokument nicht greift

Vier Schalter bestimmen, was als Nächstes geschieht. Jeder von ihnen ist entweder fallback_to_document (den Benutzer zur Dokumentenerfassung weiterleiten) oder decline (die Sitzung mit einer abgelehnten Ausweisverifizierung beenden); wallet.on_failure akzeptiert zudem retry, wie unten beschrieben. Für alle vier gilt standardmäßig fallback_to_document. wallet.on_failure akzeptiert außerdem einen dritten Wert, retry, für ein Land, das ausschließlich die Wallet zulässt (Dokumentenerfassung deaktiviert): retry gilt nur für Wallets: Die Lookup-Schalter akzeptieren fallback_to_document oder decline, da bei einem Register, das „keine Übereinstimmung“ gemeldet hat, kein erneuter Versuch möglich ist. Die Kombination mit document.fallback_only wird abgewiesen, da hierfür ein Fehler erforderlich ist, der zur Dokumentenerfassung führt. Eine Wallet, bei der die Anmeldung erfolgreich war und Daten zurückgegeben wurden, die die Prüfungen Ihres Workflows (Alter, Namensabgleich usw.) nicht bestehen, gilt als verifizierte Anmeldung: Hierüber entscheiden die Regeln des Workflows, wallet.on_failure greift nicht. Eine Anmeldung, deren Token zwar echt, aber unzulässig ist (falsches Vertrauensniveau, fehlerhafte Signatur, fehlende erforderliche Claims), zählt als Fehlschlag und folgt wallet.on_failure. id_lookup.max_attempts (1 bis 5, Standardwert 1) gibt an, wie viele beantwortete Lookups der Benutzer durchführen darf, bevor der Schalter auslöst. Eine Nummer, die die clientseitige Formatprüfung nicht besteht, erreicht das Register gar nicht erst und verbraucht somit keinen Versuch – der Benutzer wird lediglich aufgefordert, sie zu korrigieren. Ein Fallback von einer Wallet oder einem Lookup auf die Dokumentenerfassung ist nur möglich, wenn die Dokumentenerfassung für dieses Land aktiviert ist und dort mindestens ein Dokumenttyp akzeptiert wird. Ist die Dokumentenerfassung deaktiviert oder wird für das Land kein Dokumenttyp akzeptiert, wird die Sitzung bei einer fehlgeschlagenen Anmeldung oder einem Lookup ohne Übereinstimmung abgelehnt – selbst wenn der Schalter auf fallback_to_document steht. Die Ausnahme ist wallet.on_failure: retry, was niemals ablehnt: Der Benutzer verbleibt auf dem Wallet-Schritt. Es gibt in diesem Fall keine Fallback-Möglichkeit. Welche Methode das Ergebnis geliefert hat: fallback_from verification_method benennt stets die Methode, die das verifizierte Ergebnis hervorgebracht hat: wallet, id_lookup oder document. fallback_from erklärt in beiden Fällen, warum eine Methode ohne Dokument den Ausweisschritt nicht abgeschlossen hat:
  • Fallback durchgeführt. Der Benutzer wird zur Dokumentenerfassung weitergeleitet. Die anschließende Dokumentenverifizierung hat verification_method: "document" und fallback_from nennt die Methode, die fehlgeschlagen ist, zum Beispiel { "method": "wallet", "reason": "cancelled", "action": "fallback_to_document" }. Eine Sitzung, die über die Wallet verifiziert wurde, hat verification_method: "wallet" und fallback_from: null.
  • Ablehnung. Der Schalter steht auf decline oder es steht kein Dokument für ein Fallback zur Verfügung. Die abgelehnte Ausweisverifizierung enthält fallback_from mit "action": "decline".
method ist wallet oder id_lookup, und reason ist das Ergebnis, das dazu geführt hat (cancelled, timeout, no_match, provider_error usw.). Dieselben Felder werden bei der Sitzungsentscheidung und im status.updated-Webhook übermittelt. Ein Register, das nicht antwortet (ein Timeout oder ein Ausfall), bildet die Ausnahme: Es führt für sich allein niemals zur Ablehnung des Benutzers. Der Lookup wird nicht abgerechnet und es wird kein Versuch verbraucht; der Benutzer wird gebeten, es erneut zu versuchen. Nach drei unbeantworteten Lookups in diesem Schritt greift id_lookup.on_provider_error: decline lehnt die Sitzung ab und fallback_to_document leitet den Benutzer zur Dokumentenerfassung weiter. Steht dieser Schalter auf fallback_to_document, aber das Land verfügt über kein Dokument für ein Fallback, bleibt der Lookup geöffnet und der Benutzer kann es weiter versuchen; die Sitzung wird nicht abgelehnt.

​
Dokumentenerfassung nur als Fallback anbieten

Standardmäßig zeigt ein Land, das eine Wallet oder einen ID-Lookup zusammen mit der Dokumentenerfassung anbietet, beide Optionen nebeneinander auf dem ersten Bildschirm an. Setzen Sie document.fallback_only auf true, um die Dokumentenerfassung für das Land aktiviert zu lassen, ohne sie direkt anzubieten. Benutzer beginnen mit der Wallet oder dem ID-Lookup des jeweiligen Landes. Gibt es nur eine einzige Wallet, gelangt der Benutzer direkt zu dieser Wallet. Nur Benutzer, deren Wallet-Anmeldung fehlschlägt, abgebrochen wird oder bei der ein Timeout auftritt, oder deren Lookup keine Übereinstimmung liefert, werden zur Dokumentenerfassung weitergeleitet. Welche dieser Ergebnisse zur Dokumentenerfassung führen, entscheiden weiterhin die obigen Schalter, daher muss mindestens einer von ihnen auf fallback_to_document gesetzt sein.
fallback_only ist optional und standardmäßig auf false gesetzt. Es wird abgewiesen, sofern nicht document.enabled auf true steht und mindestens eine Wallet oder ein ID-Lookup in diesem Land ein Fallback auf die Dokumentenerfassung vorsieht. Aktivieren Sie in documents_allowed die Dokumenttypen, die der Fallback anbieten soll, beispielsweise Reisepass und Personalausweis für Finnland.

​
Was jede Methode kostet

Dies sind Listenpreise: Ihr Tarifrabatt gilt für beide Methoden. Ein Lookup nutzt die öffentlichen Endkundenpreise der Datenbankvalidierung für die ausgeführten Dienste; mehrere Dienste können zu einem Versuch beitragen. Nigeria wählt entweder NIN oder BVN. Die Ländertabelle zeigt den vollständigen konfigurierten Preis pro Versuch, wobei jeder beantwortete Wiederholungsversuch separat abgerechnet wird.

​
Abrechnungsregeln

  • Ein Register, das geantwortet hat, führt zur Abrechnung des Lookups. Übereinstimmung, teilweise Übereinstimmung und keine Übereinstimmung zählen alle – die Abfrage wurde ausgeführt und die Antwort ist die abrechenbare Leistung.
  • Ein Register, das nie geantwortet hat, wird nicht abgerechnet. Ein Anbieterfehler kostet nichts.
  • Eine Nummer, die die clientseitige Formatprüfung nicht besteht, wird niemals abgerechnet und wird niemals auf max_attempts angerechnet, da sie das Register nie erreicht hat.
  • Die Dokumentenerfassung wird zusätzlich abgerechnet, wenn der Benutzer ein Fallback durchführt. Ein Lookup, der eine Antwort erhalten hat und anschließend auf ein Dokument zurückfiel, führt zu zwei Gebühren, da zwei Prüfungen durchgeführt wurden.

​
Abdeckung

Die Dokumentenerfassung ist in jedem von Didit unterstützten Land verfügbar und wird unten nicht wiederholt aufgeführt: $0.15 pro Prüfung. Diese Tabelle listet nur die Länder auf, in denen eine Methode ohne Dokument existiert. Ein Land, das nicht aufgeführt ist, oder eine Zelle mit dem Eintrag Nicht geplant, unterstützt ausschließlich die Dokumentenerfassung.
Die Abdeckung wird aus dem Leistungskatalog generiert, den das Backend bereitstellt. Diese Tabelle entspricht somit derselben Quelle, gegen die die Konsole und die API validieren. Demnächst bedeutet, dass der Eintrag in der Konsole sichtbar ist und noch nicht aktiviert werden kann; es handelt sich nicht um eine produktive Funktion und es gibt kein verbindliches Datum.

​
Was in der Sitzung enthalten ist

Jedes Ergebnis der Ausweisverifizierung enthält die Methode, mit der es erzeugt wurde, dessen Vertrauensstufe und — wenn eine dokumentenlose Methode ausgeführt wurde — einen methodenspezifischen Nachweisblock. Dokumentensitzungen sehen exakt so aus wie zuvor, wobei die neuen Schlüssel auf null gesetzt sind. Feldweise Typen und Beispiele für alle drei Methoden finden Sie im Datenmodell der Ausweisverifizierung, und dieselben Schlüssel werden über den Webhook status.updated übermittelt.
Zuletzt geändert am 7. November 2026