Didit schickt keine E-Mail, wenn sich ein Verifizierungsstatus ändert. Richten Sie einen Webhook ein, damit Ihr Backend es erfährt, und prüfen Sie die Signatur.
Ein Webhook ist eine HTTP-Anfrage, die Didit an Ihre URL sendet, wenn sich etwas ändert. Fügen Sie ein Ziel unter Entwickler → Webhooks hinzu, abonnieren Sie die gewünschten Ereignisse - es gibt kein Wildcard, listen Sie jedes einzeln auf - speichern Sie das Signing-Secret, und prüfen Sie die Signatur, bevor Sie irgendetwas verarbeiten.
Didit sendet keine E-Mail, wenn eine Session zu In Review oder Declined wechselt. Um in dem Moment davon zu erfahren, in dem sich ein Status ändert, ohne die Konsole zu aktualisieren, richten Sie einen Webhook ein - eine URL auf Ihrem Server, an die Didit das Update automatisch sendet.
Webhooks sind das empfohlene Integrationsmuster. Das Pollen des Decision-Endpoints funktioniert als Fallback, ist aber langsamer, kostet mehr Anfragen und verpasst Ereignisse, die ausschließlich per Webhook zugestellt werden - Datenbearbeitungen durch einen Prüfer, Statusänderungen bei Transaktionen und Änderungen auf Entity-Ebene.
#Einrichtung
- Entwickler → Webhooks
Öffnen Sie die gewünschte Anwendung und Live- oder Sandbox-Umgebung, dann Entwickler und Webhooks.
- Endpunkt hinzufügen
Klicken Sie auf Endpunkt hinzufügen, geben Sie HTTPS-URL und Namen ein und wählen Sie die Ereignisse. Behalten Sie die empfohlene Version v3 bei, sofern Sie keine ältere Integration pflegen. Prüfen und bestätigen Sie.
- Das Signing-Secret speichern
Jeder Endpunkt hat ein eigenes maskiertes Signaturgeheimnis. Klicken Sie auf Anzeigen und bestätigen Sie Ihre Identität; nach spätestens 60 Sekunden wird es wieder verborgen. Speichern Sie es in der Serverkonfiguration. Bei deaktivierter Anzeige hilft der Support. Entwickler → Webhooks.
- Testereignis senden
Senden Sie ein signiertes Testereignis, um Endpunkt, Signatur und Verarbeitung ohne echte Verifizierung zu prüfen.
#Die Ereignisse, die Sie abonnieren können
Es gibt kein Wildcard - listen Sie jede Ereignisfamilie auf, die Sie möchten. Sie auf mehrere Ziele zu verteilen ist in Ordnung und oft übersichtlicher.
| Ereignis | Feuert wenn |
|---|---|
status.updated | Sich der Status einer KYC- oder KYB-Session ändert. Das, das Sie fast sicher wollen |
data.updated | Verifizierungsdaten nach der Erstellung bearbeitet werden - ein Prüfer korrigiert ein Feld |
user.status.updated | Ein konsolidierter Nutzer zwischen ACTIVE, FLAGGED und BLOCKED wechselt |
user.data.updated | Sich Profil, Zähler oder Kennungen eines konsolidierten Nutzers ändern |
business.status.updated | Ein konsolidiertes Unternehmen den Status wechselt |
business.data.updated | Sich die Daten eines konsolidierten Unternehmens ändern |
transaction.created | Eine Transaktion erstellt wird und ihr erstes Urteil bereitsteht |
transaction.status.updated | Sich der Status einer Transaktion danach ändert |
travel_rule.status.updated | Sich der Status eines Travel-Rule-Austauschs ändert |
Es gibt kein session.status.updated oder kyc.completed. Wenn Sie einen Namen abonniert haben, der
nicht in dieser Liste steht, erhalten Sie nichts - und es wird genau wie ein Zustellfehler aussehen.
Prüfen Sie zuerst den Namen.
#Was Ihr Endpunkt tun sollte
- Prüfen Sie zuerst die Signatur. HMAC-en Sie den rohen Request-Body - niemals eine neu serialisierte Version des geparsten JSON, denn erneutes Serialisieren ändert die Bytes und die Signatur stimmt nicht mehr überein. Verwenden Sie einen zeitkonstanten Vergleich.
- Geben Sie schnell 2xx zurück. Erledigen Sie aufwendige Arbeit asynchron, nachdem Sie geantwortet haben.
- Seien Sie idempotent. Schlüsseln Sie über die Event-ID, oder über Session-ID + Status + Webhook-Typ. Wiederholungen und Duplikate kommen vor.
- Behandeln Sie jeden Status, der Sie interessiert, einschließlich derer, die lange nach dem Onboarding eintreffen - eine genehmigte Session kann später durch laufendes AML-Monitoring zu In Review wechseln.
- Nur HTTPS. Reine HTTP-Endpunkte werden nicht unterstützt.
#Wiederholungen
Bei 5xx oder 404 versucht Didit die Zustellung zweimal erneut, nach etwa einer und dann vier Minuten. Zeitüberschreitungen nach 5 Sekunden und Verbindungsfehler werden nicht automatisch wiederholt. Nutzen Sie nach der Korrektur Erneut senden unter Zustellungen; ein endgültiger Fehler löst eine Warnung aus.
Verlassen Sie sich nicht auf die Zustellung jedes Webhooks. Senden Sie nach einem Ausfall erneut oder fragen Sie die Entscheidung jeder Sitzung ohne erhaltenes Ergebnis ab.
#Hinter einer Firewall oder WAF
Didit liefert von der statischen IP 18.203.201.92 mit einem DiditWebhook/2.0-User-Agent aus. Wenn Ihr Edge unbekannte Clients blockiert - Cloudflares Standardhaltung zum Beispiel - erlauben Sie diese IP für den empfangenden Hostnamen, oder Zustellungen scheitern, bevor sie Ihren Code erreichen.
#Noch kein Backend?
Sie können Ergebnisse weiterhin manuell im Bereich Verifications der Konsole überwachen, während Sie eines aufbauen, oder in der Zwischenzeit einen No-Code-Verifizierungslink nutzen.
#Nächste Schritte
- Wenn ein Webhook nicht ankommt: wenn ein Webhook nie ankommt
- Verstehen, was jeder Status bedeutet, sobald er ankommt: was jeder Session-Status bedeutet
- Vollständige technische Referenz, einschließlich Codebeispielen zur Signaturprüfung: Webhooks
Kommen Sie nicht weiter? Sprechen Sie mit einem Menschen.
Geben Sie Ihre Organisations-ID und die Session-ID an, um die es geht.