How Verifa Works
Verifa is a programmable identity verification platform. You define verification workflows, your users complete them through a capture experience, and Verifa returns structured results with extracted data, biometric scores, and fraud signals.
Architecture overview
Verifa is built around five core concepts:
-
Session — A verification request. Your server creates a session via the API, and receives a
capture_urlto send the user to. -
Capture — The user-facing experience. Verifa handles document scanning, selfie collection, liveness detection, and consent — either through the hosted web capture or a mobile SDK.
-
Workflow — A directed graph of verification steps. The workflow engine executes checks in sequence — OCR extraction, face matching, age verification, watchlist screening, fraud scoring — and routes to a terminal outcome.
-
Result — The structured output of a completed workflow. Contains extracted PII, biometric scores, check outcomes, and a final decision (approved, rejected, or needs review).
-
Review Case — When a session requires human judgment, Verifa creates a review case in the queue. Reviewers can approve, reject, or escalate cases through the dashboard or API.
The verification flow
Step 1: Create a session
Your server sends a POST /api/v1/sessions request with an optional
external_ref (your user ID), country code, and workflow selection. Verifa
returns a session object with a capture_url.
Step 2: User completes capture
Redirect (or embed) the user at the capture_url. The capture flow guides them
through:
- Consent — Biometric processing consent with timestamp and IP recording.
- Document selection — Choose document type (passport, driver’s license, national ID, etc.).
- Document upload — Photograph the front (and back, if applicable) of their ID. Images are encrypted at rest immediately.
- Selfie — Take a live selfie for biometric face matching.
- Liveness — Complete a randomized liveness challenge (blink, smile, head turn) to prove physical presence.
- Additional data — Optionally provide email, phone, address, or proof of address documents.
The session status transitions from pending to capturing as the user
progresses.
Step 3: Workflow execution
Once the user completes capture, the session moves to processing and the
workflow engine takes over. A typical workflow executes:
Each step produces an independent result. If a step fails, the workflow routes based on your configured graph — to a rejection terminal, a review queue, or an alternative check path.
Step 4: Receive the result
Verifa delivers results through two channels:
- Webhooks — A
session.approvedorsession.declinedevent is sent to your configured endpoint in real time. - API polling — Call
GET /api/v1/sessions/{id}to check the session status, thenGET /api/v1/sessions/{id}/resultfor the full result.
The result contains:
Step 5: Manual review (when needed)
If the workflow routes to needs_review, a review case is created. Your team
can:
- Claim the case from the queue
- View extracted data, documents, check results, and fraud signals
- Approve or reject with a reason
- Escalate to a senior reviewer for dual-review workflows
The final decision updates the session result and fires a webhook.
Identities
When a session completes with an external_ref, Verifa upserts a persistent
Identity record. Identities aggregate all verification sessions for a single
person, enabling:
- Reverification without starting from scratch
- Cross-session duplicate detection
- Continuous AML monitoring tied to a person, not a session
- GDPR right-to-deletion across all sessions for an identity
Environments
Verifa provides two fully isolated environments:
Sandbox sessions return simulated results that you can control through the capture UI or API. API keys, webhooks, and workflows are scoped to their environment — sandbox data never mixes with production.
Security model
- Encryption at rest — All PII and documents are encrypted with AES-256-GCM using per-session encryption contexts.
- Encryption in transit — All API communication requires TLS 1.2+.
- HMAC-signed URLs — Document image URLs are time-limited and cryptographically signed.
- Audit logging — Every API call and admin action is recorded in a tamper-evident, hash-chained audit log.
- RBAC — Fine-grained role-based access control for dashboard users and API key scopes.
Next steps
- Quickstart — Create your first session in 5 minutes
- Choosing an Integration Method — Pick the right approach for your use case
- Sessions — Deep dive into the session lifecycle
Related
- Workflows — Define and customize verification pipelines
- Webhooks Guide — Real-time event notifications
- Fraud Signals — Risk scoring and signal details