Validation en base de données - activer les services et ce qui est facturé
La validation en base de données confronte les données d'identité extraites à un registre officiel ou autorisé. Pourquoi un service affiche "Nécessite une activation", pourquoi il renvoie 403 ou rien du tout, et quelles requêtes sont facturées.
La validation en base de données s'exécute en arrière-plan contre un registre officiel : la personne ne la voit jamais. Elle ne s'active qu'après la première recharge de votre organisation, certains services affichent en plus "Nécessite une activation" tant que Didit ne les a pas activés pour vous, et chaque requête à laquelle le registre répond est facturée, y compris une non-correspondance.
Lire le document vous dit ce qui y est imprimé. La validation en base de données vous dit si une source autorisée est d'accord : un registre d'état civil, une administration fiscale, un bureau de crédit, une base de permis de conduire. Chaque pays expose un ou plusieurs services, chacun avec son prix, ses données d'entrée et ses règles de consentement. Voir pays et services pris en charge et tarifs par service.
#Elle s'exécute en silence, après l'étape du document
Il n'y a pas d'écran de validation en base de données. L'étape prend les données extraites de la pièce d'identité (ou celles que vous avez transmises à la création de la session), les envoie au registre et enregistre la réponse dans le rapport de la session. Deux conséquences en découlent :
- Si l'étape d'identité a extrait un mauvais numéro ou un mauvais nom, le registre est interrogé avec la mauvaise valeur et la vérification échoue ou revient non concluante. Corrigez d'abord l'extraction. Voir corriger un nom ou un champ mal lu.
- Vous ne pouvez pas "resoumettre" une validation en base de données à l'utilisateur comme vous resoumettez une pièce d'identité ou un selfie, car il n'y a rien à refaire de son côté. Demander une resoumission de
DATABASE_VALIDATIONrenvoie une erreur indiquant que la fonctionnalité ne fait pas partie des étapes resoumissibles de la session. Pour la relancer, appelez l'API autonome de validation en base de données avec les données corrigées. Cet appel est facturé par requête comme n'importe quel autre.
#Pourquoi elle ne s'exécute pas
Vérifiez dans cet ordre. Cela explique presque tous les signalements "la validation en base de données n'a rien fait".
- Votre organisation a-t-elle déjà rechargé ?
La validation en base de données (et la vérification téléphonique) ne s'active qu'après une première recharge. Les crédits de bienvenue, y compris les 10 $ offerts à la création du compte, ne comptent pas. Jusque-là l'étape est ignorée, une session peut revenir approuvée alors que la vérification n'a silencieusement pas eu lieu, et un appel direct à
POST /v3/database-validation/répond 403. Voir recharges, factures et moyens de paiement. - Le service est-il marqué Nécessite une activation ?
Dans l'étape de validation en base de données du workflow, certains services affichent "Nécessite une activation. Contactez le support Didit pour l'activer." Le service est visible mais désactivé pour votre organisation tant que Didit ne l'a pas activé. Ce n'est pas un bug et il n'y a pas d'interrupteur en libre-service : ouvrez un ticket de support en indiquant le service et le pays, et l'équipe lance l'activation.
- Le pays est-il seulement configuré ?
Un appel API pour un pays que vous n'avez jamais sélectionné dans le workflow, ou un appel autonome pour un service que vous n'avez pas activé, répond "No database validation services configured" pour ce pays. Ajoutez le service à l'étape, ou transmettez le
service_idexact indiqué sur la page du pays. - Le solde est-il positif ?
La validation en base de données n'est jamais dans l'offre gratuite. Un solde nul ou négatif renvoie
insufficient_credits, comme toute fonctionnalité payante. Voir corriger une erreur "crédits insuffisants".
#Services nécessitant une activation auprès du fournisseur
Une poignée de sources gouvernementales exige que Didit inscrive votre organisation auprès du fournisseur, et pas seulement qu'il bascule un interrupteur. Aujourd'hui cela concerne :
- Australie (DVS : permis de conduire, passeport, visa, Medicare et les autres services DVS)
- Nouvelle-Zélande (DIA : passeport, citoyenneté, registres de naissance et de décès, permis de conduire)
- Canada (services de bureau de crédit et de rapprochement de type FINTRAC)
Pour ceux-ci, le support vous envoie les formulaires du fournisseur, le fournisseur émet des identifiants pour votre compte, et l'activation prend généralement jusqu'à deux semaines. L'Australie et la Nouvelle-Zélande ont historiquement exigé en plus un accord de service minimum (un montant prépayé unique, actuellement 5 000 USD, versé sur votre solde sous forme de crédits qui n'expirent jamais). Cette exigence ne concerne que l'accès aux registres de ces deux pays, aucune autre fonctionnalité Didit, et elle est en cours de révision à mesure que Didit finalise sa propre accréditation auprès du dispositif australien ; demandez au support les conditions en vigueur avant de bâtir un plan dessus.
Certains services exigent aussi le consentement explicite de l'utilisateur final avant l'envoi de la requête (par exemple la vérification de passeport DIA néo-zélandaise). L'étape du workflow signale ces services, et le consentement doit être recueilli dans votre parcours avant que la vérification puisse s'exécuter.
#Ce qui est facturé
Vous payez par service, pour chaque requête à laquelle le registre répond, au prix indiqué sur la page du service. Lisez-le comme "le registre a été interrogé et a répondu", pas comme "la réponse était celle que vous espériez" :
| Résultat | Facturé ? |
|---|---|
| Correspondance, correspondance partielle, non-correspondance | Oui |
| Non concluant, image biométrique inutilisable | Oui |
| Format de document invalide, entrée invalide (rejetée par le registre) | Oui |
REGISTRY_UNAVAILABLE, REGISTRY_ERROR (le registre n'a jamais répondu) | Non |
| Requête rejetée avant d'atteindre le registre (400 sur l'API autonome, ou étape du workflow ignorée pour champs manquants ou mal formés) | Non |
Une session peut déclencher plusieurs requêtes facturées si elle exécute plusieurs services, et une requête est facturée une fois par service, pas par pays. Détail complet : tarifs de la validation en base de données et codes de résultat.
Un résultat vide n'est pas une non-correspondance. Si un service ne renvoie rien du tout au
lieu d'un résultat NO_MATCH, les causes habituelles sont la règle de la première recharge, un
service en attente d'activation ou une panne du registre ; à écarter avant de déboguer votre
intégration. Voir erreurs d'API et leur signification.
#Ce qui est renvoyé
Chaque service renvoie un code de résultat standard plus les données propres du registre lorsque la source le permet : quels champs ont correspondu, un score de correspondance lorsque le registre note au lieu de répondre oui ou non, et pour les services biométriques (RENAPER en Argentine, BVN au Nigeria, Panama) une comparaison faciale avec le portrait du registre. Ce que Didit conserve de cette réponse dépend des paramètres Données retournées de l'étape. Voir choisir les données renvoyées par une vérification et le rapport de validation en base de données.
#Tester avant la mise en production
Les applications sandbox n'atteignent jamais un vrai registre et ne consomment jamais de crédits : un scénario sandbox comme decline_database_no_match force le résultat que vous voulez répéter. Ce que la sandbox ne peut pas vous dire, c'est si un service donné est provisionné pour votre organisation en production ; il faut pour cela la première recharge et un appel réel. Voir tester en sandbox.