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
No iniciada - "Not Started"
No iniciada - "Not Started"
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"
En curs - "In Progress"
En curs - "In Progress"
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"
Aprovada - "Approved"
Aprovada - "Approved"
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
decisioncomplet 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".
Rebutjada - "Declined"
Rebutjada - "Declined"
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
decisioncomplet 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".
En revisió - "In Review"
En revisió - "In Review"
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
decisioncomplet amb les advertències. - Transicions a:
"Approved","Declined","Resubmitted"
Esperant l’usuari - "Awaiting User"
Esperant l’usuari - "Awaiting User"
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".
Tornada a presentar - "Resubmitted"
Tornada a presentar - "Resubmitted"
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_infoamb 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.
Caducada - "Expired"
Caducada - "Expired"
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.
Abandonada - "Abandoned"
Abandonada - "Abandoned"
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".
KYC caducat - "Kyc Expired"
KYC caducat - "Kyc Expired"
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.updatednotifica la transició, i el resultat de la verificació d’identitat porta una advertènciaDOCUMENT_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.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.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.