Identitätsszenarien
Du entscheidest, wie eine Prüfung ausgeht, indem du die Person oder das Unternehmen nach dem gewünschten Ergebnis benennst.
Nenn den Antragsteller sanctions_match, und der Fall kommt abgelehnt zurück, mit dem Treffer auf der Screening-Prüfung statt auf der Dokumentprüfung. Nenn ihn approve, und alles geht durch.
Das Prüfsubjekt benennen
Der Name wird zuerst geprüft, ohne Rücksicht auf Groß- und Kleinschreibung, und er passt vollständig oder auf sein letztes Wort. sanctions_match und Jane sanctions_match funktionieren also beide, was zählt, wenn ein Formular auf einem Vornamen besteht.
Nutze approve für einen sauberen Durchlauf, oder eine dieser Ablehnungen:
- Dokumente:
document_expired,document_not_supported,document_unreadable,document_tampered,document_type_mismatch - Gesicht und Lebendprüfung:
face_mismatch,face_not_detected,liveness_failed - Screening:
sanctions_match,pep_match,adverse_media_match,watchlist_match - Angegebene Daten:
data_mismatch,identity_not_found,address_not_verified,phone_not_verified,email_not_verified,underage - Unternehmen:
business_not_found,business_inactive,ownership_not_verified,tax_id_mismatch - Risiko:
device_risk,blocklisted,duplicate_subject
Jede Ablehnung landet auf der Prüfung, zu der sie gehört. Forderst du für einen Antragsteller namens pep_match eine Dokument- und eine Screening-Prüfung an, bekommst du einen sauberen Dokumentbericht und eine Ablehnung beim Screening. Genau diese Form muss dein Code in der Produktion ohnehin verarbeiten.
Andere Ergebnisse als bestanden oder abgelehnt
Drei Namen erzeugen die Zustände, die sich sonst am schwersten herstellen lassen:
reviewgibt einen Fall zurück, den ein Mensch ansehen soll. Alle Prüfungen laufen, und die genannte kommt ergebnislos statt fehlgeschlagen zurück.pendinggibt einen Fall zurück, der noch nicht antwortet. Er läuft weiter, bis er erneut gelesen oder fortgesetzt wird, und genau darauf ist eine abfragende Integration geschrieben.hostedgibt einen Fall zurück, der darauf wartet, dass das Prüfsubjekt die Erfassung selbst abschließt. Folge dem Link in der Antwort und schließe sie dort ab.
Ein Anbieter ohne gehostete Strecke genehmigt hosted stattdessen, derselbe Test läuft also trotzdem.
Prüfsubjekte, die du nicht benannt hast
Eine gehostete Erfassung, eine SDK-Strecke oder ein importiertes Prüfsubjekt kommt mit einem Namen, den du nicht gewählt hast. Vier andere Auslöser erreichen diese:
- Die E-Mail
declined@example.com,sanctioned@example.com,review@example.comoderpending@example.com. - Das Geburtsdatum
2015-01-01, für jemanden, der zu jung ist. - Das Land
KP, für ein Prüfsubjekt, das ein sanktioniertes Land angibt. Schreib es mit zwei Buchstaben, drei Buchstaben oder als Zahl: Alle drei Formen erreichen denselben Auslöser, in welcher Form der Anbieter es auch speichert. - Deine eigene Referenz, sofern der Anbieter eine annimmt.
Die Testdaten des Anbieters
Jeder Anbieter behält die Werte aus seiner eigenen Dokumentation. Onfidos Antragstellernamen clear und consider funktionieren, ebenso die Dokumentnummern aus seiner Sandbox. Persona antwortet auf pass und fail sowie auf Referenzen wie test-declined.
Welcher Auslöser gewinnt
Ein Fall nimmt den ersten Auslöser, der passt, in dieser Reihenfolge:
- Name, vollständig oder auf das letzte Wort
- Deine eigene Referenz
- Dokumentnummer
- Geburtsdatum
- Land
- Prüfungsart
Sehen, worauf ein Anbieter antwortet
Öffne die Sandbox, geh auf Szenarien und wähle einen Anbieter.
Mitgeliefert ist der eigene Satz dieses Anbieters.
Gemeinsam ist die Grundlage, auf die jeder Anbieter antwortet, also die Liste oben auf dieser Seite.
Beide sind schreibgeschützt, und beide sind zum Abschreiben da.
Wenn die eingebaute Liste nicht reicht
Schreib deine eigene. Deine werden vor allem Mitgelieferten geprüft.
Siehe Eigene Szenarien schreiben.