Introducing VIDA Identity Stack: All of VIDA, in one place 🎉
Ctrlk
Go to VIDABook a Demo
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

PreviousOverview
NextIdentity Verification Flow

Last updated