Deixar que algú provi una verificació una altra vegada

Dues maneres de donar a un usuari un segon intent - demanar un reenviament només dels passos que han fallat, o iniciar una sessió completament nova. Quina fer servir depèn de l'estat actual de la sessió.

Escrit pel suport de Didit · Actualitzat el 19 d’agost del 2026

Hi ha dues maneres de donar a algú un altre intent: demanar un reenviament dels passos que han fallat, o crear una sessió nova des de zero. Quina vols dependrà de l'estat actual de la sessió.

#Opció 1: Demanar un reenviament (la sessió està In Review o Declined)

El reenviament manté la mateixa sessió i el mateix historial, i només demana a la persona que refaci els passos concrets que han fallat - no tota la verificació.

12

1. More options és des d'on es pot reobrir una sessió perquè l'usuari ho torni a provar.
2. El nou intent apareix a Events al costat del primer, així els pots comparar.

1. Obre la sessió

   A la Business Console, vés a Verificacions i obre la sessió.

2. Demana el reenviament

   Obre el menú d'accions i selecciona Request Resubmission. Tria quins passos ha de refer la persona - qualsevol pas que no s'hagi aprovat.

3. Notifica la persona (opcional)

   Si tens el seu correu electrònic registrat, pots enviar-li automàticament un enllaç directament al reenviament. També pots establir l'idioma d'aquest correu.

4. Espera la reavaluació

   L'estat de la sessió canvia a Resubmitted mentre espera. Un cop la persona completa els passos demanats, el sistema la reavalua automàticament i mou la sessió a Approved, Declined, o In Review.

Es pot demanar un reenviament més d'una vegada sobre la mateixa sessió - cada ronda queda registrada en l'historial de la sessió per als teus registres. Els desenvolupadors poden fer el mateix a través de l'API d'actualització d'estat de sessió.

#Opció 2: Crear una sessió nova (la sessió està Expired o Abandoned)

Si una sessió ha caducat abans que la persona obrís l'enllaç, o l'ha abandonat a mig camí, el reenviament no s'aplica - crea una sessió nova i envia-li un enllaç nou, ja sigui des del flux d'enllaços de verificació de la consola o via la API de creació de sessió. Una sessió nova obté el seu propi ID de sessió i comença des de Not Started.

Passa el mateix vendor_data que vas fer servir la primera vegada. Això és el que agrupa tots dos intents sota un únic usuari consolidat, així mantens una única visió d'aquesta persona encara que les sessions siguin separades.

#Quina hauries de fer servir?

Per a un problema arreglable - una foto borrosa, la cara equivocada del document -, el reenviament sol ser gairebé sempre la millor opció: és menys fricció per a un usuari genuí, més econòmic, i manté un únic registre d'auditoria.

#Què et costa un reintent

La facturació es fa per funció completada, així que:

• Un reenviament que només refà el pas de document només factura aquest pas.
• Una sessió completament nova executa tot el flux de treball una altra vegada i factura cada funció que es torni a completar.
• Un pas al qual la persona mai arriba no es factura de cap manera.

Aquest és l'argument pràctic a favor del reenviament davant d'una sessió nova en una fallada arreglable. Consulta què compta com a comprovació facturable.

#Controlar quants intents rep una persona

Si prefereixes que una verificació fallida no ofereixi a la persona un altre intent dins del mateix flux, això és una qüestió de configuració del flux de treball - l'acció del pas davant de cada avís decideix si es convida la persona a reintentar-ho, s'envia a revisió, o es denega directament. Consulta regles i llindars de decisió.

#Relacionat

• Què significa cada estat de sessió
• Per què s'ha denegat una verificació
• Quan una sessió no acaba mai