> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Parcours de vérification des utilisateurs : KYC et UX

> L'UX de vérification Didit : capture d'ID, détection du vivant et retours en direct pour optimiser les taux de conversion.



Prompt sur le cycle de vie d'une session
        Copier le prompt dans le presse-papiers



      
      

\<pre>

\````# Goal — drive a user through a full verification session

The session is the unit you build against. One `POST /v3/session/` returns a hosted URL; your user opens it; Didit runs the workflow; you receive a webhook with the decision.

For the complete recipe (SDK pick per platform, HMAC signature pipeline, decision parsing, every status), copy the canonical prompt at:

https://docs.didit.me/integration/integration-prompt

\## Session lifecycle at a glance

\| Phase | Trigger | What happens |
\|---|---|---|
\| Create | `POST https://verification.didit.me/v3/session/` | Returns `session_id`, `url`, `session_token`. Status = `Not Started`. |
\| User opens `url` | SDK / iframe / redirect | Status flips to `In Progress`. The hosted flow handles country, ID capture, liveness, retries. |
\| Processing | Didit backend | OCR, liveness, face match, AML, etc. run; per-feature plural arrays populate on the decision. |
\| Decision | `status.updated` webhook | One of `Approved`, `Declined`, `In Review`, `Awaiting User` (KYB resub), `Resubmitted`, `Abandoned`, `Expired`, `Kyc Expired`. |

\## Create a session

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "$WORKFLOW_ID",
"vendor_data": "user-42",
"callback": "https://myapp.com/kyc/return"
}'
\```

Always pass `vendor_data` — it is the linking key that binds the session to the persistent [User entity](/entities/users/overview). Without it the session is orphaned.

\## Receive the decision

Webhook (recommended) — register a destination with `webhook_version: "v3"` subscribed to `status.updated` and `data.updated`. Verify the `X-Signature-V2` header (HMAC-SHA256 of canonical JSON).

Polling fallback —
\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

The V3 decision returns plural arrays for every feature: `id_verifications[]`, `liveness_checks[]`, `face_matches[]`, `aml_screenings[]`, `nfc_verifications[]`, `proof_of_address_checks[]`, etc. Never assume V2 singular fields.

\## Failure modes

\- Missing API key → `403 {"detail": "You do not have permission to perform this action."}`. Wrong, revoked or expired key → `401`.
\- Invalid `workflow_id` → `400`.
\- User abandons the flow → status becomes `Abandoned`.
\- Workflow asks for resubmit → status `Resubmitted`, payload includes `resubmit_info`; re-deliver the same `url`.

\## Sources of truth

\- /sessions-api/create-session — request body schema
\- /sessions-api/retrieve-session — V3 decision schema
\- /integration/verification-statuses — literal status strings
\- /integration/webhooks — signature verification, retries
\- /reference/data-models — per-feature decision shape
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

Coller dans

Ce guide explique l'expérience d'un utilisateur final type lors d'une session de **vérification de document d'identité + test de détection du vivant**, et met en avant les optimisations UX qui favorisent des taux de complétion élevés.Cette leçon de la Didit Academy suit le flux hébergé exactement comme un utilisateur le voit : le premier écran, la capture du document, le selfie de détection du vivant, et chaque écran de résultat, de l'approbation au refus.[Ce que voient réellement vos utilisateurs — Didit Academy](https://www.youtube.com/embed/LzGe-dMWjUw?rel=0\&playsinline=1)## Vue d'ensemble du flux![Parcours utilisateur de vérification d'identité Didit, de l'écran de démarrage à la capture de la pièce d'identité et du selfie jusqu'au résultat](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/user-verification-flow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=cc77846e25a476c7e91281295f079e80)**1. Écran de démarrage**L'utilisateur arrive sur un écran épuré aux couleurs de la marque qui définit les attentes (par ex., « Vous aurez besoin de votre pièce d'identité et de votre visage »). Cela réduit l'abandon en levant toute incertitude.**2. Sélection du pays et du document**L'utilisateur sélectionne son pays et son type de document (passeport, carte d'identité, etc.).> [!NOTE]
>
> Si votre workflow est configuré pour un **seul type de document**, cet écran est **automatiquement ignoré** — ce qui redirige directement l'utilisateur vers la capture.**3. Capture de la pièce d'identité avec nouvelles tentatives intelligentes**L'utilisateur photographie le recto de son document.
**Contrôle qualité sur l'appareil** — Avant la soumission, le SDK vérifie la présence de reflets, de flou et de bords coupés. Si un problème est détecté, l'utilisateur est invité à reprendre la photo.**Validation côté serveur avec nouvelle tentative guidée** — Une fois soumis :- **Réussi** → passage à la détection du vivant
- **Échec** → l'utilisateur voit des instructions spécifiques (par ex., « Document expiré », « MRZ illisible — reprenez la photo sous un meilleur éclairage ») plutôt qu'une erreur génériqueCette boucle de nouvelles tentatives en libre-service augmente considérablement les taux de passage. Consultez la liste complète des résultats de validation dans les [avertissements de vérification d'identité](https://docs.didit.me/fr/core-technology/id-verification/warnings-id-verification.md).**4. Détection du vivant + correspondance faciale**Un contrôle de détection du vivant par selfie garantit la présence physique de l'utilisateur et prévient les attaques par rejeu/deepfake. Si l'utilisateur ne répond pas à temps, le processus **effectue automatiquement une nouvelle tentative, une seule fois** au lieu d'échouer de manière bloquante.**5. Résultat final**Une fois tous les contrôles terminés, l'utilisateur voit l'un des trois résultats suivants :| Résultat | Description |
| - | - |
| **Approuvé** | Tous les contrôles ont réussi. Les données sont extraites et disponibles via API/webhook. |
| **Refusé** | Le système a déterminé que la vérification ne peut pas être approuvée. |
| **En cours d'examen** | Les contrôles automatisés n'ont pas été concluants — un examen manuel est nécessaire. |Votre workflow détermine les étapes suivantes que l'utilisateur voit, dans l'ordre que vous avez défini.
Par exemple :- [Vérification du téléphone](https://docs.didit.me/fr/core-technology/phone-verification/overview.md) et [vérification de l'e-mail](https://docs.didit.me/fr/core-technology/email-verification/overview.md)
- [Questionnaires](https://docs.didit.me/fr/core-technology/questionnaires/overview.md)
- [Justificatif de domicile](https://docs.didit.me/fr/core-technology/proof-of-address/overview.md)
- [Consentement biométrique](https://docs.didit.me/fr/getting-started/biometric-consent.md)
- [Signature de documents](https://docs.didit.me/fr/core-technology/electronic-signature/overview.md)En combinant une UX intelligente, une validation progressive, des retours exploitables et des nouvelles tentatives fluides, le parcours de vérification Didit permet aux utilisateurs légitimes d'avancer tout en bloquant les fraudeurs — sans intervention manuelle.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.