Saltar al contingut principal
Cada sessió de verificació passa per una sèrie d’estats. Entendre’ls t’ajuda a supervisar el progrés de l’usuari, automatitzar les decisions de compliment i optimitzar la conversió. Aquest enum és l’única font de veritat per a les cadenes que retornen GET /v3/session/<id>/decision/ i cada webhook de Didit.

Tots els valors d’estat

Cada estat és una cadena exacta que retornen l’API i els webhooks de Didit. Utilitza sempre la comparació estricta de cadenes al codi (per exemple, === "In Review"): aquests valors distingeixen majúscules i minúscules i inclouen espais. El valor Kyc Expired també fa servir una única K majúscula (no KYC).

Estats de les sessions

Valor de l’API: "Not Started"La sessió s’ha creat mitjançant l’API, però l’usuari encara no ha obert l’enllaç de verificació.
  • Què cal fer: Esperar que l’usuari comenci o enviar-li un recordatori si passa massa temps.
  • Transicions a: "In Progress", "Expired"
Valor de l’API: "In Progress"L’usuari ha obert l’enllaç i està completant activament els passos de verificació (captura del document, prova de vida, etc.).
  • Què cal fer: No cal fer res, perquè l’usuari està seguint el flux.
  • Transicions a: "Approved", "Declined", "In Review", "Abandoned"
Valor de l’API: "Approved"Totes les comprovacions de verificació s’han superat correctament. La identitat de l’usuari s’ha verificat.
  • Què cal fer: Concedir l’accés a l’usuari, actualitzar-ne el perfil i emmagatzemar les dades de la decisió.
  • El webhook inclou: L’objecte decision complet amb tots els resultats de les funcionalitats.
  • Transicions a: "Kyc Expired" (quan passa la data de caducitat del document verificat, que és el comportament per defecte tret que el Expiration mode sigui Allow expired per a aquell país i tipus de document). Un revisor o l’endpoint d’actualització d’estat també la pot posar a "Declined" o "Resubmitted".
Valor de l’API: "Declined"Una o més comprovacions han fallat. L’usuari no ha superat la verificació.
  • Què cal fer: Notificar l’usuari. Opcionalment, sol·licitar que es tornin a presentar els passos si el problema es pot resoldre.
  • El webhook inclou: L’objecte decision complet amb les advertències que expliquen el motiu del fracàs.
  • Transicions a: "Resubmitted" (si un revisor ho sol·licita). Un revisor o l’endpoint d’actualització d’estat també la pot posar a "Approved".
Valor de l’API: "In Review"Les comprovacions automàtiques han marcat advertències que necessiten revisió humana. Un responsable de compliment ha de prendre la decisió final.
  • Què cal fer: Un revisor ha d’obrir la sessió a la Console i aprovar-la, rebutjar-la o sol·licitar que es tornin a presentar els passos.
  • El webhook inclou: L’objecte decision complet amb les advertències.
  • Transicions a: "Approved", "Declined", "Resubmitted"
Valor de l’API: "Awaiting User"S’utilitza en sessions de KYB (verificació d’empreses) quan el pas de persones clau ha enviat la llista de parts i ha generat sessions KYC o KYB filles. La sessió pare espera fins que totes les parts obligatòries completin la seva verificació individual.
  • Què cal fer: Supervisar els estats de les sessions KYC filles. Quan totes les parts obligatòries acabin (aprovades, rebutjades o caducades), la sessió pare tornarà a agregar automàticament els resultats per determinar l’estat final.
  • El webhook inclou: La llista actual de parts i els estats de les seves sessions filles.
  • Transicions a: "Approved", "Declined", "In Review" (quan totes les sessions filles hagin arribat a un estat terminal)
  • Transicions des de: "In Progress" (després d’enviar el pas de persones clau)
  • Nota: Si es tornen a presentar els passos d’una sessió KYC filla, la sessió pare torna a "Awaiting User" fins que es completi la sessió tornada a presentar. Una comprovació del registre KYB amb estat "Declined" té prioritat sobre "Awaiting User".
Valor de l’API: "Resubmitted"Un revisor ha sol·licitat que l’usuari torni a fer passos de verificació concrets (per exemple, tornar a fer una fotografia borrosa del document).
  • Què cal fer: Esperar que l’usuari completi els passos que s’han de tornar a presentar. El sistema tornarà a avaluar automàticament la sessió.
  • El webhook inclou: L’objecte resubmit_info amb la llista de funcionalitats que cal repetir i els motius.
  • Transicions a: "Approved", "Declined", "In Review" o "Abandoned" quan la finestra de la sessió acabi abans que la persona torni a fer els passos.
Valor de l’API: "Expired"La sessió ha caducat abans que l’usuari obrís l’enllaç de verificació.
  • Què cal fer: Crear una sessió nova i enviar a l’usuari un enllaç nou.
  • Estat terminal: no hi ha més transicions.
Valor de l’API: "Abandoned"L’usuari ha començat però no ha acabat la verificació dins del termini permès.
  • Què cal fer: Enviar un recordatori o crear una sessió nova.
  • Sense transicions automàtiques. Un revisor, o PATCH /v3/session/{sessionId}/update-status/, encara la pot posar a "Approved", "Declined" o "Resubmitted".
Valor de l’API: "Kyc Expired"El document verificat durant la sessió ha superat la seva pròpia data de caducitat. L’activador és aquesta data, no un termini mesurat des de l’aprovació, i no s’envia cap avís previ.
  • Què cal fer: Demanar a l’usuari que es torni a verificar amb una sessió nova. status.updated notifica la transició, i el resultat de la verificació d’identitat porta una advertència DOCUMENT_EXPIRED.
  • Controlat per: el Expiration mode d’aquell país i tipus de document a ID verification → Additional settings by country & document type. Reject expired (el valor per defecte) supervisa el document; Allow expired fa que la sessió mai passi a aquest estat.
  • Sense transicions automàtiques. Un revisor, o PATCH /v3/session/{sessionId}/update-status/, encara la pot posar a "Approved", "Declined" o "Resubmitted".

Transicions d’estat

Diagrama del cicle de vida


Terminal vs no terminal


Gestió dels estats al vostre codi

Utilitzeu webhooks o la API de recuperació de sessió per reaccionar als canvis d’estat.
Els estats són cadenes exactes, sensibles a majúscules i minúscules, amb espais. Per exemple, "In Review" (no "in_review" ni "IN_REVIEW"). Utilitzeu sempre la igualtat estricta (===) en fer la comparació.

Reenviament

L’estat Resubmitted permet que el vostre equip de compliment doni a l’usuari una segona oportunitat sense crear una sessió nova.
1

El revisor inicia el reenviament

Des de la Console, obre una sessió In Review o Declined i fes clic a Sol·licitar reenviament. Selecciona quins passos s’han de tornar a fer.
2

Les dades anteriors s'arxiven

El sistema reinicia les funcionalitats seleccionades i marca les dades prèvies com a previous_attempt, conservant tot el registre d’auditoria.
3

Es notifica l'usuari

Si hi ha un correu electrònic disponible, l’usuari rep un correu electrònic localitzat amb un enllaç directe per reprendre el procés.
4

L'usuari refà passos concrets

L’usuari només repeteix els passos marcats, no tota la verificació.
5

El sistema torna a avaluar

Quan es completa, la sessió passa automàticament a "Approved", "Declined" o "In Review".

Payload del webhook de reenviament

reasons relaciona cada node_id reenviat amb el codi d’advertència del registre més rellevant d’aquest pas (els mateixos codis que informa la decisió), perquè el pugueu relacionar amb la vostra pròpia còpia. També és el codi que la pantalla de reenviament del flux allotjat i el correu de reenviament localitzen per a l’usuari, excepte les advertències que revelarien un senyal de cribratge o de frau (duplicats, AML, llista de bloqueig, comprovacions entre organitzacions, integritat de la ubicació i similars): en aquests casos la persona veu un motiu genèric, i resubmit_info.reasons del vostre webhook sempre conté el codi real. Un pas sense cap advertència registrada no té entrada.

Quines funcionalitats es poden reenviar?

Qualsevol funcionalitat amb un estat no aprovat: Declined, In Review, Not Finished, Not Started o Expired.
Podeu sol·licitar el reenviament diverses vegades en la mateixa sessió. Cada cicle arxiva les dades de l’intent anterior, cosa que us dona una visibilitat completa de l’historial de verificació de l’usuari.

Pràctiques recomanades

Supervisa les sessions en revisió

Configura alertes (per correu electrònic o Slack) a la Didit Console per rebre una notificació quan les sessions necessitin revisió manual.

Prioritza el reenviament

Si el problema es pot resoldre (una fotografia borrosa, el costat equivocat del document), sol·licita un reenviament en lloc de rebutjar la sessió. Així millora la conversió.

Fes seguiment dels abandonaments

Unes taxes elevades de sessions abandonades o caducades poden indicar fricció en l’experiència d’usuari. Considera ajustar el TTL de la sessió o millorar les indicacions per a l’usuari.

Gestors idempotents

Els webhooks es poden reintentar. Utilitza session_id com a clau única per assegurar que processis cada canvi d’estat només una vegada.
Verifica sempre les signatures dels webhooks abans de processar els payloads. Didit ofereix tres mètodes: X-Signature, X-Signature-V2 (recomanat) i X-Signature-Simple, obsolet, que només autentica l’embolcall i mai el cos decision. Consulta Webhooks per a més detalls.
Darrera modificació el 7 de novembre del 2026