Skip to main content
Didit, 신원·사기 방지 인프라 구축 위해 750만 달러 투자 유치
Didit
신원 인프라

신원사기 방지를 위한
인프라

하나의 오픈 API로 사용자, 비즈니스, 거래 전반에 걸쳐 모든 신원 및 사기 방지 흐름을 통합하세요. 5분 만에 배포하거나, 코딩 에이전트로 한 번의 프롬프트로 해결하세요.

지원
Y CombinatorRobinhood Ventures
  1. 워크플로의 시작점
    0

    시작

  2. Step
    1
    신분증 확인$0.15
  3. Step
    2
    비대면 본인 확인$0.10
  4. Step
    3
    AML 심사$0.20
  5. 상태
    세션 승인됨
GBTC Finance
Bondex
Crnogorski Telekom
UCSF Neuroscape
Shiply
Adelantos

전 세계 2,000개 이상의 기관에서 신뢰합니다.

하나의 플랫폼. 인증. 확인. 모니터링.

단일 API로 신원 및 사기 방지 워크플로우를 구축, 배포, 모니터링하세요. 생체 인증부터 실시간 거래 모니터링까지, 미리 구축된 모듈을 사용하거나 직접 구성할 수 있습니다.
인증

사용자가 실제 본인이며 현재 접속 중인지 확인합니다. 생체 인증, 패시브 라이브니스, 연령 추정, IP 및 기기 정보, 그리고 단계별 인증을 위한 전화 및 이메일 OTP(일회성 비밀번호)를 제공합니다.

본인 확인

모든 개인 및 기업을 위한 일회성 KYC(고객 알기), KYB(사업체 알기), AML(자금세탁 방지) 및 문서 확인. 220개 이상의 국가, 14,000개 이상의 문서, 10,000개 이상의 AML 데이터셋, 1,000개 이상의 정부 및 기관 데이터 소스를 지원합니다.

모니터링

실시간 거래 모니터링, 지속적인 AML, 암호화폐 지갑 스크리닝을 제공합니다. AI가 패턴 변화에 따라 규칙과 워크플로우를 조정합니다. 온보딩 이후에도 끊임없이 리스크를 관리합니다.

개발자를 위해 · AI 에이전트를 위해 · 개방형 설계

개발자와 AI 에이전트를 위해 구축되었습니다.

신원 및 사기 방지를 위한 단일 API(Application Programming Interface). 공개 문서, 공개 가격, 즉시 사용 가능한 샌드박스, MCP(Model Context Protocol) 서버, 모든 스택을 위한 SDK(Software Development Kits)를 제공합니다. 개발자는 하루 만에 배포하고, AI 에이전트는 MCP를 통해 단 한 번의 프롬프트로 배포합니다.
01 · 하나의 API

신원 및 사기 방지를 위한 하나의 API.

하나의 Application Programming Interface (API)로 모든 신원 및 사기 확인(Know Your Customer (KYC), Know Your Business (KYB), Anti-Money Laundering (AML), 거래 모니터링, 생체 인식 매칭)을 처리합니다. 동일한 키, 동일한 워크플로우 엔진을 사용하며, 단일 세션에서 연결 가능하여 제품 간 추가 통합 작업이 필요 없습니다.
API 문서 읽기
POSThttps://verification.didit.me/v3/session/
curl
$ curl -X POST /v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "3daf4c64-...",
    "vendor_data": "u_42",
    "callback": "https://acme.com/webhook"
  }'
201생성됨
{ "session_id": "4c5c7f3a-...", "url": "verify.didit.me/..." }
02 · 에이전트 네이티브

단일 프롬프트로 통합하세요.

저희 Model Context Protocol (MCP) 서버는 라이브 상태이며 에이전트 스킬이 게시되어 있습니다. Claude Code, Codex 또는 Cursor에게 Didit 통합을 요청하면, 에이전트가 워크스페이스를 생성하고 워크플로우를 구성하며 첫 API 호출을 자체적으로 배포합니다. 대시보드, 사람의 개입, 지원 티켓이 필요 없습니다.
통합 프롬프트 읽기
promptdidit-integration.md
# Integrate Didit into my application

You are integrating Didit — infrastructure for identity and fraud — into my application end-to-end. Didit ships KYC, KYB, AML screening, biometric verification, transaction monitoring, and wallet screening behind one API. 220+ countries, 14,000+ document types, 48+ languages. Pay-per-call from $0.33, 500 free verifications per core feature per month, no minimums, no contract.

## My application context

<my_stack>
Stack: [framework + language — e.g. Next.js 15 + TypeScript, Django, Rails, Go]
Surface: [web | iOS | Android | React Native | Flutter | backend-only]
Use case: [KYC at signup | KYB at business onboarding | age gate | re-auth | transaction monitoring | other]
Database: [Postgres | MySQL | Mongo | other]
</my_stack>

## Step 1 — Create the Didit account programmatically

Two API calls. No browser. No 2FA. Returns an `api_key` you use for every subsequent request.

```bash
# 1) Register — creates org + app + emails a 6-character code
curl -X POST https://apx.didit.me/auth/v2/programmatic/register/   -H "Content-Type: application/json"   -d '{"email": "dev@example.com", "password": "StrongP@ss1"}'

# 2) Verify email with the code from the inbox — returns api_key
curl -X POST https://apx.didit.me/auth/v2/programmatic/verify-email/   -H "Content-Type: application/json"   -d '{"email": "dev@example.com", "code": "A3K9F2"}'
# Response.application.api_key — save this
```

Persist the returned `api_key` as the env var `DIDIT_API_KEY`. Auth header for every Didit call:
`x-api-key: $DIDIT_API_KEY`

## Base URLs

| Surface | Base URL |
|---|---|
| Every `/v3/...` endpoint (sessions, workflows, lists, billing, webhook destinations, entities, transactions, standalone APIs) | `https://verification.didit.me` |
| Auth / programmatic registration (`/auth/v2/programmatic/...`) | `https://apx.didit.me` |
| Console (human UI) | `https://business.didit.me` |
| Hosted verification URL handed to end users | `https://verify.didit.me` |
| Docs (cross-check anything) | `https://docs.didit.me` |
| OpenAPI spec (machine-readable, server is `https://verification.didit.me`) | `https://docs.didit.me/openapi-25.json` |

## Step 2 — Choose the integration approach

Pick exactly one, based on my use case:

- **Approach A — Sessions API + SDK (recommended for any end-user verification flow).** My backend creates a Didit session → my frontend opens the Didit-hosted verification UI (via SDK / iframe / redirect) → user completes verification → my backend receives a webhook with the decision. Best for KYC at signup, KYB at business onboarding, age verification, re-auth. Didit-hosted flows are A/B-tested and convert higher than custom UIs.
- **Approach B — Standalone APIs (server-to-server only).** My backend calls individual modules directly (`/v3/id-verification/`, `/v3/aml/`, `/v3/face-match/`, etc.) for batch jobs or fully custom UI. Best for back-office verification pipelines.

If unsure, default to Approach A.

## Step 3 — Create or reuse a workflow

A workflow defines which modules run during a session. Create one via API (or `https://business.didit.me` → Workflows → Create).

```bash
# List existing workflows
curl https://verification.didit.me/v3/workflows/   -H "x-api-key: $DIDIT_API_KEY"

# Create a new KYC workflow — features are UPPERCASE enum values, each an object with optional `config`
curl -X POST https://verification.didit.me/v3/workflows/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "workflow_label": "Standard KYC",
    "features": [
      { "feature": "OCR" },
      { "feature": "LIVENESS", "config": { "face_liveness_method": "PASSIVE" } },
      { "feature": "FACE_MATCH" },
      { "feature": "IP_ANALYSIS" }
    ]
  }'
# Response.uuid — save as DIDIT_WORKFLOW_ID
```

Feature enum values (UPPERCASE, source: `management-api/workflows/feature-configs.mdx`):
- **KYC features:** `OCR`, `NFC`, `LIVENESS`, `FACE_MATCH`, `AGE_ESTIMATION`, `PHONE_VERIFICATION`, `EMAIL_VERIFICATION`, `DATABASE_VALIDATION`, `AML`, `IP_ANALYSIS`, `PROOF_OF_ADDRESS`, `QUESTIONNAIRE`.
- **KYB features:** `KYB_REGISTRY`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE` (each plus AML / DATABASE_VALIDATION as needed).

For a KYB workflow set `"workflow_type": "kyb"` (default is KYC). A workflow is locked to its type at creation; create separate workflows per kind.

## Step 4 — Install the SDK that matches my stack

| Stack | Package | Install |
|---|---|---|
| Web (React, Vue, Next.js, Nuxt, Svelte, vanilla JS) | `@didit-protocol/sdk-web` | `npm install @didit-protocol/sdk-web` |
| iOS (Swift / SwiftUI) | `didit-sdk-ios` | SPM: `https://github.com/didit-protocol/didit-sdk-ios` |
| Android (Kotlin / Jetpack Compose) | `me.didit:didit-sdk` | Maven |
| React Native (Expo or bare) | `@didit-protocol/sdk-react-native` | `npm install @didit-protocol/sdk-react-native` |
| Flutter | `didit_sdk` | `flutter pub add didit_sdk` |
| Backend-only / batch / custom UI | none — call REST directly | — |

Always prefer native iOS / Android SDKs over WebView on mobile (NFC + camera + biometrics work natively).

## Step 5 — Create a session and present it to the user

**Backend creates the session:**

```bash
curl -X POST https://verification.didit.me/v3/session/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "workflow_id": "'"$DIDIT_WORKFLOW_ID"'",
    "vendor_data": "internal-user-id",
    "callback": "https://myapp.com/done"
  }'
```

Response (201 Created):
```json
{
  "session_id": "4c5c7f3a-...",
  "session_token": "eyJ...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "session_kind": "user",
  "workflow_id": "...",
  "vendor_data": "internal-user-id"
}
```

`vendor_data` is **my internal user ID** — Didit links the session to a User entity (auto-created if new). For KYB workflows it links to a Business entity.

Optional create-session field: `callback_method` (`"initiator"` | `"completer"` | `"both"`, default `"initiator"`) — controls which side of a cross-device flow receives the `callback` redirect. Useful when the verification opens on a phone after a desktop start.

**Frontend presents the verification (pick one):**

| Pattern | Code |
|---|---|
| Web JS SDK (modal) | `import { DiditSdk } from "@didit-protocol/sdk-web"; DiditSdk.shared.startVerification({ url })` |
| Iframe (embedded) | `<iframe src={url} allow="camera; microphone; fullscreen; autoplay; encrypted-media" />` |
| Redirect (cross-device) | `window.location.href = url` |
| iOS / Android / RN / Flutter | `DiditSdk.startVerification(token: session_token)` |

## Step 6 — Set up the webhook to receive results

Build `POST /api/webhooks/didit` in my backend.

**Register the webhook destination once:**

```bash
curl -X POST https://verification.didit.me/v3/webhook/destinations/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "url": "https://myapp.com/api/webhooks/didit",
    "label": "production",
    "subscribed_events": ["status.updated", "data.updated"]
  }'
```

Response includes `secret_shared_key` — save as `DIDIT_WEBHOOK_SECRET`.

**Cloudflare / restrictive firewall users:** allowlist `18.203.201.92` — Didit webhooks egress from this single IP.

**Three signature headers** ship on every webhook. Verify **one** — `X-Signature-V2` is recommended because it survives JSON middleware re-encoding:

| Header | What it signs | When to use |
|---|---|---|
| `X-Signature-V2` ★ recommended | `JSON.stringify(sortKeys(shortenFloats(parsed_body)))` with unescaped Unicode | Default — works through Express / Django / FastAPI / Next.js body parsers |
| `X-Signature` | The raw request bytes verbatim | Only if you can guarantee no middleware re-encodes the body |
| `X-Signature-Simple` | `"{timestamp}:{session_id}:{status}:{webhook_type}"` | Fallback when nothing else works — does NOT verify the `decision` payload, so only use as a hint |

**Endpoint requirements (in order):**

1. Parse JSON (V2 is parser-tolerant; you can use any framework's default body parser).
2. Read headers: `X-Signature-V2` (HMAC-SHA256 hex), `X-Timestamp` (Unix seconds).
3. Reject if `abs(now - X-Timestamp) > 300` (replay protection).
4. Apply `shortenFloats` (whole-number floats → integers), then `sortKeys` (recursive lexicographic), then `JSON.stringify` (unescaped Unicode — default).
5. Compute `expected = HMAC-SHA256(DIDIT_WEBHOOK_SECRET, canonical_json, "utf8")`.
6. Compare with `X-Signature-V2` using constant-time comparison (`hmac.compare_digest` in Python, `crypto.timingSafeEqual` in Node).
7. Dispatch on `webhook_type`. Return `200` immediately even if processing is async — Didit retries 5xx/404 twice (~1 min, ~4 min).

**Node.js / Next.js App Router example (canonical V2):**

```ts
import crypto from "node:crypto";

// Server-side normalisation: convert whole-number floats to integers.
function shortenFloats(v: unknown): unknown {
  if (Array.isArray(v)) return v.map(shortenFloats);
  if (v && typeof v === "object") {
    return Object.fromEntries(
      Object.entries(v as Record<string, unknown>).map(([k, x]) => [k, shortenFloats(x)])
    );
  }
  if (typeof v === "number" && !Number.isInteger(v) && v % 1 === 0) return Math.trunc(v);
  return v;
}

// Recursively sort object keys (arrays preserved in order).
function sortKeys(v: unknown): unknown {
  if (Array.isArray(v)) return v.map(sortKeys);
  if (v && typeof v === "object") {
    return Object.keys(v as object)
      .sort()
      .reduce<Record<string, unknown>>((acc, k) => {
        acc[k] = sortKeys((v as Record<string, unknown>)[k]);
        return acc;
      }, {});
  }
  return v;
}

export async function POST(req: Request) {
  const raw = await req.text();
  const sig = req.headers.get("x-signature-v2") ?? "";
  const ts = Number(req.headers.get("x-timestamp"));
  if (!ts || Math.abs(Date.now() / 1000 - ts) > 300)
    return new Response("stale", { status: 401 });

  const parsed = JSON.parse(raw);
  const canonical = JSON.stringify(sortKeys(shortenFloats(parsed)));
  const expected = crypto
    .createHmac("sha256", process.env.DIDIT_WEBHOOK_SECRET!)
    .update(canonical, "utf8")
    .digest("hex");
  if (
    sig.length !== expected.length ||
    !crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(sig))
  )
    return new Response("bad sig", { status: 401 });

  // parsed.webhook_type → dispatch …
  return new Response("ok");
}
```

**Webhook event types:** `status.updated`, `data.updated`, `user.status.updated`, `user.data.updated`, `business.status.updated`, `business.data.updated`, `activity.created`, `transaction.created`, `transaction.status.updated`.

**Webhook body shape:**
```json
{
  "session_id": "uuid",
  "status": "Not Started | In Progress | Awaiting User | In Review | Approved | Declined | Resubmitted | Abandoned | Expired | Kyc Expired",
  "webhook_type": "status.updated",
  "timestamp": 1627680000,
  "workflow_id": "uuid",
  "vendor_data": "internal-user-id",
  "metadata": { "any": "json" },
  "decision": { /* present when Approved / Declined / In Review; absent on Expired / Abandoned / Not Started */ }
}
```

The `decision` object holds per-module **plural arrays** (V3 schema — each entry keyed by its `node_id` in the workflow):
- `id_verifications[]`: first_name, last_name, document_type, document_number, date_of_birth, nationality, expiration_date, issuing_state, address, parsed_address, mrz, front_image_quality_score, back_image_quality_score, warnings[]
- `nfc_verifications[]`: status, document_type, mrz, signature_status, chip_data
- `liveness_checks[]`: status, score (0–1), method ("passive" | "active"), reference_image
- `face_matches[]`: status, score (0–100), source_image, target_image, warnings[]
- `phone_verifications[]`: status, phone_number, carrier, is_disposable, is_virtual
- `email_verifications[]`: status, email, is_breached, is_disposable, is_undeliverable, breaches[]
- `poa_verifications[]`: status, document_type, issuer, poa_address, poa_parsed_address, issue_date, expiration_date
- `aml_screenings[]`: status, total_hits, hits[] (pep_matches, sanction_matches, warning_matches, adverse_media_matches), entity_type ("person" | "company")
- `ip_analyses[]`: status, ip_address, country, vpn, proxy, tor, hosting, risk_score
- `database_validations[]`: status, provider, match_type, fields_matched
- `questionnaire_responses`: nullable object keyed by question_id → answer

V2 → V3 migration note: V2 used singular keys (`aml`, `phone`, `email`, `poa`). V3 renamed them to plural arrays so a single workflow can run the same module multiple times on different nodes — index by `node_id`.

## Step 7 — Apply the decision to my database

```ts
switch (event.status) {
  case "Approved":       user.verified = true; user.verifiedAt = new Date(); storeDecision(event.decision); break;
  case "Declined":       user.verificationStatus = "declined"; logWarnings(event.decision); break;
  case "In Review":      user.verificationStatus = "pending_review"; break;
  case "In Progress":    user.verificationStatus = "in_progress"; break;
  case "Awaiting User":  user.verificationStatus = "awaiting_user"; break; // KYB only — waiting for a UBO / officer KYC sub-session
  case "Resubmitted":    user.verificationStatus = "resubmitted"; break; // reviewer asked the user to retry
  case "Abandoned":      scheduleReminderEmail(user); break;
  case "Expired":        break; // session URL aged out before the user finished
  case "Kyc Expired":    user.verified = false; createNewSession(user); break; // verified user's KYC has aged out per retention policy
  case "Not Started":    break;
}
```

Idempotency:
- Session webhooks: dedupe on `session_id + webhook_type + timestamp`.
- Transaction webhooks (`transaction.created`, `transaction.status.updated`): dedupe on the `event_id` field — multiple events can target the same transaction.

Didit retries 5xx/404 twice (~1 min, ~4 min after the prior failure). Return 200 even if processing is async.

## Module catalogue (use whichever ones match my use case)

| Module | Endpoint | Price | Free tier |
|---|---|---|---|
| Core KYC bundle (ID + Liveness + Face Match + IP) | session w/ workflow | **$0.33** | 500/mo (per feature) |
| ID Verification (standalone) | `POST /v3/id-verification/` | $0.20 | 500/mo |
| Passive Liveness (standalone) | `POST /v3/passive-liveness/` | $0.05 | 500/mo |
| Active Liveness | session-only | $0.15 | — |
| Face Match 1:1 | `POST /v3/face-match/` | $0.05 | 500/mo |
| Face Search 1:N | `POST /v3/face-search/` | $0.05 | — |
| Age Estimation | `POST /v3/age-estimation/` | $0.10 | — |
| AML Screening | `POST /v3/aml/` | $0.20 | — |
| Ongoing AML Monitoring | org-level continuous (per active user/yr) | $0.07 / user / year | — |
| Database Validation (gov registries) | `POST /v3/database-validation/` | variable | — |
| Proof of Address | `POST /v3/poa/` | $0.20 | — |
| Email Verification | `POST /v3/email/send/` + `POST /v3/email/check/` | $0.03 | — |
| Phone Verification (SMS / WhatsApp / voice / RCS / Telegram) | `POST /v3/phone/send/` + `POST /v3/phone/check/` | $0.04 + carrier | — |
| NFC Verification (native SDKs only) | session module | $0.15 | — |
| Biometric Authentication (re-auth) | session module | $0.10 | — |
| Device & IP Analysis | session module | $0.03 | — |
| Custom Questionnaire | session module | $0.10 | — |
| Business Verification (KYB) | `POST /v3/session/` w/ KYB workflow | $2.00 | — |
| Company AML Screening | KYB module | $0.20 | — |
| Person AML (per UBO / officer) | KYB module | $0.20 | — |
| Transaction Screening (rule engine) | `POST /v3/transactions/` | $0.02 / tx | — |
| AML Transaction Screening (counterparty sanctions + on-chain wallet risk) | inside `/v3/transactions/` | $0.15 / tx | — |
| Reusable KYC (share verified user across partners) | session feature | Free | — |
| White Label | workflow option | $0.20 | — |

## Operational APIs your code should know

| Action | Endpoint |
|---|---|
| Read full decision JSON | `GET /v3/session/{id}/decision/` |
| List sessions (filter by status, workflow, vendor_data, date) | `GET /v3/sessions` |
| Manually approve / decline / request review | `PATCH /v3/session/{id}/update-status/` |
| Patch metadata or extracted data | `PATCH /v3/session/{id}/update-data/` |
| Download compliance PDF | `GET /v3/session/{id}/generate-pdf` |
| Delete a session (GDPR / cleanup) | `DELETE /v3/session/{id}/delete/` |
| Share session with a partner (Reusable KYC) | `POST /v3/session/{id}/share/` |
| Submit a transaction for monitoring | `POST /v3/transactions/` |
| List / create lists (blocklist, allowlist, custom) | `GET/POST /v3/lists/` |
| Add entry to a list | `POST /v3/lists/{id}/entries/` |
| Upload a face image to a blocklist | `POST /v3/lists/{id}/entries/face-upload/` |
| Check credit balance | `GET /v3/billing/balance/` |
| Top up credits (returns Stripe checkout URL) | `POST /v3/billing/top-up/` |
| List / update / delete vendor users | `GET/PATCH /v3/users/`, `/v3/users/{vendor_data}/` |
| List / update / delete vendor businesses | `GET/PATCH /v3/businesses/` |

Every `/v3/...` endpoint above is served from `https://verification.didit.me` (the canonical OpenAPI server) and authenticates with `x-api-key`. Auth/registration is the only surface on `https://apx.didit.me`.

## Best-practice checklist before you mark this done

- [ ] `DIDIT_API_KEY`, `DIDIT_WORKFLOW_ID`, `DIDIT_WEBHOOK_SECRET` in env. Never committed.
- [ ] Backend route that creates a session for a given user, returns `url` (the hosted verification URL on `verify.didit.me`) and the `session_id`.
- [ ] Frontend that opens the session `url` via the right SDK / iframe / redirect for my stack.
- [ ] Webhook endpoint with: `X-Timestamp` freshness check (≤ 300s), canonical-V2 JSON re-serialisation (`shortenFloats` → `sortKeys` → unescaped `JSON.stringify`) HMAC-SHA256, constant-time compare against `X-Signature-V2`, dispatch on `webhook_type`, return 200.
- [ ] DB schema + update logic for `status in (Not Started, In Progress, Awaiting User, In Review, Approved, Declined, Resubmitted, Abandoned, Expired, Kyc Expired)`.
- [ ] Idempotent webhook handler (dedupe on `session_id + webhook_type`).
- [ ] No API key shipped to the browser. The session creation is server-side only.
- [ ] User-facing consent / disclosure shown BEFORE the session `url` opens (Didit handles biometric consent inside its flow but the legal layer outside is the integrator's responsibility).
- [ ] (Optional) `/v3/session/{id}/generate-pdf` surfaced in compliance UI.

## When you need more detail

- API root: `https://verification.didit.me/v3/` (everything `/v3/`). Auth only: `https://apx.didit.me/auth/v2/programmatic/register/`.
- Sessions overview: `https://docs.didit.me/sessions-api/overview`
- Standalone APIs index: `https://docs.didit.me/standalone-apis/id-verification`
- Programmatic registration: `https://docs.didit.me/integration/programmatic-registration`
- AI agent / MCP integration: `https://docs.didit.me/integration/ai-agent-integration`
- Webhooks reference: `https://docs.didit.me/integration/webhooks`
- SDKs overview: `https://docs.didit.me/integration/sdks`
- Full OpenAPI 3 spec: `https://docs.didit.me/openapi-25.json`
- MCP server config (drop into `.cursor/mcp.json`, `claude_desktop_config.json`, or equivalent):

```json
{
  "mcpServers": {
    "didit": {
      "command": "npx",
      "args": ["@didit-protocol/mcp-server"],
      "env": { "DIDIT_API_KEY": "your_api_key" }
    }
  }
}
```

The MCP server exposes 40+ tools spanning auth, sessions, workflows, questionnaires, users, billing, blocklist, and every standalone API — see `https://docs.didit.me/integration/ai-agent-integration` for the full tool catalogue.

Now build the integration. If anything in `## My application context` is missing, ask once at the top of your reply, then ship the complete change set: env vars wired, backend route, frontend SDK call, webhook endpoint with signature verification, decision-handling DB logic, and idempotent dedupe. Use my stack's idioms (`fetch` / `axios` / `requests` / `okhttp`), keep the API key server-side only, and follow the verification status state machine above.
Claude Code, Codex 또는 Cursor에 붙여넣기 · 완벽한 통합 제공
03 · 모듈형

어떤 플로우든. 어떤 국가든. 어떤 사용 사례든.

25개 이상의 모듈, 1,000개 이상의 정부 데이터 소스, 220개 이상의 국가, 14,000개 이상의 문서 유형, 48개 이상의 언어로 어떤 플로우든 구성할 수 있습니다. 동일한 오케스트레이터가 생체 인증, 네오뱅크를 위한 KYC, B2B 핀테크를 위한 KYB, 암호화폐 거래소를 위한 Travel Rule, 또는 마켓플레이스를 위한 지속적인 AML을 실행합니다. 필요한 검사와 순서를 직접 선택하세요.
모든 모듈 보기
워크플로우kyc-onboarding-v3
220개 이상 국가
  • ID Verification
  • Passive Liveness
  • Face Match 1:1
  • AML Screening
  • Device & IP Analysis
  • 주소 증명
  • NFC 리딩
  • 전화번호 인증
  • 지갑 심사
  • 맞춤형 설문지
+ 15개 모듈 · 1,000개 이상의 데이터 소스세션당 $0.33
04 · 셀프 서비스

유료 결제도, 영업 전화도 없습니다. 직접 사용해 보세요.

샌드박스는 즉시 이용 가능합니다. 문서와 API는 공개되어 있으며, 코드에 접근하는 데 데모 장벽이 없습니다. 가입하고, 키를 받아 당일 바로 배포하세요. 영업팀은 필요할 때 언제든 도와드리며, 결코 방해가 되지 않습니다.
샌드박스 사용해 보기
프로덕션 API 키
라이브
didit_sk_live_8f4c2a…9bf3

지금 바로 발급, 카드, 계약, 통화 필요 없음.

  • 최소 사용량 없음
  • 계약 없음
  • 월 500회 무료
  • 오픈 샌드박스
05 · 사용량 기반

사용한 만큼만 지불하세요. 그게 전부입니다.

Didit은 기존 KYC 공급업체보다 3~5배 저렴하며, 모든 가격은 /pricing에 공개되어 있습니다. 전체 KYC 번들 $0.33, 지갑 스크리닝 $0.15, 기기 및 IP 분석 $0.03, 매월 500건의 무료 인증을 제공합니다. 최소 사용량, 연간 계약, 초과 요금에 대한 걱정 없이, 페이지에 명시된 가격이 청구서의 가격입니다.
모든 가격 보기
공개 가격표
/pricing
  • ID Verification$0.15
  • Passive Liveness$0.10
  • Face Match 1:1$0.05
  • AML Screening$0.20
  • Device & IP Analysis$0.03
  • 지갑 스크리닝 (KYT)$0.15
풀 KYC 번들$0.33

월 500회 무료 · 최소 사용량 없음 · 연간 계약 없음.

06 · 개방형 인프라

개방형 API. 그 위에 구축하세요.

모든 엔드포인트는 개방되어 있으며 문서화되어 있습니다. 세션 상태 변경, 얼굴 블랙리스트 추가, 결정 PDF 다운로드, 워크플로우 편집, 이벤트 로그 쿼리 등이 가능합니다. 웹훅은 HMAC(Hash-based Message Authentication Code)로 서명되어 모든 이벤트가 Didit에서 발생했음을 증명할 수 있습니다. Didit은 폐쇄형 앱이 아닌 인프라입니다.
API 살펴보기
REST · OpenAPI 3
docs.didit.me
  • POST/v3/session/
  • GET/v3/session/{id}/decision/
  • PATCH/v3/session/{id}/update-status/
  • GET/v3/session/{id}/generate-pdf
  • POST/v3/lists/{id}/entries/face-upload/
  • POST/v3/transactions/

모든 엔드포인트 개방 · 모든 웹훅 HMAC 서명.

07 · SDK

모든 플랫폼을 위한 SDK.

Web, iOS, Android, React Native, Flutter 등 모든 스택을 위한 SDK를 제공합니다. 백엔드에는 REST API, 서명된 웹훅, OpenAPI 3 스펙, 그리고 Zapier, Shopify, Salesforce 통합이 준비되어 있습니다. 모든 인터페이스에는 샘플, 타입, 5분 만에 시작할 수 있는 가이드가 함께 제공됩니다.
SDK 살펴보기
Webv1.4.0iOSv3.0.1Androidv2.6.2
React Nativev1.8.0Flutterv1.3.4
08 · 확장 최적화 인프라

시장 내 가장 빠른 인증 속도.

전체 인증의 99%가 2초 이내에 완료됩니다. 이는 실제 운영 환경에서 측정된 수치이며, 단순히 주장하는 것이 아닙니다. 99.99%의 SLA(Service-Level Agreement)를 목표로 하며, 지난 12개월 동안 100% 가동 시간을 유지했고, 단 한 번도 침해된 적이 없습니다. iPhone, Android, 데스크톱, 태블릿, 5G 또는 2G 등 모든 기기와 네트워크에 최적화되어 있으며, 이미 매월 수백만 건의 인증을 처리하고 있습니다.
실시간 상태 보기
종단 간 지연 시간 · 30일
99.99% SLA
  • p500.82s
  • p951.42s
  • p991.89s

시장 내 가장 빠른 본인 인증 · iPhone, Android, 데스크톱, 태블릿, 5G 또는 2G.

설계부터 규정 준수

클릭 한 번으로 새로운 국가에 진출하세요. 어려운 일은 저희가 처리합니다.

저희는 현지 자회사를 설립하고, 라이선스를 확보하며, 침투 테스트를 실행하고, 인증을 획득하며, 모든 새로운 규정을 준수합니다. 새로운 국가에서 인증을 배포하려면 토글만 켜면 됩니다. 220개 이상의 국가에서 서비스 중이며, 매 분기마다 감사 및 침투 테스트를 거칩니다. EU 회원국 정부가 대면 인증보다 더 안전하다고 공식적으로 인정한 유일한 신원 확인 제공업체입니다.
보안 및 규정 준수 문서 읽기
EU 금융 샌드박스
Tesoro · SEPBLAC · BdE
ISO/IEC 27001
정보 보안 · 2026
SOC 2 · Type I
AICPA · 2026
iBeta Level 1 PAD
NIST / NIAP · 2026
GDPR
EU 2016/679
DORA
EU 2022/2554
MiCA
EU 2023/1114
AMLD6 · eIDAS 2.0
설계부터 EU 규정 준수

수치로 증명합니다

신뢰할 수 있는 인프라
  • 0%
    지난 12개월간의 가동 시간, SLO 측정 기준.
  • 0
    서비스 시작 이후 침해 사고 0건. 유출된 자격 증명 0건.
  • 수백만
    매월 본인 확인된 사용자 수.
  • 0+
    기본으로 지원되는 국가 및 지역.
세 가지 티어, 하나의 가격표

무료로 시작하고, 사용량에 따라 지불하며, 엔터프라이즈로 확장하세요.

매월 500건의 무료 본인 확인을 영구적으로 제공합니다. 프로덕션 환경에서는 사용한 만큼만 지불하세요. 엔터프라이즈 고객에게는 맞춤형 계약, 데이터 상주 및 SLA(서비스 수준 협약)를 제공합니다.
무료

무료

월 $0. 신용카드 정보가 필요 없습니다.

  • 무료 KYC 번들 (신분증 확인 + 패시브 라이브니스 + 얼굴 매칭 + 기기 및 IP 분석), 매월 500건 제공
  • 차단된 사용자
  • 중복 감지
  • 모든 세션에서 200개 이상의 사기 신호 감지
  • Didit 네트워크 전반에 걸쳐 재사용 가능한 KYC
  • 사례 관리 플랫폼
  • 워크플로 빌더
  • 공개 문서, 샌드박스, SDK, MCP(Model Context Protocol) 서버
  • 커뮤니티 지원
가장 인기
사용한 만큼 지불

사용량 기반 요금제

사용한 만큼만 지불하세요. 25개 이상의 모듈. 모듈별 공개 가격, 월 최소 요금 없음.

  • 전체 KYC $0.33 (신분증 + 생체 인식 + IP / 기기)
  • 10,000개 이상의 AML 데이터셋, 제재, PEP, 부정적 미디어
  • 데이터베이스 검증을 위한 1,000개 이상의 정부 데이터 소스
  • 거래당 $0.02의 거래 모니터링
  • 기업당 $2.00의 실시간 KYB
  • 검사당 $0.15의 지갑 스크리닝
  • 화이트 라벨 검증 플로우, 귀사의 브랜드, Didit의 인프라
엔터프라이즈

엔터프라이즈

맞춤형 MSA 및 SLA. 대규모 볼륨 및 규제 프로그램에 적합합니다.

  • 연간 계약
  • 맞춤형 MSA, DPA, SLA
  • 전용 Slack 및 WhatsApp 채널
  • 주문형 수동 검토자
  • 리셀러 및 화이트 라벨 조건
  • 독점 기능 및 파트너 통합
  • 전담 CSM, 보안 검토, 규정 준수 지원

무료로 시작 → 확인 실행 시에만 지불 → 맞춤형 계약, SLA 또는 데이터 상주를 위해 엔터프라이즈 잠금 해제.

FAQ

자주 묻는 질문

알레한드로 로사스(왼쪽)와 알베르토 로사스(오른쪽), Didit 공동 창업자
“AI는 AI를 위해 구축되지 않은 모든 신원 확인 시스템을 무너뜨리고 있습니다. 다음 10년의 신뢰를 위해서는 개방적이고 프로그래밍 가능하며 공개적으로 가격이 책정되는 인프라 계층이 필요합니다. 이것이 바로 우리가 Didit을 설립한 이유입니다.”
알베르토 로사스Didit 공동 창업자 겸 CEO

신원 및 사기 방지 인프라.

KYC, KYB, 거래 모니터링, 지갑 심사를 위한 단일 API. 5분 만에 통합하세요.

AI에게 이 페이지 요약 요청