> For the complete documentation index, see [llms.txt](https://docs.vida.id/identity-stack/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vida.id/identity-stack/verify/kyc-web-sdk/getting-started/use-cases.md).

# Use Cases

## Recommended Use Cases for the Vida Web SDK

Vida KYC Web SDK is optimized for **fast, high-conversion identity verification** in browser environments.

This page explains **when the KYC Web SDK is the preferred choice** compared to API-only or native SDK integrations, and gives examples of typical use cases.

***

### When the Web SDK is a Good Fit

Use the Web SDK when you:

* ✅ Want a **ready-made verification UI** (no need to design every screen yourself)
* ✅ Need a **consistent experience** across desktop, mobile browser, and webview
* ✅ Want to **minimize integration effort** (just initialize the SDK with a token)
* ✅ Need to **reduce compliance risk** by leveraging Vida’s guided UX and guardrails
* ✅ Prefer to keep **sensitive image handling** inside SDK flows instead of building your own

> In short: if you want to go live quickly with a clean, standardized KYC flow on web, the Web SDK is usually the best option.

***

### Typical Use Cases

#### 1. New Customer Onboarding (Account Opening)

Use the Web SDK when:

* Users sign up on your **website** or in a **mobile webview**
* You need to collect and verify:
  * Government-issued ID (front & back where applicable)
  * Selfie with liveness
  * Face match between selfie and document photo

Common scenarios:

* Digital bank / e-money account opening
* Securities & crypto exchange registration
* Wallet or super-app KYC (tiered limits)

Recommended:

* Enable both **document verification** and **liveness + face match**
* Keep tutorials enabled for first-time users
* Log `transactionId` + `partnerTransactionId` to your backend for audit

***

#### 2. Limit Increases & High-Risk Actions (Step-Up Verification)

Use the Web SDK for **step-up verification** when:

* Existing users request:
  * Higher transaction limits
  * Access to new products (e.g. margin, loans, card issuance)
  * Sensitive account changes (phone number, address, device change)
* You need additional assurance that:
  * The person behind the request is the **real account owner**
  * Documents are valid and not reused fraudulently

Typical flows:

* “Verify your identity to increase your limit”
* “For your security, please re-verify before changing your phone number”

Recommended:

* Trigger the Web SDK from a **secured, logged-in session**
* Pre-fill `partnerTransactionId` with your internal user ID / request ID
* Consider showing a shorter tutorial if users have verified before

***

#### 3. Merchant / Business Onboarding (B2B2C Platforms)

For platforms that onboard **merchants or drivers** (e.g. marketplace, ride-hailing, delivery, lending):

* Use Web SDK as part of:
  * Merchant onboarding portal (web)
  * Franchisee/agent onboarding flows
  * Driver / courier onboarding that starts in a web-based registration form

What you verify:

* Individual’s ID document (director, owner, or representative)
* Selfie + liveness
* Face match to document

The Web SDK is preferred when:

* Onboarding happens on **web portals** (desktop or mobile web)
* You need a **repeatable, consistent flow** across many partners and locations

***

#### 4. Re-KYC / Periodic KYC Refresh

Regulations or internal policy may require **periodic re-verification** (e.g. every 1–3 years, or when risk signals change).

Use the Web SDK for:

* Scheduled **re-KYC campaigns**
* Targeted **risk-based re-verification** (e.g. unusual behavior, device change)

Why Web SDK works well here:

* You can send users a **link** (email / SMS / in-app) that opens the Web SDK flow
* No need to push app updates or require a specific app version
* Same flow can be reused for new users and re-KYC users, with different messaging handled via `localeConfigs`

***

#### 5. Agent-Assisted / Branch-Light Flows

Where you have **agents, branches, or kiosks** but don’t want heavy desktop software:

* Agents use a **browser-based portal** to start verification
* Customers:
  * Scan their ID and take a selfie using the device camera
  * Or receive a **QR code / link** and complete on their own phone

Web SDK is preferred when:

* You want **lightweight deployment** (just a web app) instead of thick clients
* You need **consistent flows** across many locations, partners, or devices
* Hardware varies (different laptops, tablets, kiosks)

***

### When Web SDK Is Preferred vs. Alternatives

#### Web SDK vs. Pure API Integration

Choose **Web SDK** when:

* You don’t want to build & maintain your own:
  * Camera flows
  * Error states
  * Document & selfie capture UX
* You prefer a **pre-validated UX** aligned with KYC/AML best practices
* You want to minimize the chance that a custom UI introduces mistakes (e.g. incorrect cropping, missing backside capture)

Choose **API-only** when:

* You already have a **strong custom UX** and want full design control
* You’re heavily invested in native-only flows (and call Vida APIs directly from backend)

***

#### Web SDK vs. Native Mobile SDK

Choose **Web SDK** when:

* Your traffic is mainly:
  * Desktop browser
  * Mobile browser
  * In-app **webview** flows
* You want a **single implementation** for both desktop & mobile
* You need to launch quickly without app store releases

Choose **native SDK** when:

* Your product is heavily **mobile app–centric**
* You want the most **device-level control** and deep integration with mobile-specific UX

> In many cases, customers use **both**:
>
> * Web SDK for web + webview flows
> * Native SDK for deep in-app flows

***

If you are unsure whether Web SDK is the best fit for your use case, please contact your Vida representative with:

* Your user journey (web / mobile / branch)
* Target countries and documents
* Expected volumes and risk level