Datenbankvalidierung - Dienste aktivieren und was berechnet wird
Die Datenbankvalidierung gleicht die extrahierten Identitätsdaten mit einem behördlichen oder autorisierten Register ab. Warum ein Dienst "Erfordert ein Onboarding" anzeigt, warum er 403 oder gar nichts zurückgibt, und welche Abfragen berechnet werden.
Die Datenbankvalidierung läuft im Hintergrund gegen ein offizielles Register: die Person sieht sie nie. Sie wird erst nach der ersten Aufladung Ihrer Organisation aktiv, manche Dienste zeigen zusätzlich "Erfordert ein Onboarding", bis Didit sie für Sie freischaltet, und jede Abfrage, die das Register tatsächlich beantwortet, wird berechnet, auch ein Nicht-Treffer.
Das Auslesen des Dokuments sagt Ihnen, was darauf gedruckt ist. Die Datenbankvalidierung sagt Ihnen, ob eine autorisierte Quelle dem zustimmt: ein Melderegister, eine Steuerbehörde, eine Kreditauskunftei, eine Führerscheindatenbank. Jedes Land stellt einen oder mehrere Dienste bereit, jeder mit eigenem Preis, eigenen Eingaben und eigenen Einwilligungsregeln. Siehe unterstützte Länder und Dienste und Preise pro Dienst.
#Sie läuft still, nach dem Dokumentschritt
Es gibt keinen Bildschirm für die Datenbankvalidierung. Der Schritt nimmt die aus dem Ausweis extrahierten Daten (oder die Daten, die Sie beim Erstellen der Sitzung übergeben haben), sendet sie an das Register und speichert die Antwort im Sitzungsbericht. Daraus folgen zwei Dinge:
- Wenn der Ausweisschritt die falsche Nummer oder den falschen Namen extrahiert hat, wird das Register mit dem falschen Wert abgefragt und die Prüfung schlägt fehl oder kommt als nicht eindeutig zurück. Korrigieren Sie zuerst die Extraktion. Siehe einen falsch gelesenen Namen oder ein Feld korrigieren.
- Sie können eine Datenbankvalidierung nicht an den Nutzer "erneut einreichen" lassen, wie Sie es bei einem Ausweis oder einem Selfie tun, denn es gibt nichts, was die Person wiederholen könnte. Eine Aufforderung zur erneuten Einreichung von
DATABASE_VALIDATIONgibt einen Fehler zurück, dass die Funktion nicht zu den erneut einreichbaren Schritten der Sitzung gehört. Um sie erneut auszuführen, rufen Sie die eigenständige Datenbankvalidierungs-API mit den korrigierten Daten auf. Dieser Aufruf wird wie jeder andere pro Abfrage berechnet.
#Warum sie nicht läuft
Gehen Sie die Punkte der Reihe nach durch. Sie erklären fast jede Meldung "die Datenbankvalidierung hat nichts gemacht".
- Hat Ihre Organisation jemals aufgeladen?
Die Datenbankvalidierung (und die Telefonverifizierung) wird erst nach einer ersten Aufladung aktiv. Willkommensguthaben, einschließlich der 10 $ für neue Konten, zählt nicht. Bis dahin wird der Schritt übersprungen, eine Sitzung kann genehmigt zurückkommen, obwohl die Prüfung stillschweigend nicht durchgeführt wurde, und ein direkter Aufruf von
POST /v3/database-validation/antwortet mit 403. Siehe Aufladungen, Rechnungen und Zahlungsmethoden. - Ist der Dienst als Erfordert ein Onboarding markiert?
Im Datenbankvalidierungsschritt des Workflows zeigen manche Dienste "Erfordert ein Onboarding. Kontaktieren Sie den Didit-Support, um den Dienst zu aktivieren." Der Dienst ist sichtbar, aber für Ihre Organisation deaktiviert, bis Didit ihn freischaltet. Das ist kein Fehler und es gibt keinen Self-Service-Schalter: eröffnen Sie ein Support-Ticket mit Dienst und Land, und das Team startet das Onboarding.
- Ist das Land überhaupt konfiguriert?
Ein API-Aufruf für ein Land, das Sie im Workflow nie ausgewählt haben, oder ein eigenständiger Aufruf für einen Dienst, den Sie nicht aktiviert haben, antwortet mit "No database validation services configured" für dieses Land. Fügen Sie den Dienst dem Schritt hinzu oder übergeben Sie die exakte
service_idvon der Seite des Landes. - Ist das Guthaben positiv?
Die Datenbankvalidierung ist nie Teil des kostenlosen Kontingents. Ein Guthaben von null oder darunter gibt
insufficient_creditszurück, genau wie jede kostenpflichtige Funktion. Siehe einen Fehler "nicht genügend Guthaben" beheben.
#Dienste, die ein Onboarding beim Anbieter brauchen
Eine Handvoll behördlicher Quellen verlangt, dass Didit Ihre Organisation beim Anbieter anmeldet, statt nur einen Schalter umzulegen. Heute gilt das für:
- Australien (DVS: Führerschein, Reisepass, Visum, Medicare und die übrigen DVS-Dienste)
- Neuseeland (DIA: Reisepass, Staatsbürgerschaft, Geburts- und Sterberegister, Führerschein)
- Kanada (Kreditauskunftei- und FINTRAC-artige Abgleichdienste)
Dafür schickt Ihnen der Support die Formulare des Anbieters, der Anbieter stellt Zugangsdaten für Ihr Konto aus, und die Freischaltung dauert in der Regel bis zu zwei Wochen. Australien und Neuseeland haben bisher zusätzlich eine Mindestvereinbarung verlangt (ein einmaliger Vorauszahlungsbetrag, derzeit 5.000 USD, der Ihrem Guthaben als nie verfallende Credits gutgeschrieben wird). Diese Anforderung gilt nur für den Registerzugang dieser beiden Länder, nicht für andere Didit-Funktionen, und sie wird überarbeitet, während Didit seine eigene Akkreditierung im australischen System abschließt; fragen Sie den Support nach den aktuellen Bedingungen, bevor Sie damit planen.
Manche Dienste verlangen außerdem die ausdrückliche Einwilligung des Endnutzers, bevor die Abfrage gesendet wird (zum Beispiel die neuseeländische DIA-Passprüfung). Der Workflow-Schritt kennzeichnet diese Dienste, und die Einwilligung muss in Ihrem Ablauf eingeholt werden, bevor die Prüfung laufen kann.
#Was berechnet wird
Sie zahlen pro Dienst, pro Abfrage, die das Register beantwortet, zum Preis auf der Seite dieses Dienstes. Lesen Sie es als "das Register wurde gefragt und hat geantwortet", nicht als "die Antwort war die erhoffte":
| Ergebnis | Berechnet? |
|---|---|
| Treffer, Teiltreffer, kein Treffer | Ja |
| Nicht eindeutig, biometrisches Bild unbrauchbar | Ja |
| Ungültiges Dokumentformat, ungültige Eingabe (vom Register abgelehnt) | Ja |
REGISTRY_UNAVAILABLE, REGISTRY_ERROR (das Register hat nie geantwortet) | Nein |
| Anfrage abgelehnt, bevor sie das Register erreicht (400 bei der eigenständigen API, oder Workflow-Schritt wegen fehlender oder fehlerhafter Felder übersprungen) | Nein |
Eine Sitzung kann mehrere berechnete Abfragen auslösen, wenn sie mehrere Dienste ausführt, und eine Abfrage wird einmal pro Dienst berechnet, nicht pro Land. Vollständige Aufschlüsselung: Preise der Datenbankvalidierung und Ergebniscodes.
Ein leeres Ergebnis ist kein Nicht-Treffer. Wenn ein Dienst gar nichts zurückgibt statt
eines NO_MATCH-Ergebnisses, sind die üblichen Ursachen die Regel der ersten Aufladung, ein
Dienst, der noch auf das Onboarding wartet, oder ein Registerausfall - alles Dinge, die Sie
ausschließen sollten, bevor Sie Ihre Integration debuggen. Siehe API-Fehler und ihre
Bedeutung.
#Was zurückkommt
Jeder Dienst gibt einen Standard-Ergebniscode plus die eigenen Daten des Registers zurück, soweit die Quelle das erlaubt: welche Felder übereinstimmten, einen Übereinstimmungswert, wenn das Register bewertet statt mit Ja oder Nein zu antworten, und bei biometrischen Diensten (Argentinien RENAPER, Nigeria BVN, Panama) einen Gesichtsabgleich mit dem Porträt des Registers. Was Didit von dieser Antwort speichert, bestimmen die Einstellungen unter Zurückgegebene Daten des Schritts. Siehe auswählen, welche Daten eine Verifizierung zurückgibt und den Bericht zur Datenbankvalidierung.
#Vor dem Livegang testen
Sandbox-Anwendungen erreichen nie ein echtes Register und verbrauchen nie Guthaben: ein Sandbox-Szenario wie decline_database_no_match erzwingt das Ergebnis, das Sie proben möchten. Was die Sandbox Ihnen nicht sagen kann, ist, ob ein bestimmter Dienst für Ihre Live-Organisation bereitgestellt ist; dafür braucht es die erste Aufladung und einen echten Aufruf. Siehe Tests in der Sandbox.