Stripe Identity vs Entrust Identity Verification (Onfido)
usage-based
·enterprise-custom
Draw · 12–11 (20 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round drawnStripe's docs.stripe.com serves both an llms.txt (200) and .md variants of Identity docs (200), confirmed via direct probes, letting an agent be pointed at machine-readable docs. Missing for 10: no explicit agent-oriented guidance specific to Identity beyond the generic llms.txt, and no independent community confirmation of agents successfully using it this way.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/identity.md # Identity Verify government-issued IDs, match documents to selfies, and val…”
- [claimed-docs] “Capture government-issued photo IDs with a conversion-optimized verification flow”
An llms.txt file exists at documentation.identity.entrust.com/llms.txt and is directly probed returning HTTP 200 with structured content describing the API/SDK platform, confirming an agent can be pointed at it. Missing for 10: no evidence of broader agent-oriented doc formats (e.g., markdown-only mirrors, sitemap of llms-full.txt) or third-party confirmation that agents successfully consume it.
- [probe] “PROBE llms.txt: HTTP 200 at https://documentation.identity.entrust.com/llms.txt # Entrust Identity Verification Documentation > Entrust Ide…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Stripe IdentityStripe Identity exposes a full REST API (curl examples for creating verification sessions), webhooks for automated result handling, and programmatic access to results, which supports headless/CI-style automation. However, there's no evidence of a dedicated SDK/test-mode designed for CI pipelines, official CI examples, or automated testing harnesses specific to Identity verification flows. missing for 10: CI-specific tooling/examples, automated test-mode documentation for Identity, independent hands-on confirmation of headless CI usage.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
The product exposes a full REST API (create applicant, create workflow run, webhooks, OAuth client-credentials tokens) that could be scripted headlessly in CI, and webhook/polling patterns support automation without UI interaction. However, the primary workflow-building tool is explicitly no-code/drag-and-drop, and there is no evidence of a CLI, SDK for CI pipelines, or documented headless/automation-testing use case. missing for 10: explicit CI/headless automation examples, CLI tooling, documented non-interactive test/staging workflows, and confirmation that Workflow Studio config can be version-controlled or scripted rather than GUI-only.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
ai-native userConnect an agent via an official MCP server
weight 3 · round to Stripe IdentityStripe (the platform Stripe Identity belongs to) has an official documented MCP server that lets AI agents interact with 'the Stripe API,' confirmed by both docs and a probe. However, the evidence never explicitly confirms that Identity-specific verification-session endpoints are exposed as MCP tools, leaving a gap in scope specificity. Missing for 10: explicit documentation or example showing Identity verification-session/session-result operations available as MCP tools, and independent/community confirmation of using the MCP server for Identity use cases.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Entrust Identity Verification (Onfido)none0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userUse an official CLI
weight 2 · round to Stripe IdentityStripe offers an official Stripe CLI documented at docs.stripe.com/stripe-cli, which applies platform-wide including Identity API interactions, though evidence doesn't show Identity-specific CLI commands or AI-native workflow integration beyond the generic CLI listing. missing for 10: Identity-specific CLI usage examples, independent hands-on confirmation of CLI use with Identity endpoints, agentic/AI-native workflow documentation for the CLI.
- [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
Entrust Identity Verification (Onfido)none0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userDrive the product through a documented public API
weight 3 · round to Stripe IdentityStripe Identity exposes a documented REST API (verification_sessions endpoint with curl examples), webhooks for outcomes, programmatic access to verification results, and review/blocklist actions — all usable to fully drive the product without a UI. There's also an official MCP server for AI agents to interact with the Stripe API. Missing for 10: a public OpenAPI/swagger spec was probed and returned 404s, and no independent hands-on report of an AI agent driving the API end-to-end.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Entrust provides a well-documented public API/SDK flow (applicant creation, workflow run, SDK token, webhook or polling for results) plus OAuth client-credentials authentication and webhook signature verification, all confirmed by a live llms.txt probe describing it as 'a comprehensive API and SDK platform'. missing for 10: independent/community corroboration of real-world API integration, and a direct link to a full API reference/OpenAPI spec beyond the docs snippets.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
- [probe] “PROBE llms.txt: HTTP 200 at https://documentation.identity.entrust.com/llms.txt # Entrust Identity Verification Documentation > Entrust Ide…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to Entrust Identity Verification (Onfido)Stripe Identitynone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
The docs show OAuth client-credentials grant for short-lived tokens and separate SDK tokens for capture flows, which provides some credential separation, but there is no explicit mention of scoped/least-privilege roles, permission granularity, or agent-specific credential issuance. missing for 10: explicit least-privilege/scoped role definitions, documentation of granting narrower API scopes per use-case or agent, and any AI-agent-specific credential workflow.
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
ai-native userBuild against official SDKs
weight 2 · round to Entrust Identity Verification (Onfido)Docs show a well-documented REST API (curl examples, programmatic access to verification results, webhooks) and even an official MCP server for AI agents, implying SDK-friendly integration, but no evidence explicitly documents official client SDKs (e.g., Node/Python/Ruby libraries) or their AI/agentic usage patterns. missing for 10: explicit official SDK documentation, language-specific SDK usage examples, and any AI-native tooling built directly on those SDKs beyond the generic MCP server mention.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Evidence confirms official SDKs exist (mobile/web SDKs, SDK tokens, migration guide from Smart Capture SDKs to new IDV SDKs) with documented API/webhook/auth flows, showing developers can build against them. However, there's no evidence of language-specific SDK repos, open-source code samples, versioning/release notes, or independent developer corroboration of build experience. Missing for 10: public SDK repository/language coverage details, code samples, independent developer testimonials, changelog/versioning transparency.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
- [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
- [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnStripe Identity's docs explicitly describe listening for verification results via webhooks/events to trigger automated reactions, and events/webhooks are Stripe's standard integration mechanism supported across products including Identity. Missing for 10: explicit webhook event-type list for Identity, independent hands-on confirmation of webhook reliability/latency, and AI-agent-specific webhook subscription tooling beyond general docs.
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
Docs clearly document configurable webhook events to notify on workflow status changes, including signature verification via HMAC-SHA256, showing a supported webhook subscription mechanism. missing for 10: no documentation of event type granularity/catalog, no independent/hands-on corroboration, and no explicit mention of self-serve webhook management UI or retry/delivery guarantees.
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round drawnStripe Identity supports webhook-driven automation (auto-triggering reactions to verification outcomes, programmatic access, blocklist automation) and Stripe now ships an official MCP server letting AI agents call the API, which together enable background/autonomous workflows. However, evidence doesn't show any AI-native scheduling, agent orchestration, or first-party 'set-and-forget' automation framework specific to Identity beyond webhooks+MCP. Missing for 10: dedicated agent/automation tooling within Identity itself, independent hands-on confirmation of autonomous agent use via MCP for identity verification, and detail on how persistent/background jobs are managed.
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Workflow Studio provides no-code, drag-and-drop automation of verification workflows, and webhooks/polling allow asynchronous, background monitoring of workflow status rather than requiring active user polling — evidence of some autonomous background operation. However, this is workflow automation for identity checks, not an AI-native agentic automation framework (no mention of AI agent orchestration, scheduling, or LLM-driven decisioning). Missing for 10: evidence of AI-agent-specific automation setup, autonomous decision-making beyond fixed verification steps, and integration with agent frameworks.
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
ai-native userOperate the product with natural-language commands
weight 2 · round to Stripe IdentityStripe provides an official MCP server that lets AI agents interact with the Stripe API via natural-language-driven tool calls, which would in principle expose Identity operations (create/verify sessions, review) to an AI agent. However, there is no evidence specifically confirming Identity endpoints are exposed through this MCP server, nor any hands-on or community confirmation of natural-language operation of Identity itself. Missing for 10: explicit documentation that Identity API/actions are covered by the MCP server, and independent/hands-on evidence of an AI agent successfully running Identity verification via natural-language commands.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Entrust Identity Verification (Onfido)none0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to Stripe IdentityDocs include concrete code samples (e.g., curl requests for verification sessions) and structured API reference pages, but there is no evidence of an interactive, runnable API console (probes show openapi.json/swagger.json 404, and no mention of a 'try it' sandbox or live code execution). missing for 10: evidence of an in-browser runnable/interactive API explorer, discoverable OpenAPI spec, or independent confirmation of interactivity.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/identity.md # Identity Verify government-issued IDs, match documents to selfies, and val…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round drawnStripe Identitynone0/10The evidence pack shows an explicit probe for OpenAPI/swagger spec files at standard paths, all returning 404, and no docs page or claim points to a downloadable machine-readable API spec for Identity; only human-readable curl examples and prose docs exist.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round drawnStripe Identitynone0/10No evidence in the pack mentions a sandbox, test mode, or test API keys specific to Stripe Identity that would let a developer verify documents without touching production data. Missing for 10: any documentation of Identity test-mode verification sessions, sandbox test IDs/selfies, or explicit test/live key separation for this product.
Entrust Identity Verification (Onfido)none0/10The evidence pack covers SDK tokens, webhooks, OAuth, and workflow tools but contains no mention of a sandbox/test environment separate from production for API or SDK testing. This is a fair axis for an API/SDK platform, but no evidence supports it.
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round to Entrust Identity Verification (Onfido)Stripe Identitynone0/10Evidence shows API usage (curl examples, secret key access) but no documentation of API versioning scheme or a deprecation policy; the OpenAPI probe returned 404s, and no changelog/versioning docs are cited. Missing for 10: versioning scheme docs, deprecation policy docs, changelog/migration guides.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
The docs reference an 'api/latest' version and a migration guide for moving from Smart Capture SDKs to new IDV SDKs, implying some versioning and change management, but there is no explicit documented deprecation policy, version support timeline, or sunset schedule for APIs. missing for 10: explicit versioned API scheme (e.g., v1/v2 endpoints), a published deprecation/sunset policy, and timelines for backward compatibility.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnStripe Identitynone0/10Evidence shows only per-session API calls (create one verification_session at a time) and no batch/bulk endpoint for processing many verifications in a single call; the 'static link' flow (docs-9) supports many users sequentially, not bulk operations in an AI-native automation sense. No documentation of bulk create/list/export or batch-processing APIs is present.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
Entrust Identity Verification (Onfido)none0/10The evidence describes single-applicant workflows (create applicant → workflow run → SDK token → webhook) and no batch/bulk API endpoints, CSV bulk upload, or multi-item processing tools are documented. Bulk operations are a plausible axis for an identity verification API but no supporting evidence exists.
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Entrust Identity Verification (Onfido)Stripe Identity supports event-driven automation via webhooks ('Listen for verification results so your integration can automatically trigger reactions') and has some built-in rule-like actions (auto-blocklisting matched documents, override status), but there's no evidence of a user-facing rules engine where an AI-native user can declaratively define custom conditional rules — automation still requires the developer to write webhook-handling code. Missing for 10: a declarative rules/conditions builder, evidence of AI-agent-configurable triggers beyond generic webhooks, and confirmation the MCP server exposes rule-definition capabilities.
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
Workflow Studio provides a no-code, drag-and-drop rule builder for defining identity verification workflows, and webhooks let users trigger downstream actions automatically on workflow status change events, satisfying the event-driven automation story within the IDV domain. Missing for 10: detailed documentation of conditional/branching rule logic within Workflow Studio and independent/hands-on corroboration of the rule engine's flexibility.
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
Biometric liveness — stories about biometric liveness in this arenaBiometric liveness
Stories about biometric liveness in this arena
Deepfake defense
risk analystThe vendor documents specific defenses against AI-generated faces, deepfakes, and camera-injection attacks — named detection capabilities, not just a marketing mention of fraud
weight 2 · round drawnStripe Identitynone0/10The evidence pack only shows generic mentions of ID/selfie matching and fraud prevention (e.g., 'match documents to selfies... to prevent fraud') but no named detection capabilities against AI-generated faces, deepfakes, or camera-injection attacks. No documentation specifically addresses liveness detection technology or anti-spoofing mechanisms by name.
- [claimed-docs] “Match government-issued photo IDs with selfies, and validate Social Security numbers (SSNs)”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/identity.md # Identity Verify government-issued IDs, match documents to selfies, and val…”
Entrust Identity Verification (Onfido)none0/10Evidence documents general liveness via head-motion challenges (Motion feature) and repeat-face fraud alerts, but nothing names specific defenses against AI-generated faces, deepfakes, or camera-injection attacks as the story requires. Missing for 10: named deepfake detection capability, AI-generated/synthetic face detection, and camera/virtual-camera injection attack prevention documentation.
- [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
Duplicate detection
risk analystThe platform detects repeat and duplicate identities across verifications — the same face or document resurfacing under different names is flagged automatically
weight 2 · round to Entrust Identity Verification (Onfido)Docs mention a manual 'add to blocklist' review tool that can block future verifications using the same flagged document, but this requires an analyst to manually add the document rather than the platform automatically detecting and flagging duplicate faces/documents resurfacing under different names. There's no evidence of automatic cross-session biometric or document matching for fraud rings. Missing for 10: automatic duplicate/repeat-identity detection across sessions, face-matching across different names, proactive fraud-ring flagging without manual analyst action.
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
Docs explicitly describe a facial deduplication feature that flags faces already seen in prior verification flows, directly addressing repeat-identity detection under different names. However, evidence lacks detail on document-level duplicate detection, how matches are surfaced/scored to a risk analyst, or independent/hands-on validation of accuracy. Missing for 10: document dedup evidence, analyst-facing reporting/UI detail, independent corroboration of detection accuracy.
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
Liveness
risk analystSelfie checks match the live user to the document portrait with liveness detection — documented defenses against printed photos, screens, and replayed video
weight 3 · round to Entrust Identity Verification (Onfido)Docs confirm selfie-to-document matching as part of the verification flow (stripe-identity-docs-3, stripe-identity-probe-2), but there is no documented mention of liveness detection or specific anti-spoofing defenses against printed photos, screens, or replayed video. Missing for 10: explicit liveness detection documentation, anti-spoofing technical details, and independent/hands-on evidence that liveness checks defeat photo/screen/video replay attacks.
- [claimed-docs] “Match government-issued photo IDs with selfies, and validate Social Security numbers (SSNs)”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/identity.md # Identity Verify government-issued IDs, match documents to selfies, and val…”
Docs confirm a facial similarity/liveness check using motion challenges (head turns, randomized movements) to match selfie to document portrait, but there is no explicit documentation describing specific defenses against printed photos, screen replays, or video replay attacks. Missing for 10: explicit anti-spoofing detail (printed photo, screen, deepfake/video replay countermeasures), independent testing/accuracy corroboration.
- [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”
Data checks — stories about data checks in this arenaData checks
Stories about data checks in this arena
Db checks
developerVerify identity against authoritative databases without documents — SSN, national registries, or credit-header data — for lower-friction flows where a doc scan is overkill
weight 2 · round to Stripe IdentityDocs confirm SSN validation as part of document verification flow (stripe-identity-docs-3), but evidence is thin on standalone no-document checks like national registry lookups or credit-header/database-only verification — SSN validation appears bundled with document capture rather than a document-free flow. Missing for 10: explicit documented database-only/no-document verification session type, national registry checks, credit-header data verification, and independent confirmation these work without a doc scan.
- [claimed-docs] “Match government-issued photo IDs with selfies, and validate Social Security numbers (SSNs)”
- [claimed-docs] “Capture government-issued photo IDs with a conversion-optimized verification flow”
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
Entrust Identity Verification (Onfido)none0/10The evidence pack covers document verification, biometric/facial checks, watchlist/PEP/sanctions screening, webhooks, and SDK auth flows, but contains no mention of document-free identity verification against SSN, national ID registries, or credit-header databases. Since this is a plausible capability for an IDV platform, absence of evidence means 'none' rather than 'na'.
Kyb
ops leadVerify businesses, not just people — registry lookups, UBO identification, and documented KYB flows that chain into KYC on the owners
weight 2 · round drawnStripe Identitynone0/10Stripe Identity documentation and community evidence focus entirely on individual identity verification (ID documents, selfie matching, SSN validation) — nothing addresses business registry lookups, UBO identification, or KYB flows chaining into KYC on owners.
Entrust Identity Verification (Onfido)none0/10All evidence focuses on individual identity verification (document capture, facial similarity, watchlist/PEP checks on applicants, workflow studio for KYC flows) — there is no mention of business/registry lookups, UBO (ultimate beneficial owner) identification, or documented KYB (know-your-business) workflows chaining into KYC on owners.
Risk signals
developerEnrich verifications with phone, email, and device risk signals — carrier checks, address history, device fingerprint — as additional documented check types
weight 2 · round drawnStripe Identitynone0/10Evidence shows Stripe Identity supports document verification, selfie matching, and SSN validation, but nothing documents carrier/phone risk checks, address history checks, or device fingerprinting as check types.
Entrust Identity Verification (Onfido)none0/10The evidence pack documents document reports, facial similarity/liveness, watchlist/PEP/sanctions checks, and duplicate-face detection, but contains no mention of phone, email, carrier, address history, or device fingerprint risk signals as check types. missing for 10: phone risk check docs, email risk check docs, carrier/device fingerprint check docs, address history check docs.
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
- [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
- [claimed-docs] “Motion also assesses liveness by asking users to complete either a simple head turn pattern in both directions or four randomized head movem…”
Document coverage — stories about document coverage in this arenaDocument coverage
Stories about document coverage in this arena
Doc types
ops leadThe platform verifies government IDs from a documented breadth of countries and document types — passports, national IDs, driver licenses, residence permits — with the supported list published
weight 3 · round to Entrust Identity Verification (Onfido)Stripe Identitydisputedcontradicted5/10Stripe's docs claim ID verification for 120+ countries and mention passports, national IDs, and other government-issued photo IDs, but there's no published document-type breakdown (passport vs. national ID vs. driver license vs. residence permit) per country, and community reports concretely contradict full breadth: a user notes Polish IDs are unsupported despite smaller countries being covered, and multiple reports describe Chinese passports being rejected as 'invalid' during verification. missing for 10: a published per-country/per-document-type coverage list, and resolution of documented failures for specific document types (e.g., Chinese passports, Polish IDs).
- [claimed-docs] “Verify the authenticity of government-issued ID documents from more than 120 countries”
- [claimed-docs] “Capture government-issued photo IDs with a conversion-optimized verification flow”
- [community] “I'm really surprised they don't support Polish IDs. We've had them in the same format for ages and I've done automatic verification with som…”
- [community] “We have a problem with validating passports of residents from Asia-Pacific who use the Stripe Identity tool... This situation is similar to …”
- [community] “Stripe Identity shows 「The document is invalid」 after submitting a Chinese passport.”
Docs confirm the platform lets ops configure accepted documents by issuing country and document type (docs-8), implying broad multi-country/document-type support, but no published list enumerating supported countries or specific document types (passports, national IDs, licenses, residence permits) is provided in the evidence. Missing for 10: a published country/document-type coverage list, explicit mention of all four document categories, and any breadth metric (e.g., number of countries/documents supported).
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
- [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
Extraction
developerVerified sessions return the extracted document fields as structured data — name, date of birth, document number, address, expiry — retrievable via the API, not just a pass/fail flag
weight 2 · round to Stripe IdentityDocs explicitly state you can access collected images and extracted data from ID documents programmatically via secret key, and the API returns structured verification details rather than a simple flag; the verification_sessions API and access-verification-results docs support this. Missing for 10: an explicit enumerated field list (name, DOB, document number, address, expiry) in the evidence pack and independent hands-on confirmation of exact field names.
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
Entrust Identity Verification (Onfido)none0/10The evidence describes workflow results retrievable via webhook or polling and a 'document report' concept, but nothing explicitly confirms that structured fields (name, DOB, document number, address, expiry) are returned as retrievable API data rather than a report/pass-fail outcome. Missing for 10: explicit API/webhook payload schema or docs showing per-field extracted data (name, DOB, doc number, address, expiry) returned to developers.
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
Idv agent access — stories about idv agent access in this arenaIdv agent access
Stories about idv agent access in this arena
Agent decisions
ai-native userVerification outcomes come back structured enough for an agent to decide on — machine-readable check results, risk signals, and failure reasons an automated onboarding flow can branch on
weight 2 · round to Stripe IdentityStripe Identity's API returns structured verification_sessions objects with programmatic access to results, extracted data, and outcome webhooks that trigger automated reactions, giving an onboarding flow machine-readable data to branch on (docs-5, docs-6, docs-7, docs-4). Failure reasons and status overrides are documented via review tools, but there's no explicit schema showing granular risk-signal taxonomies or agent-specific decision guidance, and community reports (comm-12, comm-13) show ambiguous 'document invalid' failures that complicate automated branching. missing for 10: a documented enumerated list/schema of all risk signals and failure reason codes, independent confirmation that failure reasons are granular/actionable enough for automated branching rather than opaque.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [community] “We have a problem with validating passports of residents from Asia-Pacific who use the Stripe Identity tool... This situation is similar to …”
- [community] “Stripe Identity shows 「The document is invalid」 after submitting a Chinese passport.”
Docs show a structured, API-driven flow (workflow run → SDK token → webhook/polling → reports) with distinct report types (document, watchlist/PEP/sanctions/adverse media, facial similarity, repeat-fraud alerts) that provide machine-consumable results an automation could branch on. However, there is no explicit evidence of a documented schema for risk scores, standardized failure-reason codes, or example JSON payloads that an agent would parse to make branching decisions. Missing for 10: explicit result schema/field reference, enumerated failure/rejection reason codes, and sample structured payloads showing risk signal granularity.
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
- [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
Agent operations
ai-native userAn agent can operate the verification pipeline — create sessions, poll outcomes, retrieve extracted data, and trigger re-checks through the API or an MCP surface with scoped credentials
weight 3 · round drawnStripe Identity's API supports creating verification sessions, listening for/polling outcomes via webhooks, and retrieving extracted data programmatically with a scoped secret key, and Stripe has a general MCP server that exposes Stripe API tools to agents. However, there is no evidence the MCP server specifically exposes Identity operations (session creation, outcome polling, data retrieval, re-checks) or documents scoped credentials for Identity use cases, nor any agent-specific workflow example. missing for 10: MCP tool listing/documentation confirming Identity-specific endpoints are exposed, evidence of scoped/restricted API keys for agent use, and confirmation of a re-check/retry trigger via API or MCP.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
The API supports the core pipeline: create applicant/workflow run, obtain SDK/OAuth tokens with scoped client-credentials grants, and retrieve results via webhook or polling (docs-2,3,4,6). However there is no evidence of an MCP surface for agent access, and no explicit documentation of a 're-check' trigger endpoint distinct from creating a new workflow run. missing for 10: MCP server/tool surface for agentic access, explicit re-check/re-verification API, and any agent-oriented orchestration examples.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
Integration dx — sandboxes, test modes, webhooks, and how fast a developer gets to a working integrationIntegration dx
Sandboxes, test modes, webhooks, and how fast a developer gets to a working integration
Sandbox
developerA sandbox lets me exercise every outcome before going live — documented test documents, personas, or magic values that deterministically produce pass, fail, and review results
weight 3 · round drawnStripe Identitynone0/10No evidence of documented test/sandbox mode, magic values, or deterministic test personas for triggering pass/fail/review outcomes in Stripe Identity's docs; evidence only covers live verification flow, review tools, and API access, with community complaints about real-world verification failures (not sandbox testing).
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [community] “We have a problem with validating passports of residents from Asia-Pacific who use the Stripe Identity tool... This situation is similar to …”
- [community] “Stripe Identity shows 「The document is invalid」 after submitting a Chinese passport.”
Entrust Identity Verification (Onfido)none0/10No evidence of a sandbox environment with documented test documents, personas, or magic values that deterministically produce pass/fail/review outcomes; the pack only covers workflow setup, SDK tokens, webhooks, and report types. missing for 10: sandbox/test-mode documentation, sample test documents or personas, deterministic magic-value test data for triggering specific verification outcomes.
Session api
developerThe whole verification lifecycle is drivable through the API — create a session, get its status, retrieve results and captured media, and cancel or redact it — with every step documented
weight 3 · round drawnDocs cover creating a session via API (docs-5), listening for status/results (docs-6, docs-7), and accessing captured images/data (docs-4), plus review tools like manual override and blocklisting (docs-10, docs-11). However, no evidence in the pack documents the cancel or redact endpoints for verification sessions, which are explicit parts of the story. missing for 10: documented cancel session endpoint, documented redact endpoint, and independent confirmation of full lifecycle API coverage.
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
Docs confirm core lifecycle steps — create applicant, create workflow run, obtain SDK token, retrieve results via webhook or polling — plus authentication (OAuth) and webhook signature verification are documented. However, explicit API-level documentation for retrieving captured media, and for cancel/redact operations, is not shown in the evidence pack. missing for 10: documented endpoint/example for retrieving captured media via API, documented cancel operation, documented redact/delete operation, and independent confirmation these work end-to-end.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
- [claimed-docs] “Entrust recommends generating short-lived OAuth access tokens for API authentication using client credentials grant.”
Webhooks
developerVerification lifecycle events arrive as signed webhooks — created, processing, verified, requires-input — so my system reacts to outcomes without polling
weight 2 · round to Entrust Identity Verification (Onfido)Docs confirm Identity supports webhook-based outcome handling ("Listen for verification results so your integration can automatically trigger reactions") and programmatic access to verification results, satisfying the no-polling reaction pattern. However, the pack never shows signature verification details or explicitly enumerates the created/processing/verified/requires-input event lifecycle. Missing for 10: explicit webhook signing/verification documentation, enumerated event-type list, and independent/hands-on confirmation of the full lifecycle firing correctly.
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
Docs confirm webhooks can be configured to asynchronously notify status changes on workflow runs, with signed payloads verified via HMAC-SHA256, letting developers avoid polling. However, the pack never enumerates the specific lifecycle states (created, processing, verified, requires-input) claimed in the story, so exact event coverage is unconfirmed. missing for 10: explicit list of webhook event types/payload schema, independent confirmation of event granularity.
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to Stripe IdentityCore verification workflow (create sessions, retrieve results, webhooks) is fully documented via REST API (stripe-identity-docs-5,6,7), and even AI agents can invoke it via the official MCP server (stripe-identity-docs-12, stripe-identity-probe-4). However, review-tool actions like manually overriding verification status or blocklisting documents (stripe-identity-docs-10,11) are described in the context of the dashboard review UI with no confirmed API endpoint, and 'Flows' configuration (stripe-identity-docs-8,9) also appears to be a dashboard-centric concept without clear API-driven equivalent. Missing for 10: documented API endpoints for manual status override/blocklist actions, API-based flow configuration, and independent confirmation that all dashboard actions have API parity.
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “Flows provide a way to save and reuse the same configuration across all of your integration interfaces.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
Core verification actions (create applicant, start workflow run, obtain SDK token, retrieve results via webhook/polling) are documented as API operations, but Workflow Studio (workflow building) and Dashboard-based document-acceptance configuration are explicitly positioned as no-code/low-code UI tools 'without the need for developer involvement,' with no documented API equivalent for authoring or editing workflows/rules themselves. Missing for 10: API/SDK endpoints for programmatically creating or editing workflows and document-acceptance rules equivalent to what Workflow Studio and the Dashboard provide, and confirmation that NFC or other SDK-only features are reachable via pure API calls.
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
- [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnStripe Identitynone0/10No evidence of any data residency/region-selection controls for Stripe Identity; docs and community discussion focus on verification flows, pricing, and document support, with no mention of choosing storage region or data residency options.
Entrust Identity Verification (Onfido)none0/10No evidence in the pack mentions data residency, regional storage options, or data localization controls for Entrust Identity Verification; the docs cover workflow building, SDK tokens, webhooks, and verification reports but say nothing about where data is stored or user choice of region.
ai-native userControl data retention and deletion
weight 2 · round drawnStripe Identitynone0/10The evidence pack covers verification flows, review tools, and access to results, but contains no documentation of data retention policies, deletion controls, or user-initiated data removal/export mechanisms for AI-native or any users. Community commentary raises concern about data security/trust (comm-8) but does not confirm any retention/deletion controls exist. Missing for 10: any documentation of retention periods, deletion APIs/endpoints, data export or right-to-erasure workflows, or AI-agent-specific controls over stored ID data.
- [community] “Does Stripe intend to make a giant online database of international identity documents? Why should we trust Stripe to secure these? It could…”
Entrust Identity Verification (Onfido)none0/10The evidence pack covers workflow building, SDK/API auth, webhooks, document/watchlist checks, and fraud detection, but contains no mention of data retention policies, deletion controls, or user-facing privacy/data lifecycle management. No documentation excerpt addresses how users or AI-native integrators can configure retention periods or trigger deletion of collected identity data.
Privacy retention — stories about privacy retention in this arenaPrivacy retention
Stories about privacy retention in this arena
Consent
founderThe vendor documents how biometric data is handled lawfully — GDPR bases, US biometric statutes like BIPA, and the consent language my flow needs — so legal review has something to review
weight 2 · round drawnStripe Identitynone0/10None of the docs or community evidence address legal bases for biometric processing (GDPR Art. 9 basis, BIPA compliance, consent language) — evidence covers technical integration, review tools, and pricing/UX feedback only. missing for 10: GDPR legal basis documentation, BIPA/state biometric statute compliance statements, sample consent language, any privacy/legal compliance whitepaper.
Entrust Identity Verification (Onfido)none0/10The evidence pack covers technical integration (SDKs, webhooks, workflow studio, watchlist/document reports) but contains no documentation addressing GDPR legal bases, BIPA or other US biometric statutes, or consent language guidance for biometric data handling.
Redaction
ops leadControl what happens to collected identity data — documented retention windows and a redaction or deletion API that scrubs PII on demand
weight 2 · round drawnStripe Identitynone0/10The evidence pack shows verification, review tools (override/blocklist), and access to collected data, but contains no documentation of retention windows or a redaction/deletion API for scrubbing PII on demand. Community commentary even raises concerns about long-term data storage trust without any documented deletion mechanism countering it.
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [community] “Does Stripe intend to make a giant online database of international identity documents? Why should we trust Stripe to secure these? It could…”
Entrust Identity Verification (Onfido)none0/10None of the evidence mentions documented data retention windows or a redaction/deletion API for PII; the docs cover workflow building, SDK tokens, webhooks, watchlist reports, and biometric features but nothing about data lifecycle controls. missing for 10: retention policy documentation, deletion/redaction API endpoints, and any mention of PII scrubbing on demand.
Verification flows — stories about verification flows in this arenaVerification flows
Stories about verification flows in this arena
Hosted flows
developerLaunch a complete document-plus-selfie verification with a hosted or drop-in flow — create a session server-side, redirect or embed, and read the result — without building capture UI myself
weight 3 · round drawnDocs show server-side session creation via API (docs-5), a hosted, conversion-optimized capture flow with no custom UI needed (docs-2, docs-1, docs-3), and mechanisms to read results via webhooks or API (docs-6, docs-7), plus reusable 'Flows' for static links (docs-8, docs-9). Community hands-on reports corroborate the redirect-based hosted UX working well across desktop/mobile with no native app needed (stripe-identity-comm-2, stripe-identity-comm-5). Missing for 10: explicit documentation of an embeddable/drop-in JS element (vs. only hosted redirect) and independent verification of the full create→redirect→read loop end-to-end.
- [claimed-docs] “Verify the authenticity of government-issued ID documents from more than 120 countries”
- [claimed-docs] “Capture government-issued photo IDs with a conversion-optimized verification flow”
- [claimed-docs] “Match government-issued photo IDs with selfies, and validate Social Security numbers (SSNs)”
- [claimed-docs] “curl https://api.stripe.com/v1/identity/verification_sessions \ -u "<<YOUR_SECRET_KEY>>:" \ -d type=document”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Flows provide a way to save and reuse the same configuration across all of your integration interfaces.”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
- [community] “1. Easy transition from desktop to phone to take a picture of your ID or a selfie, then complete verification on desktop. 2. It does all the…”
- [community] “We've been using this to verify short term rental guests (non-Airbnb) for the past year and it's been extremely positive. Given that our gue…”
Docs describe the full server-side flow: create applicant, create workflow run (returns SDK token), collect document+selfie captures via drop-in/hosted SDK, and retrieve results via webhook or polling — exactly the no-build-your-own-capture-UI flow described in the story. Also supports Smart Capture Link as a hosted no-code option and webhook signature verification for secure result reads. missing for 10: no independent/hands-on developer corroboration (blog posts, sample repos, or third-party integration reports) confirming the drop-in/hosted redirect flow works end-to-end in practice.
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
- [claimed-docs] “You can get the expected signature of the webhook by computing the HMAC of the event request body using the SHA256 algorithm, using the webh…”
- [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
Native sdks
developerI get native iOS, Android, and web SDKs with guided camera capture — glare, blur, and edge detection coaching the user to a usable document photo on the first try
weight 2 · round to Entrust Identity Verification (Onfido)Stripe Identitynone0/10The evidence only references a generic 'conversion-optimized verification flow' and one community comment describing browser-based (not native) image capture across desktop/phone; there is no documentation of native iOS/Android SDKs or of glare, blur, or edge-detection coaching during capture.
- [claimed-docs] “Capture government-issued photo IDs with a conversion-optimized verification flow”
- [community] “1. Easy transition from desktop to phone to take a picture of your ID or a selfie, then complete verification on desktop. 2. It does all the…”
Evidence confirms native mobile SDKs (with NFC only via mobile SDK) and an SDK-token based capture flow, and the product name 'Smart Capture' implies guided capture, but there is no explicit documentation of glare/blur/edge-detection coaching or confirmation of iOS, Android, and web SDK parity. missing for 10: explicit glare/blur/edge-detection coaching documentation, confirmation of web SDK support, first-try capture UX detail.
- [claimed-docs] “Obtaining SDK tokens – SDK tokens are essential for authenticating and initializing the Entrust IDV SDKs”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “NFC is **only available for integration via the Entrust Identity Verification mobile SDKs**.”
- [claimed-docs] “migration guide to support migrations from the latest Smart Capture SDKs to the new Entrust IDV SDKs and highlight all new features”
- [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
No code
ops leadSend a verification to someone with a no-code link or QR code — no engineering ticket to verify a one-off customer, contractor, or seller
weight 2 · round to Stripe IdentityStripe Identity's "Flows" feature explicitly supports a static, shareable link that ops can send to verify any number of users without engineering integration work (stripe-identity-docs-8, stripe-identity-docs-9), fitting the no-code link use case; community evidence confirms the flow is simple enough for non-technical guests to complete via a link on mobile (stripe-identity-comm-2, stripe-identity-comm-5). Missing for 10: explicit mention of QR code generation/sharing, and independent hands-on confirmation of the ops/no-ticket workflow specifically (vs. general link UX).
- [claimed-docs] “Flows provide a way to save and reuse the same configuration across all of your integration interfaces.”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
- [community] “1. Easy transition from desktop to phone to take a picture of your ID or a selfie, then complete verification on desktop. 2. It does all the…”
- [community] “We've been using this to verify short term rental guests (non-Airbnb) for the past year and it's been extremely positive. Given that our gue…”
Smart Capture Link is documented as a low-/no-code frontend that lets ops verify individuals without engineering effort, aligning with the no-code link concept, and Workflow Studio supports drag-and-drop workflow setup without developers. However, there is no explicit mention of a shareable QR code option or a simple 'send a one-off link' flow from a dashboard for ad-hoc individuals like contractors or sellers. missing for 10: explicit QR code generation/sharing feature, documentation of an ops-friendly one-off invite/send flow, independent or hands-on confirmation of ease-of-use for non-technical ops staff.
- [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
Reuse
developerA person verified once can be recognized and reused across sessions or products — documented re-verification and reuse of a prior passed check instead of forcing a full re-run
weight 2 · round drawnStripe Identitynone0/10Docs describe verification flows, blocklisting bad documents, and manual overrides, but there is no documented mechanism to recognize a previously-verified person and reuse their passed check to skip a new verification session across products/sessions. missing for 10: explicit reuse/verification-caching API, cross-session identity linking, documentation of skipping re-verification for a known verified user.
- [claimed-docs] “Flows provide a way to save and reuse the same configuration across all of your integration interfaces.”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
Entrust Identity Verification (Onfido)none0/10The docs describe repeat-face detection for fraud purposes (flagging faces that already went through verification) but this is a fraud-detection alert, not a documented mechanism for reusing a prior passed check to skip re-verification across sessions or products. No evidence of a 'reusable identity' or portable verification token/credential feature.
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
Verification orchestration — stories about verification orchestration in this arenaVerification orchestration
Stories about verification orchestration in this arena
Analytics
founderSee verification funnel analytics — pass rates, drop-off points, completion time by country and document type — to know what verification is costing me in signups
weight 2 · round drawnStripe Identitynone0/10Evidence covers verification session creation, review tools, and access to individual verification results, but nothing about aggregate funnel analytics (pass rates, drop-off points, completion time breakdowns by country/document type) that a founder could use to quantify signup cost. Missing for 10: dashboard/analytics UI for funnel metrics, aggregated pass-rate or drop-off reporting, completion-time-by-country/doc-type breakdowns.
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
Entrust Identity Verification (Onfido)none0/10Evidence covers workflow configuration, SDK/webhook integration, document/watchlist checks, and fraud detection, but nothing about a dashboard or reporting feature showing pass rates, drop-off funnels, or completion time broken down by country/document type. No analytics or reporting evidence exists to support this founder-facing metrics story.
Review
ops leadBorderline verifications land in a manual review queue with the full evidence — document images, extracted fields, check results — and reviewer decisions feed back into the record
weight 2 · round to Stripe IdentityDocs confirm access to full evidence (images, extracted fields, check results) via API and review tools that let a human override status or blocklist a document, which supports manual review workflows, but there's no documented dedicated 'manual review queue' UI for borderline cases, no explicit routing/escalation logic for borderline verifications, and no evidence that reviewer decisions are captured as structured feedback beyond a status override. missing for 10: a native queue/dashboard for borderline cases, explicit borderline-detection/escalation criteria, and structured reviewer-decision feedback loop into the verification record.
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
Entrust Identity Verification (Onfido)none0/10The evidence pack documents workflow orchestration, SDKs, webhooks, watchlist/document reports, and dashboard configuration, but nowhere describes a manual review queue that surfaces document images, extracted fields, and check results together, nor a feedback loop where reviewer decisions update the record. Missing for 10: explicit manual review queue documentation, evidence bundling for reviewers, and reviewer decision feedback into the applicant record.
Workflows
ops leadConfigure verification logic without code — conditional steps, risk-based routing, country-specific requirements, and template changes that don't need an engineering deploy
weight 3 · round to Entrust Identity Verification (Onfido)Stripe Identity offers 'Flows' to save and reuse a verification configuration across integration surfaces without redeploying code, and review tools let ops manually override statuses or blocklist documents, but there is no evidence of a no-code UI for conditional branching, risk-based routing, or country-specific rule sets — most configuration (document types, session creation) still happens via API calls in docs examples. missing for 10: no-code conditional-step builder, risk-based routing rules, country-specific requirement configuration, and independent confirmation that Flows support these beyond simple reuse.
- [claimed-docs] “Flows provide a way to save and reuse the same configuration across all of your integration interfaces.”
- [claimed-docs] “You can use a flow’s static link to verify any number of your users.”
- [claimed-docs] “Override status: Manually override the verification status to match your decision on whether or not the customer is verified.”
- [claimed-docs] “Add to blocklist: Add the document to a blocklist to programmatically block future verifications completed with the same document.”
- [community] “I like that it lets you specify the types of accepted docs. The biggest issue i have with Stripe identity verification product right now. An…”
Workflow Studio is explicitly documented as a no-code, drag-and-drop tool for building/maintaining/updating workflows without developer involvement, and the Dashboard lets ops filter accepted documents by issuing country — both directly support code-free verification-logic configuration. However, the evidence never explicitly confirms conditional branching or risk-based routing logic within Workflow Studio, only general workflow building and document/country filtering. Missing for 10: explicit documentation of conditional-step/risk-based routing configuration, and independent/hands-on confirmation that template changes deploy live without engineering involvement.
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
- [claimed-docs] “Smart Capture Link is a low- to no-code frontend solution complementing Workflow Studio, allowing you to verify individuals with or without …”
- [claimed-docs] “In your Dashboard, you can configure which documents you want to accept in your verification workflow, filtering according to issuing countr…”
Watchlist screening — stories about watchlist screening in this arenaWatchlist screening
Stories about watchlist screening in this arena
Monitoring
ops leadScreening is not one-shot — previously verified users are continuously re-screened against watchlist updates, and changes raise events I can act on
weight 2 · round drawnStripe Identitynone0/10Stripe Identity's evidence covers one-time document verification, selfie matching, SSN validation, and webhook-based verification-session outcomes, but there is no mention of watchlist/sanctions screening or continuous re-screening of previously verified users against watchlist updates. This is a plausible axis for an identity-verification product (competitors like Persona/Onfido offer ongoing AML monitoring), so absence of evidence yields 'none' rather than 'na'.
- [claimed-docs] “Match government-issued photo IDs with selfies, and validate Social Security numbers (SSNs)”
- [claimed-docs] “Listen for verification results so your integration can automatically trigger reactions.”
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
Entrust Identity Verification (Onfido)none0/10Evidence documents one-time Watchlist Reports (sanctions, PEP, monitored lists, adverse media) run during a verification workflow, plus webhooks that notify on workflow status changes — but nothing describes ongoing/continuous re-screening of previously verified applicants against watchlist updates or dedicated 'watchlist changed' events after the initial check.
- [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
Screening
ops leadScreen verified users against sanctions, PEP, and adverse-media watchlists as part of the same verification — one vendor, one API, one review surface
weight 2 · round to Entrust Identity Verification (Onfido)Stripe Identitynone0/10Evidence covers ID document verification, selfie matching, SSN validation, and review/override tools, but no mention of sanctions, PEP, or adverse-media watchlist screening anywhere in docs or community reports.
Docs explicitly describe Watchlist reports covering Sanctions, PEPs, Monitored Lists, and Adverse Media, integrated into the same workflow/API/dashboard used for identity verification (single vendor, single API, unified webhook/review surface). missing for 10: no independent/hands-on corroboration of the unified review UI or case-management workflow for screening hits.
- [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
- [claimed-docs] “create an applicant → create a workflow run (returns an SDK token) → collect captures via SDK → retrieve results via webhook or polling”
- [claimed-docs] “Configuring webhooks – asynchronously monitor the status of identity verification workflows by configuring webhook events to notify you of c…”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableStripe Identityn/aStripe Identity is an identity-verification API/service, not an agent or agent-hosting platform that consumes external tools; the evidence only shows Stripe providing an MCP *server* for other AI agents to call Stripe's API (the reverse role), not Stripe Identity acting as an MCP client that plugs in third-party MCP servers.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableStripe Identitynone0/10No evidence that Stripe Identity itself generates AI-driven insights or suggestions from verification data; the docs describe verification, review tools, and manual override, not AI-generated analytics or recommendations. The MCP server reference is about external agents calling Stripe's API, not in-product AI insights for the user.
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification is an identity-proofing/verification API and SDK platform (document checks, facial similarity, watchlist screening, workflows), not a data-analytics or generative-AI insights product where users query their data for AI-generated suggestions. The story's axis is a category error for this product type.
- [claimed-docs] “It's a no-code, drag and drop interface that allows you to build, maintain and update workflows seamlessly without the need for developer in…”
- [claimed-docs] “Watchlist reports verify an applicant's records against a range of global watchlists, including: Sanctions... Politically Exposed Persons (P…”
- [claimed-docs] “The alerts you to faces which have already been through your identity verification flow, highlighting potential repeat identity fraud attemp…”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableStripe Identityn/aStripe Identity is an identity-verification API/product, not an AI assistant application; there is no evidence of a built-in AI assistant users can delegate tasks to (the MCP server evidence is for external agents connecting to Stripe, not a built-in assistant within the product).
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableStripe Identityn/aStripe Identity is a point-in-time identity verification API (document capture, verification sessions, webhooks for outcomes) — it is not a workflow orchestration or job-scheduling product, so 'scheduling recurring jobs/workflows' is a category error rather than a missing feature.
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification is an identity verification/KYC API and SDK platform, not an automation/orchestration tool for scheduling recurring jobs or workflows; its 'workflows' refer to verification decision flows, not cron-like recurring job scheduling. This axis is a category error for this product type.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableStripe Identityn/aStripe Identity is an identity-verification API/service; it has no concept of 'automations' that a user builds, versions, reviews, or rolls back — that's a workflow/automation-builder axis, not applicable to this product category.
ai-native userExport all of my data in open formats and leave
weight 3 · not comparableStripe Identitynone0/10Stripe Identity is a KYC/identity-verification API for businesses, not a personal data platform; end users have no account or export mechanism, and evidence shows only programmatic access by the integrating business (via API/secret key), not data export/portability for the verified individual to leave with their data in open formats. No evidence of any data-export or account-closure/data-portability feature for the AI-native end user persona.
- [claimed-docs] “You can access most verification details programmatically... using your secret key.”
- [claimed-docs] “Access collected images, and extracted data from government-issued ID documents”
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification is an identity-verification/KYC API and SDK platform, not a data-hosting product with a user-facing data export/portability feature for end users; 'export all data and leave' is a category error for this kind of B2B verification infrastructure.
ai-native userRead the product's source under an open license
weight 2 · not comparableStripe Identityn/aStripe Identity is a closed proprietary SaaS API/service, not open-source software; source-code openness is not a fair axis for this kind of product's evidence pack.
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification is a closed commercial SaaS/SDK identity-verification product; there is no indication it is or could be an open-source project. Source availability under an open license is not a relevant axis for this kind of proprietary vendor platform.
ai-native userSelf-host the core product
weight 3 · not comparableStripe Identityn/aStripe Identity is a hosted SaaS verification API; self-hosting the core product is not a coherent axis for this kind of managed cloud service.
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification (Onfido) is a cloud SaaS identity verification API/SDK platform; self-hosting the core product is not an offered deployment model and is a category error for this type of managed compliance/verification service, not a missing feature.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableStripe Identitynone0/10No evidence pack content addresses AI-model-training data usage, opt-out controls, or any privacy policy specific to AI training exclusion for Stripe Identity; the evidence only covers identity verification features, pricing, and integration mechanics.
Entrust Identity Verification (Onfido)n/aThis story targets AI-native users seeking control over AI training data usage, which is not a relevant axis for an identity verification/KYC platform like Entrust Onfido; the evidence pack covers document verification, workflows, watchlists, and SDKs with no mention of AI training data opt-outs. This is a category mismatch rather than a missing capability.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableStripe Identitynone0/10No evidence in the pack mentions telemetry opt-out, usage tracking controls, or any privacy settings for AI-native usage; Stripe Identity is an identity verification API and the evidence is entirely about document verification and KYC features, not telemetry controls.
Entrust Identity Verification (Onfido)n/aEntrust Identity Verification (Onfido) is an identity-verification API/SDK platform, not an AI coding tool or agent product with telemetry/usage-tracking opt-out settings relevant to an AI-native developer workflow; this axis is a category error for this product type.