Erste Schritte
Integrieren / SDKs
Benutzerverifizierung
Unternehmensverifizierung
Transaktionsüberwachung
ChangelogNachrichtenzwecke
Dokument-Uploads akzeptieren derzeit JPEG-, PNG- und WebP-Bilder bis 5 MB.
Nur die Zwecke, die auf die betroffene Person im Fall zutreffen, werden angezeigt.
Kunden-E-Mail-Vorlagen sind derzeit auf Englisch, Spanisch und Portugiesisch verfügbar.
Die Konsole verwendet dasselbe E-Mail-Feld und dieselbe Sprachauswahl wie die erneute Einreichung der Sitzung.
Verifizierte Empfänger und feste Vorlagen
Ein Empfänger muss die E-Mail-Verifizierung in einer Sitzung abgeschlossen haben, die der betroffenen Person im Fall und der Anwendung zugeordnet ist. Eine Adresse, die in einem Benutzerprofil importiert oder bearbeitet wurde, begründet keine Verifizierung. Gibt es keinen verifizierten Kontakt, erklärt der Editor dies, und das Senden bleibt deaktiviert. Prüfer können keine beliebigen E-Mail-Texte, Links, Absenderadressen oder Empfänger angeben. Die E-Mail verwendet das bestehende Didit- oder White-Label-Branding. Ein benutzerdefinierter Absender erfordert, dass die konfigurierte E-Mail-Domain verifiziert ist. Jede Vorlage weist den Empfänger darauf hin, dass die E-Mail keine Passwörter, Verifizierungscodes oder Zahlungen anfordert. Das erneute Einreichen einer Sitzung bleibt eine separate Aktion zur Wiederholung von Verifizierungsprüfungen. Die Vorschau zeigt die tatsächliche E-Mail zur erneuten Einreichung und die ausgewählten Prüfungen.Zustellung und Antworten
Der Nachrichtenverlauf unterscheidet die Zustellergebnisse „in der Warteschlange“, „wird gesendet“, „gesendet“, „simuliert“ und „unbekannt“. Eine simulierte E-Mail wird nicht gesendet. Ein unbekanntes Ergebnis bedeutet, dass der Anbieter die E-Mail möglicherweise angenommen hat; das System sendet sie nicht automatisch erneut. Beim erneuten Versuch einer bestätigten Anfrage wird dieselbe Anfrage-ID verwendet, um doppelte Zustellung zu vermeiden. Eine Anfrage, die eine Antwort erfordert, hat einen sicheren Antwort-Link, der sieben Tage gültig ist. Das Abbrechen der Anfrage oder das Abschließen des Falls macht diesen Link ungültig, auch nachdem ein Fall wieder geöffnet wurde. Die Kundenseite gibt keine nicht öffentlichen Ergebnisse des Falls und keine anderen Quelldatensätze preis. Eine übermittelte Antwort erscheint unter Kundennachrichten als Nachweis, dessen Prüfung aussteht. Der Fall wird wieder auf Offen gesetzt, und eine bestehende ausstehende Entscheidung muss erneut geprüft werden. Antworten können eine frühere Einreichung nicht ersetzen, die ursprüngliche Verifizierung nicht genehmigen, die Identität eines Kunden nicht überschreiben und nicht zu einem Ergebnis der Betrugsbewertung beitragen. Das Löschen der zugrunde liegenden Verifizierung oder des Falls löscht auch die zugehörigen Kundenanfragen und deren hochgeladene Nachweise.API-Workflow
Alle Konsolen-Endpoints sind auf eine Organisation, eine Anwendung und einen Fall beschränkt:read:cases erforderlich.
Zum Verfassen, Anzeigen der Vorschau, Bestätigen, Abbrechen und Erinnern ist write:cases erforderlich.
Die Bestätigung muss dieselben contact_id, purpose und language enthalten sowie request_id, expires_at und preview_token, die von der Vorschau zurückgegeben wurden.
Der Bestätigungsnachweis läuft nach 15 Minuten ab, unabhängig von der Antwortfrist des Kunden.
Eine Erinnerung sendet dieselbe E-Mail erneut an denselben verifizierten Empfänger, höchstens einmal pro Anfrage alle 24 Stunden.
Sonst ändert sich nichts: Die Anfrage behält ihre Frist und der Fall behält seinen Status.
Die Antwort enthält die Anfrage, reminded_at, den eigenen delivery_status der Erinnerung (SENT, SIMULATED oder UNKNOWN) und next_reminder_at.
Eine Anfrage, auf die der Kunde nicht mehr antworten muss, gibt 409 mit code case_request_not_waiting und einem reason zurück: answered, cancelled, expired, closed, not_actionable, not_delivered oder contact_unavailable.
Eine zweite Erinnerung innerhalb von 24 Stunden gibt 429 mit code case_request_reminder_too_soon, einem Zeitstempel retry_at und dem Header Retry-After zurück.
Solange eine Entscheidung auf Genehmigung wartet, gibt eine Erinnerung 400 zurück.
Der Kunden-Endpoint ist GET oder POST /v3/case-requests/{request_uuid}/ mit dem anfragespezifischen Header X-Case-Request-Token.
Der Antwort-Link enthält dieses Zugriffstoken in seinem Fragment; die Seite entfernt das Fragment beim Öffnen.
Das Token gewährt nur Zugriff auf diese Anfrage.