Skip to main content

​
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.
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

Los eventos se enumeran cronológicamente, pero en realidad muchas verificaciones se ejecutan de forma simultánea.Que los eventos aparezcan de arriba abajo en la pantalla no significa que “el evento anterior sea la causa del posterior”. Por ejemplo, el reconocimiento del documento de identidad, la prueba de vida y la verificación de edad se ejecutan casi al mismo tiempo, y el orden de visualización solo refleja pequeñas diferencias en el momento del registro. Juzga la relación causal a partir del valor de resultado y del impacto en el usuario de cada evento, no del orden.

​
Eventos del frontend (FE) y del backend (BE)

Los eventos del Recorrido de sesión se dividen en dos tipos según su origen.
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.
1

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).
2

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).
3

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.
4

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.
5

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.
6

Posterior — Página de resultado

El usuario llega a la página de resultado y el recorrido finaliza.

​
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.
Para los códigos de motivo concretos de rechazo y espera, consulta la tabla “Motivos de la decisión final” en la referencia de eventos del Recorrido de sesión.

​
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.
El orden para interpretar los errores: ① Comprueba primero los eventos de decisión final (APPROVED, REJECTED, PENDING) y su reason → ② Encuentra los eventos de verificación del BE que provocaron un impacto BLOCKED o RETAKE en el mismo paso → ③ Usa los eventos de observación del FE para confirmar de forma complementaria la pantalla que vio el usuario. No los leas de arriba abajo en el orden mostrado.
Para la lista completa de eventos y sus significados, consulta la referencia de eventos del Recorrido de sesión.