What is Session Journey
Session Journey is a dashboard feature that gathers every event that occurred from the moment a user entered the live form until the final outcome (approved, rejected, or pending), grouped chronologically as a single submission unit. Each event is collected from both the frontend (behavior observed on the user’s screen) and the backend (verifications and decisions executed on the server). This lets you trace back “why this user was blocked at this step” and “what the rejection or pending reason was.”Unlike the Event Log, which tracks admin activity and deletion history, Session Journey focuses on the verification progress of a single submission.
Session status
In the Session Journey list, each submission shows its progress at a glance through its session status. This status is a different value from the final KYC decision (approved, rejected, or pending); it indicates how far the journey has progressed.COMPLETED only means “the journey was completed to the end”; it does not mean “approved.” Always confirm the final approved, rejected, or pending status with the BE decision events (APPROVED, REJECTED, PENDING).Key cautions when interpreting
Frontend (FE) and backend (BE) events
Session Journey events fall into two types depending on their source.The actual basis for blocking or rejection is always BE events. FE events (e.g.,
ERROR_PAGE_VIEWED, FINAL_PAGE_VIEW) are merely observations that the user reached that screen; the final outcome must be confirmed with the BE decision events (APPROVED, REJECTED, PENDING) of the same submission.FE and BE sometimes record the same action as a pair. For example: FRONT_SESSION_START (FE) ↔ SESSION_CREATED (BE), CREATE_FLOW (an API call from an FE screen) ↔ FLOW_ID_ISSUED (BE processing result). FE shows “what the screen did,” while BE shows “how the server decided.”Stages of the journey
The Session Journey broadly flows through three segments: Pre-checks → Main → Post.1
Pre-checks — Entry and policy checks
The gating (Guard) stage before the main verification, including session creation and token, duplicate, IP, and device checks. If a user is stopped in this segment, they cannot enter ID document capture and are blocked (BLOCKED).
2
STEP1 — ID document verification
ID document-related verifications run simultaneously, including document capture, OCR recognition, liveness, age, expiration, and blacklist checks. On success, a submission (Submission) is created.
3
Pre-STEP2 — Account verification (optional)
Occurs only in projects that require account-based verification, such as 1-won transfers or account holder name lookups.
4
STEP2 — Selfie/face verification
Face-related verifications run simultaneously, including selfie liveness, face comparison, duplicate, government authenticity checks, and custom policies.
5
Final decision and notification
All verification results are aggregated to finalize the submission as approved, rejected, or pending, and the result is notified via webhook and email.
6
Post — Result page
The user reaches the result page and the journey ends.
The three final decisions
When the Main segment ends, the submission is always finalized as one of the following three.APPROVED
Passed all verifications and was automatically approved. No separate reason.
REJECTED
Rejected due to verification/policy failure or exceeding the retry limit. The reason is distinguished by the
reason value.PENDING
Automatic judgment is held and manual review is required. The reason is distinguished by the
reason value.Interpreting error causes
Each event shows a User impact. This value indicates what impact the user actually experienced, so it is the first thing to check when interpreting an error.
For the full list of events and their meanings, see the Session Journey event reference.