Prépare-toi à accepter le portefeuille européen d'identité numérique.
Chaque État membre de l'UE doit proposer un portefeuille d'identité numérique de l'UE (EUDI) d'ici le 24 décembre 2026, et les entreprises réglementées doivent l'accepter d'ici le 24 décembre 2027. Didit gère aujourd'hui cinq eID nationales, et l'acceptation du portefeuille EUDI sera bientôt intégrée au même flux de travail.
Approuvé par plus de 3000 organisations dans le monde entier.
Portefeuille EUDIAttestation d'identité et d'âge
La boutique en ligne demandeÂge supérieur à 18 ans
Nom de famille
Prénom
Date de naissance
Lieu de naissance
Nationalité
Âge supérieur à 18 ans
Partager 1 attribut
Partie utilisatriceBoutique en ligne
age_over_18true
Signature de l'émetteur
Liaison de l'appareil
5 attributs non partagés
Qu'est-ce que le portefeuille EUDI
Un portefeuille par personne. Seules les données que tu demandes.
Le portefeuille EUDI est une application gratuite que chaque État membre de l'UE doit proposer en vertu du règlement (UE) 2024/1183, connu sous le nom d'eIDAS 2. Il contient des données d'identification personnelle (PID), c'est-à-dire le nom, la date et le lieu de naissance, ainsi que la nationalité, plus des attestations électroniques d'attributs telles qu'un permis de conduire ou un diplôme. Son utilisation est volontaire.
Lorsqu'une entreprise demande des données, la personne voit qui demande et ne partage que les attributs requis. C'est ce qu'on appelle la divulgation sélective : un site peut savoir qu'une personne a plus de 18 ans sans voir sa date de naissance. Le portefeuille fonctionne au niveau de garantie élevé, le plus élevé des trois niveaux eIDAS, et l'entreprise vérifie la signature de l'émetteur avant de se fier aux données.
Dernière révision : 5 octobre 2026. Ceci n'est pas un avis juridique.
Dates clés
Portefeuilles d'ici fin 2026. Acceptation d'ici le 24 décembre 2027.
Voici les dates du règlement (UE) 2024/1183 et de ses actes d'exécution qu'une entreprise devrait prendre en compte.
30 avril 2024
Publication d'eIDAS 2
Le règlement (UE) 2024/1183, qui modifie le règlement eIDAS (UE) n° 910/2014, paraît au Journal officiel de l'UE. Il entre en vigueur le vingtième jour suivant sa publication.
24 décembre 2024
Premières règles du portefeuille en vigueur
Les cinq premiers règlements d'exécution pour le portefeuille entrent en vigueur : données d'identification personnelle, fonctions principales, notifications, certification, et protocoles et interfaces. Ils déclenchent les délais de 24 et 36 mois ci-dessous.
15 juillet 2026
Règles du portefeuille mises à jour
La Commission adopte le règlement d'exécution (UE) 2026/1731. Il fixe les deux formats de justificatifs, SD-JWT VC et ISO/IEC mdoc, et prévoit le portrait obligatoire pour 2028.
23 juillet 2026
ARF v3.0.0
L'Architecture and Reference Framework (ARF), le plan technique sur lequel les portefeuilles et les parties utilisatrices s'appuient, atteint la version 3.0.0.
24 décembre 2026
Portefeuilles dans chaque État membre
Chaque État membre doit fournir au moins un portefeuille EUDI. Les règles d'enregistrement des parties utilisatrices, le règlement d'exécution (UE) 2025/848, s'appliquent à partir du même jour.
24 décembre 2027
Les entreprises privées doivent l'accepter
Les entreprises privées qui doivent utiliser une authentification forte de l'utilisateur en vertu de la loi ou d'un contrat, autres que les micro et petites entreprises, doivent accepter le portefeuille lorsqu'un utilisateur demande à l'utiliser (article 5f, paragraphe 2). Ce délai est de 36 mois après l'entrée en vigueur des premiers actes d'exécution, le 24 décembre 2024, soit le 24 décembre 2027 au plus tard.
11 août 2028
Vérifications du portrait et de l'enregistrement
Le portrait fait partie des données d'identification personnelle obligatoires, et les portefeuilles doivent authentifier et valider le certificat d'enregistrement de chaque partie utilisatrice.
Qui doit l'accepter
Qui doit accepter le portefeuille, et quand.
L'article 5f du règlement eIDAS, tel que modifié par le règlement (UE) 2024/1183, fixe les obligations d'acceptation. Dans tous les cas, l'utilisateur choisit d'utiliser le portefeuille, et tu conserves tes autres moyens d'identifier les personnes.
Qui
Ce que ça signifie, en clair
Article · date
Qui
Organismes du secteur public
Ce que ça signifie, en clair
Lorsqu'un État membre exige une identification électronique pour accéder à un service public en ligne, ce service doit également accepter le portefeuille EUDI.
Article · date
Art. 5f(1)
Qui
Services privés qui doivent utiliser une authentification forte
Ce que ça signifie, en clair
Si une loi ou un contrat t'oblige à utiliser une authentification forte pour l'identification en ligne, tu dois aussi accepter le portefeuille EUDI. C'est cette exigence qui déclenche l'obligation, pas ton secteur d'activité.
Article · date
Art. 5f(2) · 24 déc. 2027
Qui
Domaines cités par l'article
Ce que ça signifie, en clair
Transport, énergie, banque, services financiers, sécurité sociale, santé, eau potable, services postaux, infrastructures numériques, éducation et télécommunications. L'article dit « y compris », la liste est donc indicative et non exhaustive.
Article · date
Art. 5f(2)
Qui
Micro et petites entreprises
Ce que ça signifie, en clair
Exemptées de l'obligation applicable au secteur privé, telle que définie dans la Recommandation 2003/361/CE de la Commission. Elles peuvent néanmoins accepter le portefeuille si elles le souhaitent.
Article · date
Art. 5f(2)
Qui
Uniquement à la demande de l'utilisateur
Ce que ça signifie, en clair
L'acceptation est due lorsque l'utilisateur demande à utiliser le portefeuille. Son utilisation est volontaire pour les personnes, et les services doivent rester ouverts à d'autres moyens d'identification et d'authentification.
Article · date
Arts. 5f(2), 5a(15)
Qui
Très grandes plateformes en ligne
Ce que ça signifie, en clair
Les plateformes désignées en vertu du règlement sur les services numériques (DSA) qui exigent une authentification de l'utilisateur doivent accepter le portefeuille à la demande de l'utilisateur, pour les données minimales dont le service a besoin. Le texte ne fixe pas de date distincte pour cette obligation.
Article · date
Art. 5f(3)
Les parties utilisatrices doivent également s'enregistrer dans l'État membre où elles sont établies, et ne peuvent demander que les données qu'elles ont enregistrées (article 5b). Dernière révision : 5 octobre 2026. Ceci n'est pas un avis juridique.
Comment une entreprise l'accepte
Comment une partie utilisatrice accepte le portefeuille EUDI, en cinq étapes.
Étape 01 / 05
01
S'enregistrer comme partie utilisatrice
Enregistre-toi dans l'État membre où tu es établi, avec tes coordonnées et les données que tu as l'intention de demander. Tu recevras un certificat d'accès, qui t'authentifie auprès du portefeuille, et, si ton État membre en délivre un, un certificat d'enregistrement listant les attributs que tu as enregistrés.
Demande uniquement ce dont tu as besoin
Demande des attributs spécifiques, par exemple l'âge supérieur à 18 ans, avec OpenID for Verifiable Presentations (OpenID4VP) et une requête Digital Credentials Query Language (DCQL), ou avec ISO/IEC 18013-7. Tu ne peux pas demander de données au-delà de ton enregistrement.
L'utilisateur donne son consentement dans le portefeuille
Sur le même téléphone, le navigateur transfère la main à l'application du portefeuille. Sur un ordinateur, l'utilisateur scanne un code QR. Le portefeuille indique qui demande, vérifie que tu ne demandes pas plus que ce que tu as enregistré, et l'utilisateur approuve ou refuse.
Vérifier la présentation
Vérifie la signature de l'émetteur par rapport aux listes de confiance, vérifie que le justificatif n'a pas été révoqué, et vérifie la liaison de l'appareil, ce qui montre que le justificatif n'a pas été copié ou rejoué.
Recevoir les attributs et décider
Tu ne reçois que les attributs partagés par l'utilisateur, signés par l'émetteur. La décision d'intégration ou d'accès, et l'enregistrement que tu conserves, restent de ton ressort.
Didit exécutera ces étapes pour toi lorsque l'acceptation du portefeuille EUDI sera lancée (bientôt disponible).
Ce que tu reçois vs ce que le KYC exige
Le portefeuille prouve l'identité. La diligence raisonnable en demande plus.
En vertu du Règlement anti-blanchiment (AMLR), Règlement (UE) 2024/1624, l'identification électronique avec un niveau de garantie substantiel ou élevé est l'une des deux manières de vérifier l'identité (Article 22(6)). Elle ne couvre pas tout ce que les contrôles KYC (Know Your Customer) demandent. Voici ce que contiennent les données d'identification de la personne (PID) et comment Didit couvre chaque élément aujourd'hui.
Exigences de diligence raisonnable
Dans le PID du portefeuille EUDI
Comment Didit le couvre aujourd'hui
Exigences de diligence raisonnable
Nom et prénoms complets
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Nom de famille et prénom, tous deux obligatoires.
Comment Didit le couvre aujourd'hui
Les eID nationales en direct renvoient le nom complet. La voie documentaire le lit à partir de plus de 14 000 types de documents.
Exigences de diligence raisonnable
Lieu et date de naissance complète
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Date et lieu de naissance, tous deux obligatoires.
Comment Didit le couvre aujourd'hui
Les eID nationales en direct renvoient la date de naissance. La voie documentaire lit le lieu de naissance lorsque le document l'indique.
Exigences de diligence raisonnable
Nationalités
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Nationalité, obligatoire, un ou plusieurs pays.
Comment Didit le couvre aujourd'hui
La voie documentaire lit la nationalité à partir du document d'identité ou de sa puce.
Exigences de diligence raisonnable
Numéro d'identification national, le cas échéant
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Numéro administratif personnel, facultatif. Chaque État membre décide de le délivrer ou non.
Comment Didit le couvre aujourd'hui
Les eID nationales en direct renvoient un identifiant propre au système : le personnummer suédois, le code d'identité personnel finlandais ou le code personnel balte. MitID renvoie un identifiant pseudonymisé, pas le numéro CPR.
Exigences de diligence raisonnable
Lieu de résidence habituel
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Les champs d'adresse sont facultatifs et souvent manquants. Les projets de normes finales de l'AMLA stipulent que les attributs manquants doivent être obtenus par d'autres moyens.
Comment Didit le couvre aujourd'hui
Aucune eID nationale en direct ne renvoie d'adresse. La preuve d'adresse vérifie une facture de services publics, un relevé bancaire ou une lettre gouvernementale.
Exigences de diligence raisonnable
Numéro d'identification fiscale, le cas échéant
AMLR Art. 22(1)(a)
Dans le PID du portefeuille EUDI
Ne fait pas partie du PID.
Comment Didit le couvre aujourd'hui
Collecte-le avec une étape de questionnaire dans le même flux de travail.
Exigences de diligence raisonnable
La personne correspond à l'identité
ARF · liaison utilisateur
Dans le PID du portefeuille EUDI
Le portrait reste facultatif jusqu'à ce qu'il devienne obligatoire le 11 août 2028.
Comment Didit le couvre aujourd'hui
Vérification de la vivacité passive et correspondance faciale 1:1 avec la photo du document ou le portrait de la puce, dans le cadre de la vérification KYC complète à 0,33 $.
Exigences de diligence raisonnable
Bénéficiaires effectifs d'une entreprise
AMLR Art. 20(1)(b)
Dans le PID du portefeuille EUDI
Pas dans le PID. Un portefeuille identifie une personne, pas le propriétaire d'une entreprise.
Comment Didit le couvre aujourd'hui
La vérification d'entreprise extrait les données du registre et les propriétaires lorsque le registre les contient, avec une vérification d'identité pour chaque propriétaire.
Exigences de diligence raisonnable
Sanctions et personnes politiquement exposées (PPE)
AMLR Art. 20(1)(d), (g)
Dans le PID du portefeuille EUDI
Pas dans le PID.
Comment Didit le couvre aujourd'hui
Filtrage AML contre plus de 1 300 listes de sanctions, de PPE et de surveillance, à 0,20 $ par vérification.
Exigences de diligence raisonnable
Objet de la relation et suivi continu
AMLR Arts. 25, 26
Dans le PID du portefeuille EUDI
Pas dans le PID.
Comment Didit le couvre aujourd'hui
Les questionnaires enregistrent l'objet de la relation. La surveillance continue re-filtre les clients chaque jour pour 0,07 $ par personne par an.
La vigilance à l'égard de la clientèle reste ton obligation. Didit fournit des vérifications et des preuves, mais ne te rend pas conforme. L'AMLR s'applique à partir du 10 juillet 2027, et les normes techniques de l'AMLA sont un projet final daté du 30 septembre 2026, et non une loi.
État d'avancement par pays
Où en sont les portefeuilles nationaux, avec dates et sources.
Voici ce que chaque pays a publié, ou ce qu'une source nommée rapporte, avec la date et un lien pour chaque ligne.
Statut au 5 octobre 2026
Pays
Portefeuille ou app
Statut
Date
Ce que l'on sait
Pays
Italie
Portefeuille ou app
IT-Wallet (app IO)
Statut
App en ligne
Date
17 février 2026
Ce que l'on sait
En ligne dans l'application IO, avec 10,1 millions d'activations et 17,3 millions de documents chargés au 17 février 2026. Gratuit et facultatif pour les adultes, qui se connectent avec CIE ou SPID.
AltID est disponible avec une carte d'identité numérique et une preuve d'âge, et 281 390 personnes l'avaient créé au 4 août 2026. L'Agence pour le gouvernement numérique met en œuvre le portefeuille par étapes.
Selon Euronews, la France fait partie des pays les plus avancés, et l'application France Identité devrait être mise en conformité avec les règles EUDI.
Bac à sable public depuis décembre 2025. L'application est prévue pour début 2027, en commençant par la fonction d'identification. La loi d'application a été examinée en première lecture au Bundestag le 23 septembre 2026.
Non listés : Autriche, Belgique, Estonie, Hongrie, Lettonie, Lituanie, Luxembourg, Malte, Portugal, Slovénie. Nous n'avons trouvé aucun statut public pour ces pays à cette date. Nous mettons à jour ce tableau au fur et à mesure du lancement des applications nationales.
Comment Didit vous y aide · Cinq points
Accepte les eID nationaux dès maintenant. Ajoute le portefeuille EUDI ensuite.
Le portefeuille EUDI ajoute une voie, il ne remplace pas les autres. Développe ton workflow une seule fois : les eID et documents nationaux aujourd'hui, et l'acceptation du portefeuille EUDI dans la même étape de vérification d'identité dès son lancement.
Accepte les eID nationales que tes clients utilisent déjà.
Cinq eID nationales sont déjà intégrées à Didit dans sept pays : MitID, BankID Sweden, Finnish Trust Network, Smart-ID et Mobile-ID. L'utilisateur se connecte avec son eID, et la session reçoit des attributs signés : nom complet, date de naissance, un identifiant propre au système (par exemple le personnummer suédois ; MitID renvoie un identifiant pseudonymisé) et le niveau de garantie déclaré par le système. Seules les connexions complètes sont facturées.
Niveaux tels que labellisés par Didit. Aucune adresse ou portrait n'est renvoyé.
02 · Portefeuille EUDI, bientôt disponible
Acceptation du portefeuille EUDI, dans le même workflow.
L'acceptation du portefeuille EUDI arrive bientôt. Notre catalogue de portefeuilles le répertorie pour 30 pays de l'EEE, dans la même étape de vérification d'identité que les eID nationaux. Il n'y a pas encore de date ni de prix.
Pas encore de date ni de prix pour l'acceptation du portefeuille EUDI.
03 · Voie documentaire
Une voie documentaire pour tous ceux qui n'ont pas de portefeuille.
Tout le monde n'aura pas ou n'utilisera pas de portefeuille, et la loi maintient d'autres moyens ouverts. La voie documentaire lit la puce des passeports et cartes d'identité par NFC (0,15 $), effectue une détection de vivacité passive et compare le visage à la photo du document, sur plus de 14 000 types de documents dans plus de 220 pays et territoires.
Le portefeuille EUDI peut prouver qu'une personne a plus de 18 ans sans date de naissance. En attendant que les portefeuilles soient courants, l'estimation de l'âge à partir d'un selfie coûte 0,10 $ par vérification et envoie les résultats limites à un système de vérification d'identité de secours. Une connexion eID en direct renvoie également une date de naissance signée sans photo de document.
Filtrage, surveillance et entreprises, au même endroit.
L'identité est une partie de la vigilance à l'égard de la clientèle. Dans le même workflow, filtre les personnes par rapport à plus de 1 300 listes de sanctions, de PPE et de listes de surveillance (0,20 $ par vérification), refiltre-les chaque jour avec une surveillance continue (0,07 $ par personne par an), et vérifie les entreprises et leurs propriétaires.
Une présentation multi-appareils telle que décrite par l'ARF : la personne commence sur un ordinateur et termine sur le téléphone qui contient le portefeuille.
01Scanne pour continuer
Scanne le code QR
Le service affiche un code QR, et la personne le scanne avec l'application de portefeuille.
02La boutique en ligne demande : âge supérieur à 18 ans
Examine la demande
Le portefeuille indique qui demande et quels attributs.
03Partage 1 attribut
Partage
La personne approuve, et seuls les attributs demandés quittent le téléphone.
04Vérifié
Vérifié
Le service vérifie la signature de l'émetteur et continue. Rien d'autre n'a été partagé.
Une illustration du flux standard. L'acceptation du portefeuille EUDI de Didit arrive bientôt.
Intègre dès aujourd'hui
Intègre dès aujourd'hui, et garde-le quand le portefeuille arrivera.
Il n'y a pas encore d'API Didit spécifique à l'EUDI. Crée une session pour un workflow qui accepte les eID nationaux et les documents en direct, puis lis le résultat. L'acceptation du portefeuille EUDI est prévue pour la même étape de vérification d'identité.
Prépare-toi au portefeuille EUDI en une seule invite.
Copie cette invite dans ton agent de codage. Elle construit le workflow que tu peux exécuter aujourd'hui, les eID nationaux en direct avec un fallback documentaire, ainsi que l'appel de session et le webhook signé. Elle n'invente pas de point de terminaison EUDI, car il n'en existe pas encore.
didit-integration-prompt.md
# Didit: get ready for the EUDI Wallet with the ID Verification step you run today
You are adding electronic identification to my_stack so the product is ready
for the EU Digital Identity (EUDI) Wallet. Every URL, header and enum value
below is canonical. Do not paraphrase or "improve" them.
## 0. What exists today, and what does not
- EUDI Wallet acceptance on Didit is coming soon. There is NO EUDI-specific
endpoint, wallet id, field or flag to integrate yet. Do not invent one, do
not send any EUDI identifier in a workflow, and do not build an OpenID4VP
verifier yourself as part of this task.
- What is live: national digital ID wallets inside the ID Verification step,
with document capture (chip reading, liveness, face match) as the fallback.
EUDI Wallet acceptance is planned for the same ID Verification step, so the
workflow, session call and webhook you build now are the ones you keep.
- The live wallets, as listed by the methods catalog:
- MitID: wallet id mitid, country keys DNK (Denmark)
- BankID: wallet id bankid_se, country keys SWE (Sweden)
- Finnish Trust Network: wallet id ftn, country keys FIN (Finland)
- Smart-ID: wallet id smart_id, country keys EST (Estonia), LVA (Latvia), LTU (Lithuania), BEL (Belgium)
- Mobile-ID: wallet id mobile_id, country keys EST (Estonia), LTU (Lithuania)
Check the catalog for your environment before you go live. Never
hard-code dates.
## 1. Provision an account
- Sign up: https://business.didit.me (no credit card required).
- Copy the API key of your application from the console.
## 2. Read the methods catalog
Availability is server-driven per country. Only wallets marked available can
be enabled on a live application.
- Business Console: your application -> Workflows -> the ID Verification
step -> Countries -> "Wallets accepted". Coming-soon wallets are listed
but cannot be switched on. https://docs.didit.me/console/id-verification-methods
- Didit MCP server (https://mcp.didit.me/mcp), tool
didit_workflow_get_id_verification_methods_catalog; pass country as ISO
3166-1 alpha-3 to narrow it. The MCP server signs in with "Log in with
Didit" (OAuth). It does not accept the x-api-key.
https://docs.didit.me/integration/mcp/tools
- Public coverage table (no sign-in, read-only):
https://docs.didit.me/core-technology/id-verification/digital-id-wallets#supported-wallets
If your code holds only an API key, it cannot read the catalog itself: use the
wallet ids listed in this prompt, and treat the answer of the workflow save as
the check. A live application answers 400 for a wallet that is not available
in that country ("<wallet> is not offered in <ISO3>", "unknown wallet").
## 3. Create the workflow (ID Verification = feature OCR)
POST https://verification.didit.me/v3/workflows/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
{
"workflow_label": "eID onboarding",
"features": [
{
"feature": "OCR",
"config": {
"methods": {
"DNK": {
"document": { "enabled": true },
"wallet": {
"enabled": true,
"providers": ["mitid"],
"on_failure": "fallback_to_document"
}
},
"EST": {
"document": { "enabled": true },
"wallet": {
"enabled": true,
"providers": ["smart_id", "mobile_id"],
"on_failure": "fallback_to_document"
}
}
}
}
}
]
}
Response: 201. The workflow id is uuid (workflow_id carries the same value);
the workflow is published straight away. Create it once and keep the id:
every call to this endpoint makes a new workflow.
is_desktop_allowed defaults to false: on a desktop browser the hosted flow
then shows a QR code to continue on a phone. Add "is_desktop_allowed": true
next to workflow_label to let people finish on desktop.
Rules the API enforces:
- OCR is UPPERCASE; ID_VERIFICATION is rejected in this body (the decision
later lists the step as ID_VERIFICATION in its features)
- country keys are ISO 3166-1 alpha-3; method keys are document, id_lookup, wallet
- providers is an accept-list, not a ranking; the end user picks
- on_failure is fallback_to_document or decline
- a wallet the catalog does not mark available rejects the whole save (400)
- every other country keeps document capture, so people without an eID
can still verify
- this body runs document capture only. Chip reading, liveness and face
match are their own features: add { "feature": "NFC" },
{ "feature": "LIVENESS" } and { "feature": "FACE_MATCH" } to features
when your policy needs them
## 4. Create a session
POST https://verification.didit.me/v3/session/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
-d '{ "workflow_id": "<id from step 3>", "vendor_data": "<your user id>" }'
Response: 201 with session_id, session_token, url and status "Not Started".
Redirect the user to url (hosted flow) or open it in the Web, iOS, Android,
React Native or Flutter SDK. The field is named url on this response.
One unfinished session exists per workflow_id and vendor_data pair: calling
create again with the same pair answers 201 again with that same session.
## 5. Webhook
Register a destination in the console (API & Webhooks), or over the API:
POST https://verification.didit.me/v3/webhook/destinations/
-H "x-api-key: <your-api-key>"
-H "Content-Type: application/json"
-d '{
"label": "Verification webhooks",
"url": "https://<your-public-host>/webhooks/didit",
"webhook_version": "v3",
"subscribed_events": ["status.updated", "data.updated"]
}'
label, url and subscribed_events are required. url must be a public HTTPS
address: Didit does not deliver to localhost or private addresses. Response:
201 with uuid and secret_shared_key. Store secret_shared_key as the webhook
secret (DIDIT_WEBHOOK_SECRET); it is unique to this destination. Remove a
destination with DELETE /v3/webhook/destinations/{uuid}/ (204).
What arrives:
- webhook_type is "status.updated" (the session changed status) or
"data.updated" (verification data was corrected after the fact)
- a destination receives the events of every session of the application,
so filter on workflow_id or vendor_data when several flows share it
- creating a session already sends status.updated with status
"Not Started". The decision key is present only when status is Approved,
Declined, In Review or Abandoned.
Verify every delivery:
Header: X-Signature-V2 (not X-Signature, not X-Signature-Simple)
Algorithm: HMAC-SHA256, hex digest, over the canonical JSON of the payload
(Python json.dumps(sort_keys=True, separators=(",", ":"),
ensure_ascii=False) after whole-valued floats become ints).
Never hash the raw request bytes under this header.
Freshness: the signed body field timestamp is the dispatch time (Unix
seconds). Reject when abs(now - timestamp) > 300 seconds, and
reject when the X-Timestamp header does not equal it.
Idempotency: event_id is the same on every retry of one event, so store it
and skip a delivery you already processed. One session can
still send the same status under two event ids, and the
console's Try Webhook test deliveries carry no event_id, so
also make the handler safe to run twice for one
(session_id, status, webhook_type).
Compare: constant-time (crypto.timingSafeEqual)
Reference handler (Express). Keep the verification lines as written.
The handler is a fragment. Put this above it and app.listen(process.env.PORT)
below it. It needs Express and Node 21 or newer (an older Node rejects
every delivery). It expects a JSON body: answer 400 yourself if you accept
anything else on this route, and refuse to start without the secret.
const express = require("express");
const app = express();
const SECRET = process.env.DIDIT_WEBHOOK_SECRET; // secret_shared_key of the destination
// Your endpoint receives a signed payload
const crypto = require("node:crypto"); // ESM: import crypto from "node:crypto"
// X-Signature-V2 = HMAC over the canonical JSON, never the raw bytes. Match the sender byte for
// byte: keys sorted by code point, integers digit for digit, floats in Python's repr.
class Num { constructor(src) { this.src = src; } } // a number as written on the wire, not a double
const num = (s) => { if (/^-?\d+$/.test(s)) return BigInt(s).toString(); const n = +s; // ints stay exact
if (Number.isInteger(n)) return BigInt(n).toString(); const [m, e] = n.toExponential().split("e"); // 27.0 -> 27
return +e >= -4 ? String(n) : `${m}e-${String(-e).padStart(2, "0")}`; }; // 1e-05, not 0.00001
const byCodePoint = (a, b) => Buffer.compare(Buffer.from(a), Buffer.from(b)); // UTF-8 order = Python's
const canon = (v) => Array.isArray(v) ? `[${v.map(canon)}]` : v instanceof Num ? num(v.src)
: v && typeof v === "object" ? `{${Object.keys(v).sort(byCodePoint).map((k) => `${JSON.stringify(k)}:${canon(v[k])}`)}}`
: JSON.stringify(v);
// Read the body as text: express.json() would round 1000000000000000129 to a double first.
// Register this route ABOVE any global app.use(express.json()): the first parser to run
// consumes the stream, and a body it already parsed has lost the digits the signature covers.
app.post("/webhooks/didit", express.text({ type: "application/json" }), (req, res) => {
const exact = JSON.parse(req.body, (k, v, c) => typeof v === "number" ? new Num(c.source) : v); // Node 21+
const body = JSON.parse(req.body);
const mac = crypto.createHmac("sha256", SECRET).update(canon(exact), "utf8").digest("hex");
const sig = Buffer.from(String(req.headers["x-signature-v2"] ?? ""));
// Freshness comes from the signed body timestamp; the header alone is unsigned and replayable.
const ts = body.timestamp, fresh = String(ts) === req.headers["x-timestamp"]
&& Math.abs(Date.now() / 1000 - ts) <= 300;
if (!fresh || sig.length !== mac.length
|| !crypto.timingSafeEqual(sig, Buffer.from(mac))) return res.sendStatus(401);
const { status, decision } = body;
// One entry per ID Verification node; pick yours by node_id when you run several.
const [idv] = decision?.id_verifications ?? [];
// idv.verification_method: "document" | "id_lookup" | "wallet"
res.sendStatus(200);
});
Status values (exact strings): Not Started, In Progress, Approved, Declined,
In Review, Resubmitted, Expired, Abandoned, Kyc Expired. Awaiting User only
appears on business verification sessions.
## 6. Read the result
The same V3 decision reaches you two ways:
- webhook body: body.decision.id_verifications[]
- GET https://verification.didit.me/v3/session/{session_id}/decision/
-H "x-api-key: <your-api-key>"
This response IS the decision object. Read id_verifications at the top
level: there is no decision wrapper here.
Until the user finishes the ID step, status is "Not Started" or "In Progress"
and id_verifications is null, not an empty array. Guard for it.
id_verifications[] has one entry per ID Verification node; with a single step
take index 0. A wallet sign-in sets:
verification_method "wallet"
assurance "cryptographic"
wallet_provider the catalog wallet id the user picked
wallet_verification provider, provider_name, issuing_authority,
issuing_country, credential_type, level_of_assurance,
verified_at, signature_valid, attributes, portrait
(null for the live wallets), face_match_score
fallback_from { method, reason, action } when the wallet sign-in failed
and on_failure declined the session; otherwise
null. After a document fallback that succeeds the
entry reads verification_method "document" with
fallback_from null
full_name, the normalised identity fields, on the entry itself
date_of_birth
On a live application, check wallet_verification.signature_valid before you
trust attributes. The
live wallets return name, date of birth and a scheme identifier (for example
the Swedish personnummer; MitID returns a pseudonymised identifier), never an
address or a portrait: collect those through other steps if your policy
needs them.
Reference: https://docs.didit.me/core-technology/id-verification/digital-id-wallets
## 7. Billing
Only completed wallet sign-ins are billed; cancelled, timed-out and failed
ones are free. Prices per wallet: https://didit.me/pricing
## 8. Verify your integration
Sandbox (an application in sandbox mode: nothing is billed and no real eID is
called). https://docs.didit.me/integration/sandbox-testing
- a sandbox application can enable every wallet in the catalog, the
coming-soon ones included. A workflow that saves in sandbox can still be
refused on a live application, so only use wallets marked available.
- open the session url, pick the wallet and confirm: the default approve
scenario simulates the sign-in. The entry then has verification_method
"wallet", assurance "cryptographic" and wallet_provider set, and the
normalised full_name and date_of_birth are filled. But
wallet_verification.signature_valid and level_of_assurance are null and
attributes is { "sandbox": true }: no real credential was checked.
Assert signature_valid === true and the level of assurance only against
a live application.
- to exercise on_failure, create the session with
"sandbox_scenario": "wallet_cancelled" (also wallet_timeout and
wallet_provider_error). The wallet sign-in then fails and the flow moves
to document capture or declines, as on_failure says. A fallback that
ends in an approved document reads verification_method "document".
- POST /v3/session/{session_id}/simulate/ forces a final status but writes
no id_verifications entry, so it cannot stand in for a sign-in.
Checks:
- create the workflow, create a session, and read its decision: expect 201,
201 with url, and 200 with status "Not Started"
- run one sandbox session per accepted wallet through the hosted flow and
assert verification_method is "wallet" and wallet_provider is the wallet
you picked
- run one session with sandbox_scenario "wallet_cancelled" and assert the
flow offers document capture
- assert the webhook accepts a correctly signed payload and rejects a wrong
X-Signature-V2, a changed body, and a payload whose signed timestamp is
older than 300 seconds, even when X-Timestamp is refreshed
- on a live application, assert wallet_verification.signature_valid is true
Docs: https://docs.didit.me/core-technology/id-verification/digital-id-wallets
Conforme par nature
Ouvre un nouveau pays en un clic. On s'occupe du plus dur.
Nous ouvrons les filiales locales, obtenons les licences, effectuons les tests d'intrusion, obtenons les certifications et nous alignons sur chaque nouvelle réglementation. Pour déployer des vérifications dans un nouveau pays, il suffit d'activer un interrupteur. Plus de 220 pays en direct, audités et testés chaque trimestre, le seul fournisseur d'identité qu'un gouvernement d'un État membre de l'UE a formellement jugé plus sûr que la vérification en personne.
Pays de l'EEE dans le déploiement du portefeuille EUDI
220+
Pays et territoires avec la route documentaire
Trois niveaux, une seule grille tarifaire
Commence gratuitement. Payez à l'usage. Passez à l'Enterprise.
500 vérifications gratuites chaque mois, pour toujours. Ensuite, ne payez que lorsqu'un module s'exécute. Contrats personnalisés, résidence des données et accords de niveau de service (SLA) pour l'offre Enterprise.
Gratuit
$0/ mois · sans carte bancaire
Pour le développement, les tests et tes premiers utilisateurs.
Tout ce qu'il te faut pour démarrer :
500 vérifications KYC complètes chaque mois
ID, preuve de vie, correspondance faciale, appareil et IP
Plus de 200 signaux de fraude, liste noire, doublons
KYC réutilisable sur le réseau Didit
Éditeur de workflows, gestion des cas, SDK
Support IAAgent IA intégré à la console, documentation et communauté.