Stripe Identity vs Veriff

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Stripe Identity✓fullprobed8/10

   Stripe'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”

   proof ↗⚑ flag

   Veriff✓fullprobed8/10

   Veriff hosts a live llms.txt at devdocs.veriff.com/llms.txt (confirmed HTTP 200 via probe) that indexes structured dev docs, directly enabling an AI agent to be pointed at agent-oriented documentation. Missing for 10: no OpenAPI/machine-readable spec (openapi.json 404s) and no explicit vendor messaging about AI-agent consumption of the docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://devdocs.veriff.com/llms.txt # Veriff Dev Documentation > Knowledge base documentation for Veriff Dev Do…”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Stripe Identity
   Stripe Identity~partialclaimed6/10

   Stripe 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.”

   proof ↗⚑ flag

   Veriff~partialclaimed5/10

   Veriff exposes a REST API (create session, poll decision, webhooks) and dedicated test integrations where decisions can be triggered programmatically without paid usage, which supports scripted/CI-style testing of the integration logic. However, the core verification itself requires an end-user completing an SDK-driven capture flow, so full headless automation of real verifications is not documented. missing for 10: explicit CI/automation guide, example of running full flow with no human/SDK interaction, and any mention of CI pipelines or automation frameworks.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Stripe Identity
   Stripe Identity~partialprobed6/10

   Stripe (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”

   proof ↗⚑ flag

   Veriff—none0/10

   Veriff is an identity verification SaaS with a REST API, SDKs, and webhooks, but no evidence of an official MCP server for agent connectivity; this is a fair axis for a SaaS API product, so absence of evidence yields none.

   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Identity
   Stripe Identity~partialprobed6/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff—none0/10

   The 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.)

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Stripe Identity✓fullprobed8/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff✓fullprobed8/10

   Veriff exposes a documented REST API (session creation, decision polling, HMAC-signed webhooks, authentication) with dedicated devdocs, matching an AI-native user's need to drive the product programmatically. Missing for 10: a discoverable OpenAPI/Swagger spec (probe found only 404s) and independent third-party confirmation of API usage.

   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Stripe Identity—none0/10

   The 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.)

   ⚑ flag

   Veriff—none0/10

   Veriff's API auth model is a single shared-secret HMAC key (X-HMAC-SIGNATURE) plus optional IP allowlisting, not a scoped/least-privilege credential system with per-agent roles or permissions. No evidence of API key scoping, granular roles, or credential issuance tailored to individual agents.

   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Identity~partialprobed5/10

   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”

   proof ↗⚑ flag

   Veriff~partialprobed5/10

   Veriff docs reference web and native SDKs plus a REST API with webhooks and HMAC auth, giving developers official building blocks, but there is no OpenAPI/swagger spec (probe found 404s) and no evidence of language-specific SDK repos, versioning, or AI-agent-friendly machine-readable schemas. Missing for 10: OpenAPI/machine-readable spec, list of concrete SDK languages/repos, independent developer corroboration.

   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Veriff
   Stripe Identity✓fullclaimed7/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff✓fullclaimed8/10

   Veriff has documented webhook support with HMAC-signed payloads for verification decisions, including setup docs and security details (X-HMAC-SIGNATURE, IP allowlisting), which allows event-driven/agentic integration rather than only polling. Missing for 10: no independent/hands-on corroboration of webhook reliability or payload schema details, and no explicit mention of event types beyond decision webhooks.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Stripe Identity—none0/10

   No 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.

   ⚑ flag

   Veriff—none0/10

   Evidence covers identity verification APIs, webhooks, HMAC auth, manual review portal, and pricing add-ons, but nothing indicates AI-generated insights or suggestions surfaced to users from their data. This is a verification/fraud-check product, not an analytics/insight tool, and no such feature is documented.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Stripe Identity~partialprobed5/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff~partialclaimed5/10

   Veriff's API supports asynchronous background processing via webhooks and decision polling (create a session, then get notified via webhook when a decision is ready), which enables automations that run without direct user interaction. However, there is no evidence of AI-agent-specific orchestration, scheduling, or autonomous multi-step workflow tooling beyond basic webhook/polling patterns. Missing for 10: explicit support for autonomous agent orchestration, scheduled/triggered workflows beyond single verification sessions, and any AI-native automation framework or SDK.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   proof ↗⚑ flag

3. ai-native userOperate the product with natural-language commands

   weight 2 · round to Stripe Identity
   Stripe Identity~partialprobed5/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff—none0/10

   The 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.)

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Stripe Identity
   Stripe Identity~partialprobed4/10

   Docs 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/…”

   proof ↗⚑ flag

   Veriff—none0/10

   Veriff's devdocs describe API endpoints (sessions, webhooks, HMAC auth) but there is no evidence of an interactive reference with runnable/try-it examples; a probe for OpenAPI/Swagger specs at devdocs.veriff.com returned 404s, indicating no machine-readable spec backing an interactive console.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Stripe Identity—none0/10

   The 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”

   proof ↗⚑ flag

   Veriff—none0/10

   Explicit probe evidence shows all common OpenAPI/Swagger spec paths return 404, and no documented download link for a machine-readable spec exists anywhere in the docs pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://devdocs.veriff.com/llms.txt # Veriff Dev Documentation > Knowledge base documentation for Veriff Dev Do…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Veriff
   Stripe Identity—none0/10

   No 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.

   ⚑ flag

   Veriff✓fullclaimed7/10

   Veriff explicitly documents test integrations where sessions 'do not count towards paid usage' and decisions can be manually triggered without real verification data, effectively serving as a sandbox for API testing. missing for 10: no explicit mention of full data isolation guarantees, no independent/hands-on confirmation of sandbox fidelity, and OpenAPI spec probes returned 404 suggesting limited machine-readable API test tooling.

   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Stripe Identity—none0/10

   Evidence 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/…”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence shows Veriff's API uses versioned paths (e.g. /v1/sessions) but there is no documentation of a versioning scheme, deprecation policy, changelog, or sunset timeline; OpenAPI spec probes returned 404. Missing for 10: documented API versioning/deprecation policy, changelog or migration guides, and any explicit commitment to backward compatibility.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Veriff
   Stripe Identity—none0/10

   Evidence 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.”

   proof ↗⚑ flag

   Veriff~partialclaimed2/10

   Veriff's API is built around creating and polling individual verification sessions (docs-6, docs-7), with no documented bulk/batch API endpoint for processing many items in one call. The only mention of batch capability is 'Batch upload tests' that are ad-hoc, negotiated with the onboarding team, and 'very use case specific' rather than a standard bulk feature. Missing for 10: a documented bulk/batch API endpoint, SDK support for multi-item submission, and evidence of automated large-scale batch processing.

   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”
   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Stripe Identity
   Stripe Identity~partialclaimed5/10

   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”

   proof ↗⚑ flag

   Veriff~partialclaimed3/10

   Veriff supports webhooks to notify external systems of verification events, which is a basic building block for event-driven automation, but there is no evidence of a rule-definition system or conditional logic engine that lets users configure custom triggers/actions within Veriff itself. missing for 10: rule engine or conditional automation builder, evidence of user-configurable trigger logic beyond simple webhook delivery, AI-native automation tooling.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   proof ↗⚑ flag

Deepfake defense

1. 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 drawn
   Stripe Identity—none0/10

   The 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…”

   proof ↗⚑ flag

   Veriff—none0/10

   The only relevant evidence (veriff-docs-11) is a single generic marketing-style sentence claiming the liveness solution 'ensures biometric data is from a live person' — it names no specific detection capabilities (e.g., anti-spoofing models, deepfake detection, camera-injection detection) as the story requires. Missing for 10: named technical defenses against AI-generated faces, deepfake detection methodology, camera/virtual-camera injection detection, and any independent validation of these claims.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   proof ↗⚑ flag

Duplicate detection

1. 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 Stripe Identity
   Stripe Identity~partialclaimed3/10

   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.”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC auth, biometric liveness (live-person spoof detection) and manual review in the portal, but nothing describes cross-session duplicate/repeat-identity detection (e.g., flagging the same face or document reappearing under a different name). Biometric liveness [veriff-docs-11] only addresses spoof/liveness, not identity deduplication across verifications.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ flag

Liveness

1. 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 drawn
   Stripe Identity~partialprobed4/10

   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…”

   proof ↗⚑ flag

   Veriff~partialclaimed4/10

   Veriff's docs confirm a dedicated biometric liveness feature that verifies the captured biometric data comes from a live person, matching the core story of selfie-to-document liveness matching, but there is no detail on specific anti-spoofing defenses (printed photo, screen replay, video injection) or any independent certification/testing evidence. Missing for 10: documented defenses against specific spoof types (print/screen/replay), independent liveness certification (e.g., iBeta/NIST), and hands-on/third-party validation of match accuracy.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   proof ↗⚑ flag

Db checks

1. 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 Identity
   Stripe Identity~partialclaimed5/10

   Docs 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”

   proof ↗⚑ flag

   Veriff—none0/10

   All evidence describes Veriff's document- and biometric-based verification flows (session creation, SDKs, webhooks, liveness) plus a PEP/Sanctions add-on, but nothing shows a no-document database-only check against SSN, national registry, or credit-header data. missing for 10: any API/doc showing a no-doc data-only verification mode, evidence of SSN/registry/credit-header lookups.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”

   proof ↗⚑ flag

Kyb

1. ops leadVerify businesses, not just people — registry lookups, UBO identification, and documented KYB flows that chain into KYC on the owners

   weight 2 · round drawn
   Stripe Identity—none0/10

   Stripe 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.

   ⚑ flag

   Veriff—none0/10

   All evidence describes person-level identity verification (KYC) via sessions, SDKs, webhooks, biometric liveness, and PEP/sanctions checks; nothing addresses business registry lookups, UBO identification, or a documented KYB flow chaining into KYC of owners. Missing for 10: business registry/company lookup API, UBO identification workflow, KYB-to-KYC chaining documentation, any KYB product page or endpoint.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   proof ↗⚑ flag

Risk signals

1. developerEnrich verifications with phone, email, and device risk signals — carrier checks, address history, device fingerprint — as additional documented check types

   weight 2 · round drawn
   Stripe Identity—none0/10

   Evidence 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.

   ⚑ flag

   Veriff—none0/10

   Evidence covers document/biometric verification, webhooks, HMAC auth, and PEP & sanctions checks, but nothing documents phone/email/device risk signals such as carrier checks, address history, or device fingerprinting as check types.

   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”

   proof ↗⚑ flag

Doc types

1. 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 Stripe Identity
   Stripe Identity!disputedcontradicted5/10

   Stripe'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.”

   proof ↗⚑ flag

   Veriff—none0/10

   The evidence pack contains only API/SDK/webhook integration docs, HMAC auth, biometric liveness, and pricing add-ons — none of it lists supported countries or document types (passports, national IDs, driver licenses, residence permits) or points to a published coverage list.

   ⚑ flag

Extraction

1. 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 Identity
   Stripe Identity✓fullclaimed8/10

   Docs 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.”

   proof ↗⚑ flag

   Veriff—none0/10

   The evidence pack shows session creation, decision polling, and webhook endpoints, but nothing documents that extracted document fields (name, DOB, document number, address, expiry) are returned as structured data via the API — only pass/fail-style 'decision' retrieval is mentioned.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”

   proof ↗⚑ flag

Agent decisions

1. 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 Identity
   Stripe Identity✓fullcommunity7/10

   Stripe 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.”

   proof ↗⚑ flag

   Veriff~partialprobed6/10

   Veriff's API returns structured decision data via session creation, polling GET /v1/sessions/{id}/decision, and webhooks with HMAC-verified payloads, which an automated flow could branch on; docs also mention risk-related add-ons like PEP & Sanctions checks. However, there's no evidence of a documented schema for risk signals/failure-reason codes, no OpenAPI spec (probe found 404s), and manual review via the Customer Portal is emphasized alongside automation, suggesting outcomes aren't always fully machine-resolved. Missing for 10: published response schema/enum of failure reasons and risk signal fields, OpenAPI spec for structured parsing, and evidence of fully automated (non-manual-review) decisioning suitable for agent branching.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

Agent operations

1. 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 drawn
   Stripe Identity~partialprobed5/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff~partialprobed5/10

   Veriff's API supports the core pipeline pieces an agent would need: creating sessions (veriff-docs-6), polling decision status (veriff-docs-7), webhook-based outcome delivery (veriff-docs-3), and scoped credential auth via HMAC/shared-secret and IP allowlisting (veriff-docs-5, veriff-docs-10). However there is no MCP server or agent-oriented surface, no clear 'retrieve extracted data' endpoint distinct from decision polling, and re-check/decision-triggering is only documented for test integrations (veriff-docs-9), not general production re-checks; a probe for a machine-readable OpenAPI spec also 404'd (veriff-probe-2). missing for 10: MCP surface, documented extracted-data retrieval endpoint, production re-check trigger, discoverable OpenAPI schema.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

Sandbox

1. 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 to Veriff
   Stripe Identity—none0/10

   No 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.”

   proof ↗⚑ flag

   Veriff~partialclaimed6/10

   Veriff docs confirm a test integration mode where sessions don't count toward paid usage and where developers can explicitly trigger decisions for test sessions, supporting a sandbox-like exercise of outcomes. However, there's no documented catalog of specific test documents/personas or magic values that deterministically map to pass/fail/review, and batch/service-quality testing is described as ad hoc and use-case-specific rather than self-serve. Missing for 10: documented magic-value/test-document list per outcome, self-serve deterministic mapping without onboarding-team coordination, independent confirmation of sandbox fidelity.

   • [claimed-docs] “Any verification session done in the test integrations **do not count towards paid usage**.”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Batch upload tests are **sometimes** agreed with Veriff onboarding team and are **very use case specific**.”

   proof ↗⚑ flag

Session api

1. 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 to Stripe Identity
   Stripe Identity~partialclaimed6/10

   Docs 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.”

   proof ↗⚑ flag

   Veriff~partialclaimed5/10

   Docs clearly cover creating a session, polling for decision/status, webhooks, and passing end-user data (veriff-docs-1, veriff-docs-6, veriff-docs-7, veriff-docs-3), but there's no evidence of API endpoints for retrieving captured media, or for cancelling/redacting a session — review/management is instead shown via the Customer Portal UI (veriff-docs-12, veriff-docs-13), not the API. missing for 10: documented API endpoints for retrieving captured media, and for cancel/redact/delete operations.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Pass end-user data via API and check out endpoint behavior”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ flag

Webhooks

1. developerVerification lifecycle events arrive as signed webhooks — created, processing, verified, requires-input — so my system reacts to outcomes without polling

   weight 2 · round drawn
   Stripe Identity~partialclaimed6/10

   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.”

   proof ↗⚑ flag

   Veriff~partialclaimed6/10

   Veriff docs confirm webhooks are the primary integration path (with polling only as a fallback) and that responses are authenticated via HMAC signature headers, matching the 'signed webhooks instead of polling' pattern. However, the evidence never enumerates the specific lifecycle event types (created, processing, verified, requires-input) or shows a payload schema/event-type list confirming granular status callbacks. Missing for 10: explicit event-type/status enumeration in webhook payloads, sample payload showing verification state transitions, independent/hands-on confirmation of signature verification working in practice.

   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “the shared secret key, used to create the X-HMAC-SIGNATURE header”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Stripe Identity
   Stripe Identity~partialprobed6/10

   Core 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”

   proof ↗⚑ flag

   Veriff~partialprobed5/10

   Veriff's API covers the core verification lifecycle (session creation, decision retrieval, webhooks, HMAC auth) per veriff-docs-6/7/3/10, but its own docs show manual review and case management are portal-only ('Verifications page in the Veriff Customer Portal', veriff-docs-12/13), and PDF export appears tied to the portal (veriff-docs-14), indicating UI-only functionality not mirrored in the API. No OpenAPI spec is discoverable (veriff-probe-2), limiting confidence that full API parity/documentation exists for programmatic exploration. Missing for 10: evidence of API endpoints for manual review/case management, PDF export via API, and a public OpenAPI spec confirming full endpoint coverage.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Veriff uses the HMAC-SIGNATURES (as `x-hmac-signature` header or `VRF-HMAC-SIGNATURE` header) and allowed IP lists and ranges for that purpo…”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “Export verification session details to PDF”
   • [probe] “PROBE openapi: all candidate paths 404 (https://devdocs.veriff.com/openapi.json, https://devdocs.veriff.com/swagger.json, https://devdocs.ve…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Stripe Identity—none0/10

   Stripe 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”

   proof ↗⚑ flag

   Veriff—none0/10

   Veriff's docs mention exporting verification session details to PDF for business customers reviewing cases, but there is no evidence of an end-user-facing mechanism to export all personal/identity data in open, machine-readable formats (JSON/CSV) and delete one's account. The axis applies since Veriff stores significant PII/biometric data, but no comprehensive data-portability feature is documented.

   • [claimed-docs] “Export verification session details to PDF”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Stripe Identity—none0/10

   No 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.

   ⚑ flag

   Veriff—none0/10

   No evidence pack items mention data residency, regional storage options, or GDPR-style data localization controls; none of the docs address where verification data is stored or configurable region choice.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Stripe Identity—none0/10

   No 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.

   ⚑ flag

   Veriff—none0/10

   No evidence in the pack addresses AI training data opt-out or any privacy controls related to preventing use of user data for AI model training; the documentation covers verification API/SDK/webhook mechanics only.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Identity—none0/10

   The 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…”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC security, and manual review, but nothing addresses data retention periods, deletion requests, or user-initiated data control/removal APIs.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Stripe Identity—none0/10

   No 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.

   ⚑ flag

   Veriff—none0/10

   Veriff is an identity-verification API/service and its evidence pack covers session APIs, webhooks, HMAC security, and biometric liveness, but there is no mention of telemetry/usage tracking or any opt-out mechanism for such tracking.

   ⚑ flag

Consent

1. 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 drawn
   Stripe Identity—none0/10

   None 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.

   ⚑ flag

   Veriff—none0/10

   The evidence pack only covers API/SDK integration mechanics, biometric liveness feature descriptions, and pricing — there is no documentation of GDPR legal bases, BIPA or other US biometric statute compliance, or consent language guidance for legal review.

   ⚑ flag

Redaction

1. 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 drawn
   Stripe Identity—none0/10

   The 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…”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence covers session creation, decisions, webhooks, HMAC auth, and manual review in the portal, but nothing documents data retention windows or a redaction/deletion API for scrubbing PII on demand.

   ⚑ flag

Hosted flows

1. 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 to Veriff
   Stripe Identity✓fullcommunity7/10

   Docs 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…”

   proof ↗⚑ flag

   Veriff✓fullclaimed8/10

   Docs confirm the core flow: create a session server-side via POST /v1/sessions, bring the end-user to verification via hosted or embedded web/native SDKs, and read results via webhook or by polling the decision endpoint — covering document+selfie/liveness capture without building custom capture UI. missing for 10: no independent/hands-on developer corroboration of the end-to-end flow and no explicit confirmation that both document and selfie capture are bundled by default in the hosted flow.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”
   • [claimed-docs] “No-code identity verification solution”

   proof ↗⚑ flag

Native sdks

1. 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 Veriff
   Stripe Identity—none0/10

   The 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…”

   proof ↗⚑ flag

   Veriff~partialclaimed3/10

   Docs confirm native and web SDKs exist for bringing users into the verification flow, but there is no evidence describing guided capture UX details like glare, blur, or edge detection coaching. missing for 10: SDK feature documentation on real-time image quality checks, glare/blur detection, edge detection guidance, and any independent/hands-on validation of first-try capture success.

   • [claimed-docs] “Bring the end-user to verification flow using web or native SDKs”
   • [claimed-docs] “Veriff Biometric Liveness solution ensures that the biometric data being captured is from a live person, significantly reducing the risk of …”

   proof ↗⚑ flag

No code

1. 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 Identity
   Stripe Identity✓fullcommunity7/10

   Stripe 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…”

   proof ↗⚑ flag

   Veriff~partialclaimed4/10

   Veriff explicitly advertises a 'No-code identity verification solution' (veriff-docs-4) and a Customer Portal for managing verifications (veriff-docs-12/13), suggesting some no-code capability exists, but the evidence pack never details a shareable link or QR-code workflow, session creation without API/engineering involvement, or a portal UI for generating one-off verification requests. Missing for 10: explicit documentation of link/QR-code generation in the portal, confirmation that ops staff (not engineers) can trigger sessions without API calls, and any UI screenshots or workflow docs for one-off verification requests.

   • [claimed-docs] “No-code identity verification solution”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ flag

Reuse

1. 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 drawn
   Stripe Identity—none0/10

   Docs 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.”

   proof ↗⚑ flag

   Veriff—none0/10

   The evidence pack covers session creation, decisions, webhooks, HMAC auth, and manual review, but nothing documents identity reuse/portability — e.g., a 'reuse prior passed verification' or cross-session/cross-product identity linking feature. Each session creation doc (veriff-docs-6) implies a fresh verification flow rather than recognizing a previously verified person.

   • [claimed-docs] “Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”

   proof ↗⚑ flag

Analytics

1. 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 drawn
   Stripe Identity—none0/10

   Evidence 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.”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence covers session creation, webhooks, HMAC auth, manual review portal, and PDF export, but nothing describes funnel analytics, pass-rate dashboards, drop-off analysis, completion-time metrics, or breakdowns by country/document type.

   ⚑ flag

Review

1. 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 drawn
   Stripe Identity~partialclaimed5/10

   Docs 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.”

   proof ↗⚑ flag

   Veriff~partialclaimed5/10

   Docs confirm a manual review queue exists in the Veriff Customer Portal (Verifications page) where sessions can be reviewed and decisions triggered/exported, and webhooks/API decision endpoints propagate results back into the record. However, the evidence pack does not detail what evidence reviewers see (document images, extracted fields, check results) or explicitly describe how reviewer decisions are written back to the underlying verification record beyond the decision endpoint. Missing for 10: documentation of the reviewer UI's evidence display (images/fields/check results), explicit reviewer-decision-to-record feedback mechanism, and independent/hands-on corroboration.

   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “You can trigger decisions for test integration sessions.”
   • [claimed-docs] “Secondary: Poll `GET /v1/sessions/{id}/decision` endpoint”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”

   proof ↗⚑ flag

Workflows

1. 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 drawn
   Stripe Identity~partialcommunity3/10

   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…”

   proof ↗⚑ flag

   Veriff~partialclaimed3/10

   The devdocs reference a 'No-code identity verification solution' and a Customer Portal for managing verification sessions/decisions, suggesting some no-code configuration exists, but there is no concrete evidence of conditional step logic, risk-based routing, country-specific requirement rules, or template editing without an engineering deploy. missing for 10: documented conditional/branching logic builder, risk-based routing rules, country-specific requirement configuration, and template editing workflow evidence.

   • [claimed-docs] “No-code identity verification solution”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”

   proof ↗⚑ flag

Monitoring

1. 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 drawn
   Stripe Identity—none0/10

   Stripe 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.”

   proof ↗⚑ flag

   Veriff—none0/10

   Evidence only shows a one-time PEP & Sanctions check at verification time and generic webhooks for session decisions; there is no mention of continuous re-screening of previously verified users against updated watchlists or of events triggered by post-verification watchlist changes.

   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Set up webhooks to get responses from Veriff”

   proof ↗⚑ flag

Screening

1. 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 Veriff
   Stripe Identity—none0/10

   Evidence 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.

   ⚑ flag

   Veriff~partialclaimed6/10

   Veriff's pricing page confirms a PEP & Sanctions check add-on ($0.64) that integrates into the same verification flow/API, and the Customer Portal already supports manual review of verification sessions, suggesting one vendor/API for both identity and watchlist screening. However, adverse-media screening is not explicitly mentioned, and there's no dedicated documentation showing watchlist hits surfaced in the same review UI as biometric/identity results. Missing for 10: explicit adverse-media watchlist coverage, and documentation showing unified review surface combining identity + watchlist results.

   • [claimed-docs] “PEP & Sanctions check (+$0.64)”
   • [claimed-docs] “Learn how to manually review and manage verification sessions in the Veriff Customer Portal.”
   • [claimed-docs] “Manually: the **Verifications page in the** Veriff Customer Portal”
   • [claimed-docs] “Export verification session details to PDF”

   proof ↗⚑ flag