Dejar que alguien intente la verificación de nuevo

Dos formas de dar a un usuario un segundo intento - pedir un reenvío solo de los pasos fallidos, o empezar una sesión completamente nueva. Cuál usar depende del estado actual de la sesión.

Escrito por el soporte de Didit · Actualizado el 19 de agosto de 2026

Hay dos formas de dar a alguien otro intento: pedir un reenvío de los pasos que fallaron, o crear una sesión nueva desde cero. Cuál quieres depende del estado actual de la sesión.

#Opción 1: pedir un reenvío (la sesión está En revisión o Rechazada)

El reenvío mantiene la misma sesión y el mismo historial, y solo pide a la persona que rehaga los pasos concretos que fallaron, no toda la verificación.

12

1. Más opciones es donde una sesión se puede reabrir para que el usuario lo intente de nuevo.
2. El nuevo intento aparece en Eventos junto al primero, así puedes compararlos.

1. Abre la sesión

   En la Consola de Negocio, ve a Verificaciones y abre la sesión.

2. Pide el reenvío

   Abre el menú de acciones y selecciona Solicitar reenvío. Elige qué pasos necesita rehacer la persona: cualquier paso que no se aprobó.

3. Notifica a la persona (opcional)

   Si tienes su correo en el sistema, puedes enviarle automáticamente un enlace directo al reenvío. También puedes fijar el idioma de ese correo.

4. Espera la reevaluación

   El estado de la sesión cambia a Reenviada mientras espera. Una vez que la persona completa los pasos solicitados, el sistema reevalúa automáticamente y mueve la sesión a Aprobada, Rechazada o En revisión.

El reenvío se puede pedir más de una vez en la misma sesión: cada ronda queda en el historial de la sesión para tus registros. Los desarrolladores pueden activar lo mismo mediante la API de actualización de estado de sesión.

#Opción 2: crear una sesión nueva (la sesión caducó o fue abandonada)

Si una sesión caducó antes de que la persona la abriera, o la abandonó a medio camino, el reenvío no aplica: crea una sesión nueva y envía un enlace nuevo, ya sea desde el flujo de enlaces de verificación de la consola o mediante la API de creación de sesión. Una sesión nueva obtiene su propio ID de sesión y empieza en No iniciada.

Pasa el mismo vendor_data que usaste la primera vez. Eso es lo que agrupa ambos intentos bajo un usuario consolidado, así que mantienes una vista única de esa persona aunque las sesiones sean independientes.

#¿Cuál deberías usar?

Para un problema arreglable (una foto borrosa, el lado equivocado del documento), el reenvío es casi siempre la mejor opción: supone menos fricción para un usuario genuino, es más barato y mantiene un único registro de auditoría.

#Lo que cuesta un reintento

La facturación ocurre por función completada, así que:

• Un reenvío que solo rehace el paso del documento factura solo ese paso.
• Una sesión completamente nueva ejecuta todo el flujo de trabajo otra vez y factura cada función que se completa de nuevo.
• Un paso al que la persona nunca llega no se factura en absoluto.

Ese es el argumento práctico a favor del reenvío frente a una sesión nueva ante un fallo arreglable. Consulta qué cuenta como comprobación facturable.

#Controlar cuántos intentos recibe una persona

Si prefieres que una verificación fallida no le ofrezca a la persona otro intento dentro del mismo flujo, eso es una cuestión de configuración del flujo de trabajo: la acción del paso ante cada advertencia decide si se invita a la persona a reintentar, se envía a revisión o se rechaza directamente. Consulta reglas y umbrales de decisión.

#Relacionado

• Qué significa cada estado de sesión
• Por qué se rechazó una verificación
• Cuando una sesión no llega a completarse