Zum Hauptinhalt springen
Jede Verifizierungssitzung durchläuft eine Reihe von Statuswerten. Wenn Sie diese verstehen, können Sie den Fortschritt der Benutzer überwachen, Compliance-Entscheidungen automatisieren und die Konversion optimieren. Dieses Enum ist die zentrale Referenz für die Zeichenfolgen, die von GET /v3/session/<id>/decision/ und jedem Didit-Webhook zurückgegeben werden.

Alle Statuswerte

Jeder Status ist ein exakter String, der von der Didit-API und Webhooks zurückgegeben wird. Verwenden Sie in Ihrem Code immer einen strikten Zeichenfolgenabgleich (z. B. === "In Review") – bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden und sie enthalten Leerzeichen. Der Wert Kyc Expired verwendet zudem nur ein einzelnes großes K (nicht KYC).

Sitzungsstatus

API-Wert: "Not Started"Die Sitzung wurde über die API erstellt, aber der Benutzer hat den Verifizierungslink noch nicht geöffnet.
  • Was zu tun ist: Warten Sie, bis der Benutzer beginnt, oder senden Sie eine Erinnerung, wenn zu viel Zeit vergeht.
  • Geht über in: "In Progress", "Expired"
API-Wert: "In Progress"Der Benutzer hat den Link geöffnet und schließt aktiv Verifizierungsschritte ab (Dokumentenerfassung, Liveness-Erkennung etc.).
  • Was zu tun ist: Keine Aktion erforderlich — der Benutzer durchläuft den Ablauf.
  • Geht über in: "Approved", "Declined", "In Review", "Abandoned"
API-Wert: "Approved"Alle Verifizierungsprüfungen wurden erfolgreich bestanden. Die Identität des Benutzers wurde verifiziert.
  • Was zu tun ist: Gewähren Sie dem Benutzer Zugriff, aktualisieren Sie sein Profil und speichern Sie die Entscheidungsdaten.
  • Webhook enthält: Vollständiges decision-Objekt mit allen Funktionsergebnissen.
  • Geht über in: "Kyc Expired" (wenn das Ablaufdatum des verifizierten Dokuments überschritten wird — Standardeinstellung, sofern der Expiration mode für dieses Land und diesen Dokumenttyp nicht auf Allow expired gesetzt ist). Ein Prüfer oder der Update-Status-Endpoint kann den Status auch auf "Declined" oder "Resubmitted" setzen.
API-Wert: "Declined"Eine oder mehrere Verifizierungsprüfungen sind fehlgeschlagen. Der Benutzer hat die Verifizierung nicht bestanden.
  • Was zu tun ist: Benachrichtigen Sie den Benutzer. Fordern Sie optional eine erneute Einreichung an, falls das Problem behebbar ist.
  • Webhook enthält: Vollständiges decision-Objekt mit Warnungen, die das Fehlschlagen erklären.
  • Geht über in: "Resubmitted" (falls von einem Prüfer angefordert). Ein Prüfer oder der Update-Status-Endpoint kann den Status auch auf "Approved" setzen.
API-Wert: "In Review"Automatische Prüfungen haben Warnungen ausgelöst, die eine manuelle Prüfung erfordern. Ein Compliance-Prüfer muss die endgültige Entscheidung treffen.
  • Was zu tun ist: Ein Prüfer sollte die Sitzung in der Console öffnen und sie genehmigen, ablehnen oder eine erneute Einreichung anfordern.
  • Webhook enthält: Vollständiges decision-Objekt mit Warnungen.
  • Geht über in: "Approved", "Declined", "Resubmitted"
API-Wert: "Awaiting User"Wird in KYB-Sitzungen (Unternehmensverifizierung) verwendet, wenn im Schritt „Key People“ die Liste der Parteien übermittelt und untergeordnete KYC- / KYB-Sitzungen erstellt wurden. Die übergeordnete Sitzung wartet, bis alle erforderlichen Parteien ihre individuelle Verifizierung abgeschlossen haben.
  • Was zu tun ist: Überwachen Sie die Status der untergeordneten KYC-Sitzungen. Sobald alle erforderlichen Parteien fertig sind (genehmigt, abgelehnt oder abgelaufen), fasst die übergeordnete Sitzung diese automatisch zu ihrem finalen Status zusammen.
  • Webhook enthält: Die aktuelle Liste der Parteien und die Status ihrer untergeordneten Sitzungen.
  • Geht über in: "Approved", "Declined", "In Review" (sobald alle untergeordneten Sitzungen einen Endstatus erreicht haben)
  • Übergang von: "In Progress" (nachdem der Schritt „Key People“ übermittelt wurde)
  • Hinweis: Wenn eine untergeordnete KYC-Sitzung erneut eingereicht wird, kehrt die übergeordnete Sitzung zu "Awaiting User" zurück, bis die erneut eingereichte Sitzung abgeschlossen ist. Ein "Declined" beim KYB Registry Check hat Vorrang vor "Awaiting User".
API-Wert: "Resubmitted"Ein Prüfer hat den Benutzer aufgefordert, bestimmte Verifizierungsschritte zu wiederholen (z. B. ein unscharfes Dokumentenfoto neu aufzunehmen).
  • Was zu tun ist: Warten Sie, bis der Benutzer die erneut durchzuführenden Schritte abgeschlossen hat. Das System führt automatisch eine Neubewertung durch.
  • Webhook enthält: resubmit_info-Objekt mit der Liste der zu wiederholenden Funktionen und Gründen.
  • Geht über in: "Approved", "Declined", "In Review" oder "Abandoned", wenn das Sitzungszeitfenster endet, bevor die Person die Schritte wiederholt.
API-Wert: "Expired"Die Sitzung ist abgelaufen, bevor der Benutzer den Verifizierungslink geöffnet hat.
  • Was zu tun ist: Erstellen Sie eine neue Sitzung und senden Sie dem Benutzer einen neuen Link.
  • Terminaler Status — keine weiteren Übergänge.
API-Wert: "Abandoned"Der Benutzer hat die Verifizierung begonnen, aber nicht innerhalb des zulässigen Zeitrahmens abgeschlossen.
  • Was zu tun ist: Senden Sie eine Erinnerung oder erstellen Sie eine neue Sitzung.
  • Keine automatischen Übergänge. Ein Prüfer oder PATCH /v3/session/{sessionId}/update-status/ kann den Status weiterhin auf "Approved", "Declined" oder "Resubmitted" setzen.
API-Wert: "Kyc Expired"Das während der Sitzung verifizierte Dokument hat sein eigenes Ablaufdatum überschritten. Auslöser ist dieses Datum, kein ab der Genehmigung gemessenes Zeitfenster, und es wird zuvor keine Warnung gesendet.
  • Was zu tun ist: Bitten Sie den Benutzer, sich in einer neuen Sitzung erneut zu verifizieren. status.updated übermittelt den Übergang, und das Ergebnis der Ausweisverifizierung enthält eine DOCUMENT_EXPIRED-Warnung.
  • Gesteuert über: den Expiration mode dieses Landes und Dokumenttyps unter Ausweisverifizierung → Additional settings by country & document type — Reject expired (Standard) überwacht das Dokument, Allow expired bedeutet, dass die Sitzung nie diesen Status erhält.
  • Keine automatischen Übergänge. Ein Prüfer oder PATCH /v3/session/{sessionId}/update-status/ kann den Status weiterhin auf "Approved", "Declined" oder "Resubmitted" setzen.

Statusübergänge

Lebenszyklus-Diagramm


Terminal vs. Nicht-Terminal


Statuswerte in Ihrem Code verarbeiten

Verwenden Sie Webhooks oder die Retrieve Session API, um auf Statusänderungen zu reagieren.
Statuswerte sind exakte, groß-/kleinschreibungssensitive Zeichenketten mit Leerzeichen. Zum Beispiel "In Review" (nicht "in_review" oder "IN_REVIEW"). Verwenden Sie beim Abgleich immer strikte Gleichheit (===).

Erneute Einreichung

Der Status Resubmitted ermöglicht es Ihrem Compliance-Team, Benutzern eine zweite Chance zu geben, ohne eine neue Sitzung zu erstellen.
1

Prüfer leitet erneute Einreichung ein

Öffnen Sie in der Konsole eine Sitzung mit Status In Review oder Declined und klicken Sie auf Erneute Einreichung anfordern. Wählen Sie aus, welche Schritte wiederholt werden müssen.
2

Bisherige Daten werden archiviert

Das System setzt die ausgewählten Funktionen zurück und markiert vorherige Daten als previous_attempt — wodurch der vollständige Audit-Trail erhalten bleibt.
3

Benutzer wird benachrichtigt

Wenn eine E-Mail verfügbar ist, erhält der Benutzer eine lokalisierte E-Mail mit einem direkten Link zur Fortsetzung.
4

Benutzer wiederholt bestimmte Schritte

Der Benutzer wiederholt nur die Schritte, die gekennzeichnet wurden — nicht die gesamte Verifizierung.
5

System bewertet neu

Nach Abschluss geht die Sitzung automatisch in "Approved", "Declined" oder "In Review" über.

Webhook-Payload für erneute Einreichung

reasons ordnet jede erneut eingereichte node_id dem Warnungscode des relevantesten Logs für diesen Schritt zu (dieselben Codes, die die Entscheidung meldet), sodass Sie dies Ihren eigenen Texten zuordnen können. Dies ist auch der Code, den der Bildschirm für die erneute Einreichung des gehosteten Flows und die E-Mail zur erneuten Einreichung für den Benutzer lokalisieren, mit Ausnahme von Warnungen, die ein Screening- oder Betrugssignal offenlegen würden (Duplikate, AML, Sperrliste, organisationsübergreifende Prüfungen, Standortintegrität und ähnliches): Für diese sieht die Person einen generischen Grund, und resubmit_info.reasons in Ihrem Webhook enthält immer den echten Code. Ein Schritt ohne aufgezeichnete Warnung hat keinen Eintrag.

Welche Funktionen können erneut eingereicht werden?

Jede Funktion mit einem nicht genehmigten Status: Declined, In Review, Not Finished, Not Started oder Expired.
Sie können für dieselbe Sitzung mehrfach eine erneute Einreichung anfordern. Jeder Zyklus archiviert die Daten des vorherigen Versuchs, sodass Sie vollständige Transparenz über die Verifizierungshistorie des Benutzers haben.

Bewährte Vorgehensweisen

„In Prüfung“ überwachen

Richten Sie Alerts (E-Mail oder Slack) in Ihrer Didit Console ein, um benachrichtigt zu werden, wenn Sitzungen eine manuelle Prüfung erfordern.

Erneute Einreichung bevorzugen

Wenn das Problem behebbar ist (unscharfes Foto, falsche Dokumentenseite), fordern Sie eine erneute Einreichung an, anstatt abzulehnen. Dies verbessert die Konversionsrate.

Abbrüche nachverfolgen

Hohe Raten abgebrochener oder abgelaufener Sitzungen können auf Reibungspunkte in der UX hinweisen. Ziehen Sie in Betracht, die Sitzungs-TTL anzupassen oder die Benutzerführung zu verbessern.

Idempotente Handler

Bei Webhooks kann es zu Wiederholungsversuchen kommen. Verwenden Sie session_id als eindeutigen Schlüssel, um sicherzustellen, dass Sie jede Statusänderung nur einmal verarbeiten.
Verifizieren Sie Webhook-Signaturen immer, bevor Sie Payloads verarbeiten. Didit bietet drei Methoden: X-Signature, X-Signature-V2 (empfohlen) und das veraltete X-Signature-Simple, welches nur die Nachrichtenhülle und niemals den Inhalt von decision authentifiziert. Details finden Sie unter Webhooks.
Zuletzt geändert am 7. November 2026