Prepárate para aceptar la Cartera Europea de Identidad Digital (EUDI Wallet).
Todos los Estados miembros de la UE deben ofrecer una Cartera Europea de Identidad Digital (EUDI Wallet) antes del 24 de diciembre de 2026, y las empresas reguladas deben aceptarla antes del 24 de diciembre de 2027. Didit ya opera con cinco identificaciones electrónicas (eIDs) nacionales, y la aceptación de la cartera EUDI estará disponible pronto en el mismo flujo de trabajo.
Con la confianza de más de 3.000 organizaciones en todo el mundo.
EUDI WalletAtestación de identidad y edad
La tienda online solicitaMayor de 18 años
Apellido
Nombre
Fecha de nacimiento
Lugar de nacimiento
Nacionalidad
Mayor de 18 años
Compartir 1 atributo
Parte confiableTienda online
age_over_18true
Firma del emisor
Vinculación del dispositivo
5 atributos retenidos
Qué es la cartera EUDI
Una cartera por persona. Solo los datos que pidas.
La cartera EUDI es una aplicación gratuita que todos los Estados miembros de la UE deben ofrecer según el Reglamento (UE) 2024/1183, conocido como eIDAS 2. Contiene datos de identificación personal (PID), es decir, nombre, fecha y lugar de nacimiento y nacionalidad, además de declaraciones electrónicas de atributos como el carné de conducir o un diploma. Su uso es voluntario.
Cuando una empresa solicita datos, la persona ve quién los pide y comparte solo los atributos solicitados. Esto se llama divulgación selectiva: un sitio puede saber que alguien es mayor de 18 años sin ver la fecha de nacimiento. La cartera funciona con un nivel de garantía alto, el más fuerte de los tres niveles de eIDAS, y la empresa verifica la firma del emisor antes de confiar en los datos.
Última revisión: 5 de octubre de 2026. No es asesoramiento legal.
Fechas clave
Carteras para finales de 2026. Aceptación antes del 24 de diciembre de 2027.
Estas son las fechas del Reglamento (UE) 2024/1183 y sus actos de ejecución que una empresa debería tener en cuenta.
30 de abril de 2024
Publicación de eIDAS 2
El Reglamento (UE) 2024/1183, que modifica el Reglamento eIDAS (UE) n.º 910/2014, aparece en el Diario Oficial de la UE. Entra en vigor a los veinte días de su publicación.
24 de diciembre de 2024
Primeras normas de la cartera en vigor
Los primeros cinco reglamentos de ejecución para la cartera entran en vigor: datos de identificación personal, funciones principales, notificaciones, certificación y protocolos e interfaces. Estos inician los plazos de 24 y 36 meses que se indican a continuación.
15 de julio de 2026
Normas de la cartera actualizadas
La Comisión adopta el Reglamento de Ejecución (UE) 2026/1731. Este establece los dos formatos de credenciales, SD-JWT VC e ISO/IEC mdoc, y programa el retrato obligatorio para 2028.
23 de julio de 2026
ARF v3.0.0
El Marco de Arquitectura y Referencia (ARF), el plano técnico sobre el que se construyen las carteras y las partes usuarias en ellas, alcanza la versión 3.0.0.
24 de diciembre de 2026
Carteras en todos los Estados miembros
Cada Estado miembro debe proporcionar al menos una cartera EUDI. Las normas para el registro de las partes usuarias en ella, el Reglamento de Ejecución (UE) 2025/848, se aplican a partir del mismo día.
24 de diciembre de 2027
Las empresas privadas deben aceptarla
Las empresas privadas que deban utilizar una autenticación de usuario fuerte por ley o por contrato, excepto las micro y pequeñas empresas, deben aceptar la cartera cuando un usuario solicite usarla (Artículo 5f, apartado 2). Ese plazo es de 36 meses desde la entrada en vigor de los primeros actos de ejecución, el 24 de diciembre de 2024, es decir, hasta el 24 de diciembre de 2027.
11 de agosto de 2028
Retrato y comprobaciones de registro
El retrato pasa a formar parte de los datos de identificación personal obligatorios, y las carteras deben autenticar y validar el certificado de registro de cada parte usuaria en ellas.
Quién debe aceptarla
Quién tiene que aceptar la cartera, y cuándo.
El artículo 5f del Reglamento eIDAS, modificado por el Reglamento (UE) 2024/1183, establece las obligaciones de aceptación. En todos los casos, el usuario elige usar la cartera, y tú mantienes tus otras formas de identificar a las personas.
Quién
Qué significa, en lenguaje sencillo
Artículo · fecha
Quién
Organismos del sector público
Qué significa, en lenguaje sencillo
Si un Estado miembro exige identificación electrónica para acceder a un servicio público online, ese servicio también debe aceptar la cartera EUDI.
Artículo · fecha
Art. 5f(1)
Quién
Servicios privados que deben usar autenticación de usuario robusta
Qué significa, en lenguaje sencillo
Si una ley o contrato te exige usar autenticación de usuario robusta para la identificación online, también debes aceptar la cartera EUDI. El detonante es ese requisito, no tu sector.
Artículo · fecha
Art. 5f(2) · 24 Dic 2027
Quién
Áreas que menciona el artículo
Qué significa, en lenguaje sencillo
Transporte, energía, banca, servicios financieros, seguridad social, salud, agua potable, servicios postales, infraestructura digital, educación y telecomunicaciones. El artículo dice «incluyendo», por lo que la lista es ejemplificativa y no cerrada.
Artículo · fecha
Art. 5f(2)
Quién
Micro y pequeñas empresas
Qué significa, en lenguaje sencillo
Exentas del deber del sector privado, según la Recomendación 2003/361/CE de la Comisión. Pueden aceptar la wallet si así lo desean.
Artículo · fecha
Art. 5f(2)
Quién
Solo a petición del usuario
Qué significa, en lenguaje sencillo
La aceptación es obligatoria cuando el usuario solicita usar la wallet. Su uso es voluntario para las personas, y los servicios deben seguir abiertos a otros medios de identificación y autenticación.
Artículo · fecha
Arts. 5f(2), 5a(15)
Quién
Plataformas online muy grandes
Qué significa, en lenguaje sencillo
Las plataformas designadas bajo la Ley de Servicios Digitales que requieren autenticación de usuario deben aceptar la wallet a petición del usuario, para los datos mínimos que el servicio necesite. El texto no establece una fecha separada para esta obligación.
Artículo · fecha
Art. 5f(3)
Las partes usuarias en la identidad también deben registrarse en el Estado miembro donde estén establecidas, y solo pueden solicitar los datos que hayan registrado (Artículo 5b). Última revisión: 5 de octubre de 2026. No es asesoramiento legal.
Cómo la acepta una empresa
Cómo una parte usuaria en la identidad acepta la cartera EUDI, en cinco pasos.
Paso 01 / 05
01
Regístrate como parte usuaria en la identidad
Regístrate en el Estado miembro donde estés establecido, con tus datos y la información que pretendes solicitar. Recibirás un certificado de acceso, que te autentica ante la wallet, y, si tu Estado miembro lo emite, un certificado de registro que enumera los atributos que registraste.
Solicita solo lo que necesites
Pide atributos específicos, por ejemplo, ser mayor de 18 años, con OpenID for Verifiable Presentations (OpenID4VP) y una consulta de Digital Credentials Query Language (DCQL), o con ISO/IEC 18013-7. No puedes solicitar datos más allá de tu registro.
El usuario da su consentimiento en la wallet
En el mismo teléfono, el navegador pasa el control a la app de la wallet. En un ordenador, el usuario escanea un código QR. La wallet muestra quién está solicitando, comprueba que no pides más de lo que registraste, y el usuario aprueba o rechaza.
Verifica la presentación
Comprueba la firma del emisor contra las listas de confianza, verifica que la credencial no ha sido revocada y comprueba la vinculación del dispositivo, lo que demuestra que la credencial no fue copiada ni reutilizada.
Recibe los atributos y decide
Recibes solo los atributos que el usuario compartió, firmados por el emisor. La decisión de onboarding o acceso, y el registro que guardes, quedan contigo.
Didit ejecutará estos pasos por ti cuando se lance la aceptación de la cartera EUDI (próximamente).
Lo que recibes vs. lo que aún necesita el KYC
La wallet prueba quién es alguien. La diligencia debida necesita más.
Según el Reglamento Antilavado de Dinero (AMLR), Reglamento (UE) 2024/1624, la identificación electrónica con un nivel de garantía sustancial o alto es una de las dos formas de verificar la identidad (Artículo 22(6)). No cubre todo lo que exigen las comprobaciones de conocimiento del cliente (KYC). Aquí te mostramos lo que contienen los datos de identificación personal (PID) y cómo Didit cubre cada elemento hoy.
Necesidades de diligencia debida
En el PID de la cartera EUDI
Cómo lo cubre Didit hoy
Necesidades de diligencia debida
Todos los nombres y apellidos
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
Apellido y nombre, ambos obligatorios.
Cómo lo cubre Didit hoy
Los eIDs nacionales en vivo devuelven el nombre completo. La ruta de documentos lo lee de más de 14.000 tipos de documentos.
Necesidades de diligencia debida
Lugar y fecha completa de nacimiento
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
Fecha y lugar de nacimiento, ambos obligatorios.
Cómo lo cubre Didit hoy
Los eIDs nacionales en vivo devuelven la fecha de nacimiento. La ruta de documentos lee el lugar de nacimiento donde el documento lo imprime.
Necesidades de diligencia debida
Nacionalidades
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
Nacionalidad, obligatoria, uno o más países.
Cómo lo cubre Didit hoy
La ruta de documentos lee la nacionalidad del documento de identidad o de su chip.
Necesidades de diligencia debida
Número de identificación nacional, cuando corresponda
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
Número administrativo personal, opcional. Cada Estado miembro decide si lo emite.
Cómo lo cubre Didit hoy
Los eIDs nacionales en vivo devuelven un identificador del sistema: el personnummer sueco, el código de identidad personal finlandés o el código personal báltico. MitID devuelve un identificador seudonimizado, no el número CPR.
Necesidades de diligencia debida
Lugar de residencia habitual
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
Los campos de dirección son opcionales y a menudo faltan. Los estándares finales de la AMLA dicen que los atributos faltantes deben obtenerse por otros medios.
Cómo lo cubre Didit hoy
Ningún eID nacional en vivo devuelve una dirección. La prueba de dirección verifica una factura de servicios, un extracto bancario o una carta del gobierno.
Necesidades de diligencia debida
Número de identificación fiscal, cuando esté disponible
AMLR Art. 22(1)(a)
En el PID de la cartera EUDI
No forma parte del PID.
Cómo lo cubre Didit hoy
Recógelo con un paso de cuestionario en el mismo flujo de trabajo.
Necesidades de diligencia debida
La persona coincide con la identidad
ARF · vinculación de usuario
En el PID de la cartera EUDI
El retrato sigue siendo opcional hasta que sea obligatorio el 11 de agosto de 2028.
Cómo lo cubre Didit hoy
Detección de vida pasiva y una coincidencia facial 1:1 con la foto del documento o el retrato del chip, dentro de la verificación KYC completa por US$0.33.
Necesidades de diligencia debida
Beneficiarios reales de una empresa
AMLR Art. 20(1)(b)
En el PID de la cartera EUDI
No en el PID. Una cartera identifica a una persona, no a quién posee una empresa.
Cómo lo cubre Didit hoy
La verificación de empresas extrae datos de registro y propietarios donde el registro los tiene, con una verificación de identidad para cada propietario.
Necesidades de diligencia debida
Sanciones y personas políticamente expuestas (PEP)
AMLR Art. 20(1)(d), (g)
En el PID de la cartera EUDI
No en el PID.
Cómo lo cubre Didit hoy
Detección AML contra más de 1.300 listas de sanciones, PEP y vigilancia, por US$0.20 por verificación.
Necesidades de diligencia debida
Propósito de la relación y monitoreo continuo
AMLR Arts. 25, 26
En el PID de la cartera EUDI
No en el PID.
Cómo lo cubre Didit hoy
Los cuestionarios registran el propósito de la relación. El monitoreo continuo vuelve a examinar a los clientes todos los días por US$0.07 por persona al año.
La diligencia debida del cliente sigue siendo tu obligación. Didit proporciona verificaciones y pruebas y no te convierte por sí solo en cumplidor. La AMLR se aplica a partir del 10 de julio de 2027, y los estándares técnicos de la AMLA son un borrador final del 30 de septiembre de 2026, no una ley.
Preparación por país
Así están las carteras nacionales, fechadas y con fuentes.
Esto es lo que ha publicado cada país, o lo que informa una fuente identificada, con la fecha y un enlace para cada fila.
Estado a 5 de octubre de 2026
País
Cartera o app
Estado
Fecha
Lo que se sabe
País
Italia
Cartera o app
IT-Wallet (app IO)
Estado
App en vivo
Fecha
17 de febrero de 2026
Lo que se sabe
En vivo en la app IO, con 10.1 millones de activaciones y 17.3 millones de documentos cargados para el 17 de febrero de 2026. Gratuita y opcional para adultos, que inician sesión con CIE o SPID.
AltID está disponible con un documento de identidad digital y prueba de edad, y 281.390 personas lo habían creado a 4 de agosto de 2026. La Agencia para el Gobierno Digital está implementando la cartera por fases.
Sandbox público desde diciembre de 2025. La app se espera para principios de 2027, comenzando con la función de identificación. La ley de implementación tuvo su primera lectura en el Bundestag el 23 de septiembre de 2026.
No listados: Austria, Bélgica, Estonia, Hungría, Letonia, Lituania, Luxemburgo, Malta, Portugal, Eslovenia. No encontramos un estado público para ellos en esta fecha. Actualizamos esta tabla a medida que se lanzan las apps nacionales.
Cómo Didit te ayuda · Cinco filas
Acepta eIDs nacionales ahora. Añade la Cartera EUDI después.
La cartera EUDI añade una ruta; no sustituye a las demás. Crea el flujo de trabajo una sola vez: eIDs nacionales y documentos hoy, y la aceptación de la cartera EUDI en el mismo paso de verificación de identidad cuando se lance.
Acepta las eIDs nacionales que tus clientes ya usan.
Cinco eIDs nacionales ya están disponibles en Didit en siete países: MitID, BankID Sweden, Finnish Trust Network, Smart-ID y Mobile-ID. El usuario inicia sesión con su eID y la sesión recibe atributos firmados: nombre completo, fecha de nacimiento, un identificador del sistema (por ejemplo, el personnummer sueco; MitID devuelve un identificador seudonimizado) y el nivel de garantía que el esquema afirmó. Solo se facturan los inicios de sesión completados.
Niveles según la clasificación de Didit. No se devuelve dirección ni foto.
02 · EUDI Wallet, próximamente
Aceptación de EUDI Wallet, en el mismo flujo de trabajo.
La aceptación de la cartera EUDI llegará pronto. Nuestro catálogo de wallets la incluye para 30 países del EEE, en el mismo paso de verificación de identidad que las eID nacionales. Todavía no hay fecha ni precio.
Aún no hay fecha ni precio para la aceptación de la cartera EUDI.
03 · Ruta de documentos
Una ruta de documentos para quienes no tienen wallet.
No todo el mundo tendrá o usará una wallet, y la ley mantiene abiertas otras vías. La ruta de documentos lee el chip de pasaportes y tarjetas de identidad mediante NFC ($0.15), ejecuta la prueba de vida pasiva y compara la cara con la foto del documento, en más de 14.000 tipos de documentos en más de 220 países y territorios.
La cartera EUDI puede demostrar que alguien es mayor de 18 años sin una fecha de nacimiento. Hasta que las wallets sean comunes, la estimación de edad a partir de un selfie cuesta $0.10 por verificación y envía los resultados dudosos a un sistema de verificación de identidad de respaldo. Un inicio de sesión eID en vivo también devuelve una fecha de nacimiento firmada sin una foto del documento.
Detección, monitoreo y empresas, en un solo lugar.
La identidad es una parte de la diligencia debida del cliente. En el mismo flujo de trabajo, detecta personas en más de 1.300 listas de sanciones, PEP y listas de vigilancia ($0.20 por verificación), vuelve a detectarlas cada día con monitoreo continuo ($0.07 por persona al año), y verifica empresas y sus propietarios.
Nordwind Handel GmbHEmpresa · propietarios en el ámbito
0 / 1,327 listsLimpioEnviado a revisión
K. Brandt · 60%A. Lindqvist · 40%
OFAC SDNSanctions
EU Consolidated SanctionsSanctions
UN Security CouncilSanctions
UK HM TreasurySanctions
PEP · Level 1 · Heads of statePEP
PEP · Level 2 · ParliamentPEP
PEP · Level 3 · Civil servicePEP
PEP · Level 4 · RCAPEP
Adverse media · Financial crimeMedia
Adverse media · FraudMedia
Adverse media · NarcoticsMedia
Regulatory enforcementWarnings
Fitness & probityWarnings
Interpol noticesCriminal
Special interest · SIPWarnings
Special interest · SIEWarnings
InsolvencyWarnings
G20 national listsSanctions
Custom watchlistsCustom
OFAC SDNSanctions
EU Consolidated SanctionsSanctions
UN Security CouncilSanctions
UK HM TreasurySanctions
PEP · Level 1 · Heads of statePEP
PEP · Level 2 · ParliamentPEP
PEP · Level 3 · Civil servicePEP
PEP · Level 4 · RCAPEP
Adverse media · Financial crimeMedia
Adverse media · FraudMedia
Adverse media · NarcoticsMedia
$0.20 / verificación
Ver el flujo
Lo que la persona ve, en cuatro pantallas.
Una presentación multidispositivo como la describe el ARF: la persona empieza en un ordenador y termina en el teléfono que contiene la wallet.
01Escanea para continuar
Escanea el código QR
El servicio muestra un código QR y la persona lo escanea con la app de la wallet.
02La tienda online pide: mayor de 18 años
Revisa la solicitud
La wallet muestra quién solicita y qué atributos.
03Compartir 1 atributo
Compartir
La persona aprueba, y solo los atributos solicitados salen del teléfono.
04Verificado
Verificado
El servicio comprueba la firma del emisor y continúa. No se compartió nada más.
Una ilustración del flujo estándar. La aceptación de EUDI Wallet de Didit estará disponible próximamente.
Intégralo hoy
Intégralo hoy y mantenlo cuando llegue la cartera.
Todavía no existe una API de Didit específica para EUDI. Crea una sesión para un flujo de trabajo que acepte los eIDs nacionales y documentos en vivo, y luego lee el resultado. La aceptación de la cartera EUDI está prevista para el mismo paso de verificación de identidad.
Prepárate para la cartera EUDI con un solo prompt.
Copia este prompt en tu agente de codificación. Construye el flujo de trabajo que puedes ejecutar hoy, eIDs nacionales en vivo con un respaldo de documentos, además de la llamada de sesión y el webhook firmado. No inventa ningún endpoint EUDI, porque aún no existe ninguno.
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
Cumplimiento por diseño
Abre un nuevo país en un clic. Nosotros hacemos el trabajo duro.
Abrimos las filiales locales, aseguramos las licencias, realizamos las pruebas de penetración, obtenemos las certificaciones y nos alineamos con cada nueva regulación. Para lanzar verificaciones en un nuevo país, activa un interruptor. Más de 220 países en vivo, auditados y probados trimestralmente, el único proveedor de identidad que un gobierno de un estado miembro de la UE ha calificado formalmente como más seguro que la verificación presencial.
Países del EEE en el despliegue de la cartera EUDI
220+
Países y territorios con la ruta de documentos
Tres niveles, una lista de precios
Empieza gratis. Paga por uso. Escala a Enterprise.
500 verificaciones gratis cada mes, para siempre. Después, paga solo cuando se ejecute un módulo. Contratos personalizados, residencia de datos y acuerdos de nivel de servicio (SLA) en Enterprise.
Gratis
$0/ mes · sin tarjeta
Para construir, probar y tus primeros usuarios.
Todo lo que necesitas para empezar:
500 verificaciones KYC completas cada mes
ID, prueba de vida, coincidencia facial, dispositivo e IP
Más de 200 señales de fraude, lista de bloqueo, duplicados
KYC reutilizable en toda la red Didit
Constructor de flujos de trabajo, gestión de casos, SDKs
Soporte con IAAgente de IA en consola, documentación y comunidad.