Passer au contenu principal
Chaque session de vérification passe par une série de statuts. Les comprendre vous aide à suivre la progression de l’utilisateur, à automatiser les décisions de conformité et à optimiser le taux de conversion. Cette énumération est la source unique de vérité pour les chaînes renvoyées par GET /v3/session/<id>/decision/ et par chaque webhook Didit.

Toutes les valeurs de statut

Chaque statut est une chaîne exacte renvoyée par l’API et les webhooks Didit. Utilisez toujours une comparaison stricte des chaînes (par exemple === "In Review") dans votre code : ces valeurs sont sensibles à la casse et contiennent des espaces. La valeur Kyc Expired utilise également un seul K majuscule (et non KYC).

Statuts des sessions

Valeur API : "Not Started"La session a été créée via l’API, mais l’utilisateur n’a pas encore ouvert le lien de vérification.
  • Action à mener : Attendez que l’utilisateur commence, ou envoyez un rappel si le délai est trop long.
  • Transitions vers : "In Progress", "Expired"
Valeur API : "In Progress"L’utilisateur a ouvert le lien et effectue activement les étapes de vérification (capture du document, détection du vivant, etc.).
  • Action à mener : Aucune action requise, l’utilisateur est en train de suivre le parcours.
  • Transitions vers : "Approved", "Declined", "In Review", "Abandoned"
Valeur API : "Approved"Toutes les vérifications ont abouti avec succès. L’identité de l’utilisateur a été vérifiée.
  • Action à mener : Accordez à l’utilisateur l’accès, mettez à jour son profil et conservez les données de la décision.
  • Le webhook inclut : L’objet decision complet avec les résultats de toutes les fonctionnalités.
  • Transitions vers : "Kyc Expired" (lorsque la date d’expiration du document vérifié est dépassée ; comportement par défaut, sauf si Expiration mode est réglé sur Allow expired pour ce pays et ce type de document). Un réviseur ou l’endpoint de mise à jour du statut peut également la faire passer à "Declined" ou "Resubmitted".
Valeur API : "Declined"Une ou plusieurs vérifications ont échoué. L’utilisateur n’a pas réussi la vérification.
  • Action à mener : Informez l’utilisateur. Vous pouvez éventuellement demander une nouvelle soumission si le problème peut être corrigé.
  • Le webhook inclut : L’objet decision complet avec les avertissements expliquant l’échec.
  • Transitions vers : "Resubmitted" (si un réviseur la demande). Un réviseur ou l’endpoint de mise à jour du statut peut aussi la faire passer à "Approved".
Valeur API : "In Review"Les contrôles automatiques ont signalé des avertissements nécessitant un examen humain. Un réviseur chargé de la conformité doit prendre la décision finale.
  • Action à mener : Un réviseur doit ouvrir la session dans la Console, puis approuver, refuser ou demander une nouvelle soumission.
  • Le webhook inclut : L’objet decision complet avec les avertissements.
  • Transitions vers : "Approved", "Declined", "Resubmitted"
Valeur API : "Awaiting User"Utilisé dans les sessions KYB (vérification d’entreprise) lorsque l’étape Personnes clés a soumis la liste des parties et généré des sessions KYC ou KYB enfants. La session parente attend que toutes les parties requises aient terminé leur vérification individuelle.
  • Action à mener : Surveillez les statuts des sessions KYC enfants. Une fois que toutes les parties requises ont terminé leur vérification (avec une session approuvée, refusée ou expirée), la session parente recalcule automatiquement son statut final.
  • Le webhook inclut : La liste actuelle des parties et les statuts de leurs sessions enfants.
  • Transitions vers : "Approved", "Declined", "In Review" (une fois que toutes les sessions enfants sont terminales)
  • Transitions depuis : "In Progress" (après soumission de l’étape Personnes clés)
  • Remarque : Si une session KYC enfant est soumise à nouveau, la session parente revient à "Awaiting User" jusqu’à ce que la session soumise à nouveau soit terminée. Un KYB Registry Check en statut "Declined" prime sur "Awaiting User".
Valeur API : "Resubmitted"Un réviseur a demandé que l’utilisateur refasse certaines étapes de vérification (par exemple, reprendre une photo de document floue).
  • Action à mener : Attendez que l’utilisateur termine les étapes à refaire. Le système réévaluera automatiquement la session.
  • Le webhook inclut : L’objet resubmit_info avec la liste des fonctionnalités à refaire et les motifs.
  • Transitions vers : "Approved", "Declined", "In Review", ou "Abandoned" lorsque la fenêtre de la session se termine avant que la personne ait refait les étapes.
Valeur API : "Expired"La session a expiré avant que l’utilisateur ouvre le lien de vérification.
  • Action à mener : Créez une nouvelle session et envoyez à l’utilisateur un nouveau lien.
  • Statut terminal : aucune transition ultérieure.
Valeur API : "Abandoned"L’utilisateur a commencé sans terminer la vérification dans le délai imparti.
  • Action à mener : Envoyez un rappel ou créez une nouvelle session.
  • Aucune transition automatique. Un réviseur, ou PATCH /v3/session/{sessionId}/update-status/, peut encore la faire passer à "Approved", "Declined" ou "Resubmitted".
Valeur API : "Kyc Expired"Le document vérifié pendant la session a dépassé sa propre date d’expiration. Le déclencheur est cette date, et non une période mesurée à partir de l’approbation ; aucun avertissement n’est envoyé au préalable.
  • Action à mener : Demandez à l’utilisateur de refaire la vérification avec une nouvelle session. status.updated transmet la transition, et le résultat de la vérification d’identité comporte un avertissement DOCUMENT_EXPIRED.
  • Contrôlé par : le paramètre Expiration mode pour le pays et le type de document concernés dans ID verification → Additional settings by country & document type : Reject expired (par défaut) surveille le document, tandis que Allow expired signifie que la session ne passe jamais à ce statut.
  • Aucune transition automatique. Un réviseur, ou PATCH /v3/session/{sessionId}/update-status/, peut encore la faire passer à "Approved", "Declined" ou "Resubmitted".

Transitions de statut

Diagramme du cycle de vie


Terminaux et non terminaux


Gérer les statuts dans votre code

Utilisez les webhooks ou l’API de récupération de session pour réagir aux changements de statut.
Les statuts sont des chaînes exactes, sensibles à la casse et contenant des espaces. Par exemple, "In Review" (et non "in_review" ou "IN_REVIEW"). Utilisez toujours l’égalité stricte (===) lors de la comparaison.

Resoumission

Le statut Resubmitted permet à votre équipe de conformité de donner une seconde chance aux utilisateurs sans créer de nouvelle session.
1

Le réviseur lance la resoumission

Depuis la Console, ouvrez une session In Review ou Declined et cliquez sur Demander une resoumission. Sélectionnez les étapes à refaire.
2

Les données précédentes sont archivées

Le système réinitialise les fonctionnalités sélectionnées et marque les données précédentes comme previous_attempt, en préservant la piste d’audit complète.
3

L'utilisateur est notifié

Si un e-mail est disponible, l’utilisateur reçoit un e-mail localisé avec un lien direct pour reprendre.
4

L'utilisateur refait des étapes précises

L’utilisateur ne répète que les étapes signalées, et non la vérification complète.
5

Le système réévalue

Une fois terminée, la session passe automatiquement à "Approved", "Declined" ou "In Review".

Charge utile du webhook de resoumission

reasons associe chaque node_id resoumis au code d’avertissement du journal le plus pertinent pour cette étape (les mêmes codes que ceux rapportés par la décision), afin que vous puissiez le mettre en correspondance avec vos propres textes. C’est aussi le code que l’écran de resoumission du flux hébergé et l’e-mail de resoumission localisent pour l’utilisateur, sauf pour les avertissements qui révéleraient un signal de filtrage ou de fraude (doublons, AML, liste de blocage, vérifications inter-organisations, intégrité de la localisation géographique et similaires) : dans ces cas, la personne voit un motif générique, et resubmit_info.reasons dans votre webhook contient toujours le code réel. Une étape sans avertissement enregistré n’a pas d’entrée.

Fonctionnalités pouvant être resoumises

Toute fonctionnalité au statut non approuvé : Declined, In Review, Not Finished, Not Started ou Expired.
Vous pouvez demander une resoumission plusieurs fois pour la même session. Chaque cycle archive les données de la tentative précédente, ce qui vous donne une visibilité complète sur l’historique de vérification de l’utilisateur.

Meilleures pratiques

Surveiller les sessions en cours d'examen

Configurez des alertes (e-mail ou Slack) dans votre Didit Console pour être averti lorsque des sessions nécessitent un examen manuel.

Privilégier la nouvelle soumission

Si le problème est corrigeable (photo floue, mauvais côté du document), demandez une nouvelle soumission au lieu de refuser. Cela améliore le taux de conversion.

Suivre les abandons

Des taux élevés de sessions abandonnées ou expirées peuvent indiquer des frictions dans l’expérience utilisateur. Envisagez d’ajuster le TTL de session ou d’améliorer les instructions données à l’utilisateur.

Gestionnaires idempotents

Les webhooks peuvent être réessayés. Utilisez session_id comme clé unique pour vous assurer de ne traiter chaque changement de statut qu’une seule fois.
Vérifiez toujours les signatures des webhooks avant de traiter les payloads. Didit propose trois méthodes : X-Signature, X-Signature-V2 (recommandée) et X-Signature-Simple, obsolète, qui n’authentifie que l’enveloppe et jamais le corps decision. Consultez Webhooks pour plus de détails.
Dernière modification le 7 novembre 2026