Skip to content
KYCVerify

Marketplaces and gig platforms

Trust on both sides of the marketplace starts with one check.

Sellers, hosts, couriers and drivers verify in a hosted flow on their phone. You get a decision by webhook, and duplicate detection catches a removed account coming back under a new name.

See the workflowTalk to us
Recommended workflowMarketplaces and gig
  1. 1Consent
  2. 2Document
  3. 3Liveness

At submit

  • Face match
  • Duplicate detection
  • AML screening
steps on the phone
3
apps or SDKs to install
0
duplicate scope, or org across apps
app

decision.auto_decline: true · a failed check declines

The problem

What this use case needs from verification.

  • Supply-side fraud

    A seller banned last month can re-register with a new email. The same face or the same document is what gives them away.

  • Mobile-first

    The hosted flow runs in the phone's browser, so there is nothing to install and no SDK to keep up to date.

  • Your brand

    The flow shows your app name and primary colour, and can return the person to your app when they finish.

Recommended workflow

Steps the person sees, checks that decide.

Pass your user id as `vendor_data` so the webhook can be matched to the account without a lookup.

In the hosted flow

  1. 1Consent
  2. 2Document
  3. 3Liveness

At submit

  • Face match
  • Duplicate detection
  • AML screening
  • IP recorded for the audit trail

Keys left out of the config keep their defaults. Paste it into the workflow builder, or read every key on the workflows page.

Workflow config · json
{
  "steps": {
    "document":   { "enabled": true, "reject_expired": true },
    "liveness":   { "enabled": true, "challenges": 3 },
    "face_match": { "enabled": true },
    "duplicate":  { "enabled": true, "face_threshold": 0.55, "scope": "app" },
    "aml":        { "enabled": true }
  },
  "redirect_url": "https://example.com/onboarding/done"
}

Signals

What happens when something is off.

Real cases for this industry, the check that sees each one and what the engine records. Codes are exactly as they appear in the decision.

Signals and outcomes
WhenSeen byOutcome
A banned seller re-registers with a new emailduplicatereviewduplicate_found (face)
The same passport is used for two driver accountsduplicatereviewduplicate_found (document number)
Someone else's ID is held up to the cameraface_matchfailedface_match_failed
The photo is too blurred to readdocumentretakedocument_unreadable
The host's name is close to a listed entryamlreviewaml_potential_match

Checks used

The capabilities behind it.

Each has its own page with an in-browser demo of the rule it applies.

Regulatory context

Where the rules meet the product.

Marketplaces increasingly have to know who sells on them. The rules differ by market; here is how they meet KYCVerify. This is context, not legal advice.

Not legal advice. KYCVerify does not certify compliance with any law or regulator. Confirm how each rule applies to you with your compliance team and counsel.

  • EU Digital Services Act, Article 30

    Online marketplaces must collect and make reasonable efforts to check information about traders, including identification, before letting them sell to consumers in the EU. A verified identity and a decision record support that effort.

  • India: Consumer Protection (E-Commerce) Rules, 2020

    Place duties on marketplace entities about seller information. Map what you must collect to the workflow; KYCVerify verifies identity, not business registration (there is no KYB).

  • Platform workers and their data

    Drivers and couriers are people with privacy rights. Tell them what you verify, keep it only as long as needed with retention_days, and let reviewers, not the machine, act on a duplicate.

What KYCVerify does not settle for you

  • Duplicate detection compares within one app. Use one live app for every market where you want a returning person recognised.

Integrate

One call starts it.

Pass your user id as vendor_data; the webhook carries it back, and duplicate review lists the earlier session it matched.

  1. 1Create the session with this workflow and your own reference.
  2. 2Send the person the url, or open it on a device you control.
  3. 3Act on the signed session.status_updated webhook.
Webhooks and APIQuickstart

Create a session

curl -X POST https://kycverify.me/api/v1/sessions \
  -H "x-api-key: $KYC_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "workflow_id": "wf_0k3t1c8n5e2wpzr6g4ya",
    "vendor_data": "seller-30917",
    "metadata": {
      "market": "in",
      "category": "home-services"
    },
    "expires_in_hours": 168
  }'

201 Created

{
  "session_id": "ses_0k3v9x2m4a7qhd8f1rtb",
  "status": "not_started",
  "url": "https://kycverify.me/verify/q3Xf…",
  "session_token": "q3Xf…",
  "workflow_id": "wf_0k3t1c8n5e2wpzr6g4ya",
  "vendor_data": "seller-30917",
  "expires_at": "2026-10-10T09:12:44Z"
}

FAQ

Questions.

Can we verify without an integration first?

Yes. Reviewers can create verification links in the console and send them by any channel.

More solutions

Other ways teams use KYCVerify.

Build this workflow in the sandbox.

Set up the configuration above in the workflow builder and run a test session in minutes, then talk to us about going live.

Start freeWorkflow docs