Qué es el Recorrido de sesión
El Recorrido de sesión (Session Journey) es una función del panel que reúne todos los eventos ocurridos desde el momento en que un usuario entra en el formulario en vivo hasta el resultado final (aprobado, rechazado o en espera), agrupándolos cronológicamente como una sola unidad de envío. Cada evento se recopila tanto en el frontend (la acción observada en la pantalla del usuario) como en el backend (la verificación y la decisión ejecutadas en el servidor). Esto permite rastrear “por qué este usuario se bloqueó en este paso” y “cuál fue el motivo del rechazo o de la espera”.A diferencia del registro de eventos, que rastrea la actividad de los administradores y el historial de eliminaciones, el Recorrido de sesión se centra en el avance de la verificación de un solo envío.
Estado de la sesión
En la lista del Recorrido de sesión, cada envío muestra de un vistazo su grado de avance mediante su estado de la sesión. Este estado es un valor distinto de la decisión final de KYC (aprobado, rechazado o en espera); indica hasta dónde ha avanzado el recorrido.| Estado | Significado |
|---|---|
IN_PROGRESS | En curso — aún no ha llegado al resultado final |
COMPLETED | Completado — el usuario terminó el recorrido hasta el final (el resultado puede ser aprobado, rechazado o en espera) |
DROPPED | Abandono — el usuario se marchó sin completar el recorrido (no llegó a la página de resultado final) |
ERROR | Error — salió del flujo normal, por ejemplo a través de una página de error |
COMPLETED solo significa “completó el recorrido hasta el final”; no significa “fue aprobado”. Confirma siempre el estado final de aprobado, rechazado o en espera con los eventos de decisión del BE (APPROVED, REJECTED, PENDING).Precauciones clave al interpretar
Eventos del frontend (FE) y del backend (BE)
Los eventos del Recorrido de sesión se dividen en dos tipos según su origen.| Origen | Significado | Ejemplos |
|---|---|---|
| FE (frontend) | Señales observadas sobre las pantallas y acciones que vio el usuario | Entrada a la pantalla, activación de la cámara, entrada a la página de error |
| BE (backend) | Verificación, decisión y finalización reales ejecutadas en el servidor | Reconocimiento del documento de identidad, comparación de rostros, aprobación/rechazo final |
El criterio real de bloqueo o rechazo son siempre los eventos del BE. Los eventos del FE (por ejemplo,
ERROR_PAGE_VIEWED, FINAL_PAGE_VIEW) son solo una observación de que el usuario llegó a esa pantalla; el resultado final debe confirmarse con los eventos de decisión del BE (APPROVED, REJECTED, PENDING) del mismo envío.El FE y el BE a veces registran la misma acción como un par. Por ejemplo: FRONT_SESSION_START (FE) ↔ SESSION_CREATED (BE), CREATE_FLOW (una llamada a la API desde una pantalla del FE) ↔ FLOW_ID_ISSUED (resultado del procesamiento del BE). El FE muestra “qué hizo la pantalla”, mientras que el BE muestra “cómo decidió el servidor”.Etapas del recorrido
El Recorrido de sesión fluye a grandes rasgos a través de tres segmentos: Verificaciones previas → Principal → Posterior.Verificaciones previas — Entrada y comprobación de políticas
Es la etapa de control (Guard) previa a la verificación principal, que incluye la creación de la sesión y las comprobaciones de token, duplicados, IP y dispositivo. Si un usuario se detiene en este segmento, no puede entrar en la captura del documento de identidad y queda bloqueado (BLOCKED).
STEP1 — Verificación del documento de identidad
Las verificaciones relacionadas con el documento de identidad se ejecutan de forma simultánea: captura del documento, reconocimiento OCR, prueba de vida, edad, caducidad, lista negra, etc. Si se superan, se crea un envío (Submission).
Pre-STEP2 — Verificación de cuenta (opcional)
Solo ocurre en los proyectos que requieren verificación basada en la cuenta, como las transferencias de 1 won o la consulta del nombre del titular de la cuenta.
STEP2 — Verificación de selfie/rostro
Las verificaciones relacionadas con el rostro se ejecutan de forma simultánea: prueba de vida del selfie, comparación de rostros, duplicados, verificación de autenticidad gubernamental, políticas personalizadas, etc.
Decisión final y notificación
Se agregan todos los resultados de las verificaciones para finalizar el envío como aprobado, rechazado o en espera, y el resultado se notifica por webhook y correo electrónico.
Las tres decisiones finales
Cuando termina el segmento principal, el envío siempre se finaliza como una de las tres opciones siguientes.APPROVED (aprobado)
Superó todas las verificaciones y se aprobó automáticamente. Sin motivo aparte.
REJECTED (rechazado)
Rechazado por fallo de verificación/política o por superar el límite de reintentos. El motivo se distingue mediante el valor
reason.PENDING (en espera)
Se suspende el juicio automático y se requiere una revisión manual. El motivo se distingue mediante el valor
reason.Interpretar las causas de los errores
Cada evento muestra un impacto en el usuario (User Impact). Este valor indica qué impacto experimentó realmente el usuario, por lo que es lo primero que se debe comprobar al interpretar un error.| Impacto en el usuario | Significado |
|---|---|
NONE | Sin impacto (avance normal o evento de registro) |
BLOCKED | Bloqueado — el flujo normal se interrumpió |
RETAKE | Solicita repetir la captura o reintentar |
PENDING | En espera — a la espera de revisión manual |
REJECTED | Rechazado — finalizado como rechazo final |
APPROVED | Aprobado |
COMPLETED | El paso correspondiente se ha completado |