Vérification e-mail : avertissements et codes de risque

La fonctionnalité Vérification de l’e-mail émet des avertissements dès qu’un signal de risque se déclenche sur le flux OTP ou sur l’adresse elle-même : une fuite de données connue, un fournisseur d’e-mails jetables, une boîte aux lettres inaccessible, un dépassement de la limite de tentatives d’OTP, ou une correspondance avec votre liste de blocage ou une autre vérification approuvée. Cette page répertorie chaque code, ce qui le déclenche et la manière de configurer la réponse du workflow.

Présentation

Les avertissements sont associés à la fonctionnalité EMAIL. Ils apparaissent dans le rapport sous email_verifications[].warnings[] et suivent la structure standard de l’objet d’avertissement (feature, risk, additional_data, log_type, short_description, long_description, node_id). Chaque avertissement est également acheminé dans le journal de la session afin d’apparaître dans la Business Console dans la section E-mail. Certains avertissements constituent des déclencheurs de refus automatique strict — ils définissent toujours le statut de la fonctionnalité à Declined et portent log_type: "error". Les autres sont associés à une action configurable (DECLINE, REVIEW ou la valeur par défaut NO_ACTION) définie par nœud de workflow ou par appel d’API, de sorte qu’un même code de risque peut entraîner le refus d’un workflow tout en signalant simplement un autre. L’action configurée détermine également la gravité : DECLINE → error, REVIEW → warning, NO_ACTION → information.

Conditions de refus automatique

Les avertissements suivants entraînent toujours le refus de l’étape de vérification de l’e-mail, quelle que soit la configuration :

EMAIL_CODE_ATTEMPTS_EXCEEDED — l’utilisateur a épuisé le quota d’OTP : 2 saisies de code incorrectes (email_max_check_attempts) ou 2 envois d’OTP — l’envoi initial plus un nouvel envoi (email_max_retries) — par défaut.
EMAIL_IN_BLOCKLIST — l’adresse figure sur une liste de blocage gérée via l’API Lists, ou correspond à une vérification d’e-mail précédemment approuvée qui a été ajoutée à la liste de blocage.
UNDELIVERABLE_EMAIL_DETECTED — l’adresse ne peut pas recevoir d’e-mails : syntaxe non valide, domaine inexistant, enregistrements DNS (MX) manquants, ou l’e-mail d’OTP n’a pas pu être distribué. L’étape est immédiatement finalisée avec le statut Declined — aucune vérification de code n’est exécutée. Exception : lorsque l’utilisateur a saisi l’adresse lui-même (elle n’a pas été pré-remplie lors de la création de la session), un envoi non distribuable renvoie une erreur affichée directement dans l’interface afin qu’il puisse réessayer avec une adresse différente au lieu que l’étape soit refusée.

Risques configurables

Chacun des risques suivants correspond à un paramètre (par nœud de workflow, ou par appel sur l’endpoint de vérification autonome) que vous pouvez configurer sur DECLINE, REVIEW ou NO_ACTION :

Paramètre	Code de risque	Comportement par défaut
`breached_email_action`	`BREACHED_EMAIL_DETECTED`	`NO_ACTION` — affiche les détails de la fuite de données au niveau `information` sans modifier le statut.
`disposable_email_action`	`DISPOSABLE_EMAIL_DETECTED`	`NO_ACTION` — signale le fournisseur jetable au niveau `information` sans modifier le statut.
`duplicated_email_action`	`DUPLICATED_EMAIL`	`NO_ACTION` — consigne le doublon au niveau `information`. Ignoré lorsque l’adresse est sur liste autorisée.

La détection des doublons ne prend en compte que les vérifications d’e-mail précédemment approuvées au sein de la même application, regroupées par vendor_data — les vérifications partageant le même vendor_data sont traitées comme un seul utilisateur final et exclues. Laissez vendor_data vide et chaque session sera traitée comme un utilisateur distinct. Si l’adresse figure sur votre liste autorisée d’e-mails, l’action pour doublon est ignorée et EMAIL_IN_ALLOWLIST est émis à la place.

Limites des tentatives de vérification

La fonctionnalité Vérification de l’e-mail applique un plafond strict sur les tentatives d’OTP pour empêcher les abus :

Tentatives de saisie du code — email_max_check_attempts, valeur par défaut 2 : le second code erroné (ou expiré) finalise l’étape.
Tentatives d’envoi — email_max_retries, valeur par défaut 2 envois au total (l’envoi initial plus un renvoi) : une demande de renvoi supplémentaire finalise l’étape.

Le dépassement de l’une ou l’autre de ces limites déclenche EMAIL_CODE_ATTEMPTS_EXCEEDED et entraîne un refus automatique. Vous pouvez ajuster ces deux limites par nœud de workflow.

Avertissements émis

Tag	Sévérité	Description
`EMAIL_CODE_ATTEMPTS_EXCEEDED`	`error`	L’utilisateur a dépassé le plafond de saisie de code ou d’envoi. Entraîne un refus automatique.
`EMAIL_IN_BLOCKLIST`	`error`	L’adresse figure dans une liste de blocage créée via l’API Lists, ou correspond à une vérification approuvée sur liste de blocage. Entraîne un refus automatique. `additional_data` contient `blocklisted_session_id`, `blocklisted_session_number` et `api_service` (tous à `null` pour une correspondance directe avec la liste).
`EMAIL_IN_ALLOWLIST`	`information`	L’adresse correspond à une liste d’autorisation créée via l’API Lists ; l’action liée aux e-mails dupliqués a donc été ignorée.
`BREACHED_EMAIL_DETECTED`	Selon `breached_email_action` (`information` par défaut)	L’adresse a été trouvée dans une ou plusieurs violations de données connues. Le tableau `breaches[]` du rapport indique le service compromis, la date et les catégories de données.
`DISPOSABLE_EMAIL_DETECTED`	Selon `disposable_email_action` (`information` par défaut)	Le domaine appartient à un fournisseur d’adresses jetables / éphémères connu, souvent utilisé pour échapper à la traçabilité.
`UNDELIVERABLE_EMAIL_DETECTED`	`error`	L’adresse ne peut pas recevoir d’e-mails (syntaxe invalide, domaine inexistant, enregistrements MX manquants ou échec de livraison). Entraîne un refus automatique.
`DUPLICATED_EMAIL`	Selon `duplicated_email_action` (`information` par défaut)	L’adresse correspond à une vérification d’e-mail préalablement approuvée appartenant à un autre utilisateur final (groupé par `vendor_data`). `additional_data` contient `duplicated_session_id`, `duplicated_session_number` et `api_service`.

Au maximum l’un de EMAIL_IN_BLOCKLIST, DUPLICATED_EMAIL et EMAIL_IN_ALLOWLIST est déclenché par tentative — la liste de blocage prévaut sur les doublons, qui prévalent à leur tour sur la liste d’autorisation.

Correspondances inter-sessions

Lorsqu’une adresse est détectée sur des vérifications d’e-mail préalablement approuvées ou sur votre liste de blocage, ces correspondances apparaissent également sous email_verifications[].matches[] (limité à 5 entrées). Chaque correspondance contient session_id, session_number, vendor_data, verification_date, email, status, is_blocklisted, api_service, ainsi qu’une source valant session (une autre vérification approuvée) ou list_entry (une entrée de liste de blocage). Si l’adresse actuelle figure sur votre liste d’autorisation d’e-mails, Didit conserve les éléments de preuve de correspondance mais émet EMAIL_IN_ALLOWLIST au lieu d’appliquer l’action liée aux e-mails dupliqués. Consultez le rapport de Vérification de l’e-mail pour le schéma complet des correspondances.

Exemple

{
  "warnings": [
    {
      "feature": "EMAIL",
      "risk": "EMAIL_IN_BLOCKLIST",
      "additional_data": {
        "blocklisted_session_id": null,
        "blocklisted_session_number": null,
        "api_service": null
      },
      "log_type": "error",
      "short_description": "Email in blocklist",
      "long_description": "The system detected that the email is in the blocklist, which is not allowed.",
      "node_id": "feature_email_1"
    },
    {
      "feature": "EMAIL",
      "risk": "DISPOSABLE_EMAIL_DETECTED",
      "additional_data": null,
      "log_type": "information",
      "short_description": "Disposable email detected",
      "long_description": "The system detected that the email is disposable, which is not allowed.",
      "node_id": "feature_email_1"
    }
  ]
}

Types d’avertissements

Chaque risque se voit attribuer un niveau de sévérité selon la configuration de votre application. Les sévérités se répartissent en trois catégories :

Voir aussi

Aperçu de la Vérification de l’e-mail — fonctionnement de la fonctionnalité et tarifs.
Rapport de Vérification de l’e-mail — structure complète de la réponse, y compris lifecycle[] et matches[].
Modèles de données — vérification de l’e-mail — schéma canonique champ par champ.
API Management — Lists — gérez la liste de blocage d’e-mails utilisée par EMAIL_IN_BLOCKLIST.

Authentification

Vérification

Surveillance

Plateforme

Vérification e-mail : avertissements et codes de risque

Présentation

Conditions de refus automatique

Risques configurables

Limites des tentatives de vérification

Avertissements émis

Correspondances inter-sessions

Exemple

Types d’avertissements

Voir aussi

​Présentation

​Conditions de refus automatique

​Risques configurables

​Limites des tentatives de vérification

​Avertissements émis

​Correspondances inter-sessions

​Exemple

​Types d’avertissements

​Voir aussi

Présentation

Conditions de refus automatique

Risques configurables

Limites des tentatives de vérification

Avertissements émis

Correspondances inter-sessions

Exemple

Types d’avertissements

Voir aussi