Stripe Issuing vs Highnote

Agent access

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

   weight 2 · round to Highnote
   Stripe Issuing✓fullprobed8/10

   Stripe's docs.stripe.com/llms.txt returns HTTP 200 and .md variants of docs pages (e.g., issuing.md, mcp.md) are directly accessible, confirming agent-oriented documentation formats exist and are served for Issuing docs. There's also an official MCP server for AI agents to interact with the Stripe API. missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully for Issuing-specific tasks, and no explicit Issuing-specific llms.txt (only the site-wide one).

   • [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/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Highnote✓fullprobed9/10

   Direct probe confirms a live llms.txt at docs.highnote.com/llms.txt returning HTTP 200 with structured documentation content, and Highnote also publishes an agent-oriented markdown doc (agentic-commerce.md) explicitly designed for agent consumption. Missing for 10: no independent third-party report of an agent successfully using llms.txt to complete a task.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Issuing
   Stripe Issuing✓fullprobed8/10

   Stripe Issuing exposes a complete REST API for creating cards/cardholders, real-time authorization webhooks, and a documented test-simulation mode for pre-production automation, plus an official CLI (stripe-cli) — all consistent with headless/CI operation. Community evidence confirms real-world usage of the API for automated QA workflows. missing for 10: explicit CI/pipeline integration guides or SDK examples showing scripted deployment in CI systems.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Test the integration: Simulate test purchases before going live.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”

   proof ↗⚑ flag

   Highnote~partialprobed6/10

   Highnote is an API/GraphQL-first platform with a Node.js SDK, webhooks, and a full-featured Test environment that mirrors Live functionality, all of which support running interactions programmatically without a UI (e.g., in CI or automated pipelines). However, there is no explicit documentation of a CLI, CI pipeline integration, or headless automation guidance beyond the general API/SDK access. Missing for 10: explicit CI/CD integration guides, a documented CLI or headless mode, and independent confirmation of automated pipeline usage.

   • [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Issuing
   Stripe Issuing✓fullprobed7/10

   Stripe documents an official MCP server that lets AI agents interact with the Stripe API (which includes Issuing endpoints) and search its knowledge base, confirmed by both docs and a probe hit at docs.stripe.com/mcp. However, the evidence doesn't detail Issuing-specific MCP tools or independent hands-on confirmation of agent usage with Issuing specifically. Missing for 10: explicit list of Issuing-specific MCP tool calls, independent/community verification of agent integration.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Highnote—none0/10

   Highnote is a card-issuance/payments platform, not an agent itself, so the MCP-server axis applies, but no evidence in the pack mentions an MCP server, MCP protocol, or agent-connection endpoint of any kind — only GraphQL API, SDKs, and webhooks are documented.

   • [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Stripe documents an official CLI (stripe-issuing-probe-5) as part of the broader Stripe platform, which would apply to Issuing API usage, but the evidence pack contains no Issuing-specific CLI commands, examples, or independent hands-on confirmation of CLI use for Issuing workflows. missing for 10: Issuing-specific CLI command examples, hands-on/community confirmation of using the CLI for Issuing tasks, documentation tying the CLI explicitly to agentic/AI-native workflows.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Highnote—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 to Stripe Issuing
   Stripe Issuing✓fullprobed9/10

   Stripe Issuing exposes a comprehensive, well-documented REST API covering cards, cardholders, webhooks, disputes, spending controls, and funding, plus an official CLI and MCP server for programmatic/agentic access, corroborated by a live probe of docs and community reports of API-driven automation. missing for 10: a directly reachable machine-readable OpenAPI spec (probe returned 404 on standard paths).

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
   • [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/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
   • [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”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”

   proof ↗⚑ flag

   Highnote✓fullprobed8/10

   Highnote exposes a documented GraphQL API (with interactive code explorer), an official Node.js SDK wrapping it, webhooks, and a test environment mirroring live functionality, all of which let an AI-native user drive the product programmatically end-to-end including agentic card issuance workflows. missing for 10: a public OpenAPI/swagger spec (probe found 404s on standard OpenAPI paths) and independent third-party corroboration of API usability beyond vendor docs.

   • [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Issuing
   Stripe Issuing✓fullclaimed8/10

   Stripe Issuing has a dedicated agents doc describing issuing virtual cards scoped to a single task/session that auto-invalidate after use, plus fine-grained spending controls (merchant category, country, amount limits) and real-time authorization webhooks that let an issuer approve/decline per-transaction — together these constitute least-privilege, scoped credential issuance for agentic use. missing for 10: independent/hands-on third-party validation of the agent-scoping feature specifically (only vendor docs), and no evidence of programmatic revocation/audit-trail APIs tailored to agent credential lifecycle beyond card invalidation.

   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”

   proof ↗⚑ flag

   Highnote—none0/10

   Highnote's evidence covers issuing scoped payment cards per agent with spend/velocity controls, but this is a financial-transaction spend-control mechanism, not API credential scoping (e.g., API keys/tokens with least-privilege permissions for programmatic access). There is no mention of scoped API keys, OAuth tokens, or role-based API credentials for agents to call Highnote's own API. missing for 10: evidence of scoped/least-privilege API credential or token issuance for agents accessing the Highnote API itself, permission/role management for API keys, documentation of API-level access control distinct from card spend controls.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Issuing~partialprobed6/10

   Stripe's docs reference the Issuing API and general Stripe SDK/CLI/MCP infrastructure, implying official SDKs exist for building Issuing integrations, but the evidence pack contains no direct mention of language-specific SDK libraries (e.g., stripe-node, stripe-python) or their coverage of Issuing endpoints specifically. missing for 10: explicit documentation of official SDK libraries and language coverage for Issuing, code samples showing SDK usage for Issuing objects, independent developer corroboration of SDK quality for Issuing specifically.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”

   proof ↗⚑ flag

   Highnote~partialprobed6/10

   Highnote documents an official Node.js SDK (currently in beta) plus PCI-compliant client SDKs for embedding sensitive card data and checkout flows, indicating a real official-SDK path beyond raw GraphQL. However, the core API remains GraphQL-first and the flagship SDK is explicitly beta, with no evidence of SDKs in other major languages, no independent/community corroboration of SDK quality, and OpenAPI spec probes returned 404s. missing for 10: multi-language SDK coverage, GA (non-beta) status, independent developer corroboration, and a public OpenAPI/type-generation artifact.

   • [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
   • [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
   • [claimed-docs] “Accept payment card details in a configured checkout experience”
   • [claimed-docs] “Collect identity verification documents from account holders when a card product application enters manual review”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Highnote
   Stripe Issuing~partialclaimed5/10

   Docs confirm Issuing supports a synchronous webhook for real-time authorization decisions, showing webhook-based event delivery exists, but the pack contains no evidence of broader webhook event subscription (e.g., issuing_card.*, issuing_dispute.* events, webhook endpoint management API) that a general 'subscribe to events' story implies. Missing for 10: documentation of the full Issuing webhook event catalog, webhook endpoint setup/management API, and any AI-native tooling (e.g. MCP) for consuming these events.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”

   proof ↗⚑ flag

   Highnote✓fullclaimed8/10

   Highnote docs explicitly describe configurable webhook notification targets, choosing which events are delivered to each webhook, and signing key rotation for verifying payloads, plus general mention of 'real-time webhooks' as a core dev feature. This directly matches the story of subscribing to events via webhooks. Missing for 10: no independent/hands-on corroboration of webhook reliability or a full event-type catalog, and no explicit mention of AI-agent-specific webhook use cases.

   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Stripe Issuing
   Stripe Issuing~partialclaimed3/10

   Docs mention machine-learning-generated risk scores (fraud, dispute risk, card testing) surfaced on every authorization, which is a narrow form of AI-generated insight from transaction data, but there's no evidence of broader in-product AI insights/suggestions (e.g., spend analytics, natural-language querying, dashboard copilot) beyond this fraud-risk scoring. Missing for 10: evidence of general AI-generated insights/suggestions across spending data, dashboard-level AI summaries, or proactive recommendations beyond fraud risk scoring.

   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”

   proof ↗⚑ flag

   Highnote—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

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

   weight 2 · round to Stripe Issuing
   Stripe Issuing✓fullprobed7/10

   Stripe Issuing exposes real-time authorization webhooks, spending controls, and agent-specific virtual cards that auto-invalidate after a task/session (docs-4, docs-5, docs-12, docs-13), enabling autonomous, unattended card issuance and approval flows. It also ships an official MCP server so AI agents can drive the Issuing API programmatically (docs-16, probe-4), supporting background automation setups. Missing for 10: independent/hands-on evidence of a fully autonomous end-to-end automation running in production, and more detail on scheduling/orchestration beyond webhook-triggered decisions.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Highnote's agentic-commerce docs describe automations that run without human intervention — per-agent card issuance that auto-closes when a workflow ends, spend rules and velocity controls evaluated automatically at authorization, and webhooks for event-driven notifications — which functions as background autonomous automation for payment operations. However this is scoped narrowly to card/spend automation rather than a general-purpose automation/scheduling engine for AI agents, and there's no evidence of a broader trigger/scheduler system or independent corroboration of these claims. Missing for 10: general-purpose scheduled/triggered automation beyond payments, independent/hands-on validation of autonomous behavior.

   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”

   proof ↗⚑ flag

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

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

   Stripe documents an official MCP server that lets AI agents interact with the Stripe API (including Issuing) via natural-language-driven tool calls, and separately markets Issuing itself for agentic/AI-driven card issuance. However there's no hands-on evidence of natural-language command execution specifically against Issuing endpoints, and the CLI (a non-NL surface) is the only other control surface mentioned. Missing for 10: independent/hands-on proof of NL commands operating Issuing resources, documentation of MCP tool coverage for Issuing-specific actions.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”

   proof ↗⚑ flag

   Highnote—none0/10

   Highnote's evidence describes a GraphQL API, SDKs, and dashboard for card issuance/payments, with no mention of a natural-language command interface, chatbot, or conversational control layer for operating the platform. While the docs discuss enabling AI agents to *use* cards programmatically, there is no evidence that a human or agent can *operate Highnote itself* via natural-language commands.

   • [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Highnote
   Stripe Issuing~partialprobed3/10

   The evidence pack shows Stripe publishes detailed API reference pages for Issuing endpoints (cards, cardholders, etc.) and markdown-accessible docs, but nothing explicitly confirms an interactive, runnable-example experience (e.g., live code sandboxes or in-browser request execution) — the OpenAPI spec probe even returned 404s. Missing for 10: explicit documentation or demonstration of runnable/interactive code snippets, live API console, or sandboxed example execution within the reference pages.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
   • [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

   Highnote~partialprobed5/10

   Highnote docs mention an "interactive code explorer" as part of building with the GraphQL API, and testing environment lets you simulate real-time transactions, suggesting some runnable/interactive documentation exists. However, there's no direct evidence of a live, embedded interactive API reference (e.g., no OpenAPI spec found, probes for openapi.json all 404), and no independent confirmation of runnable examples in the docs. Missing for 10: concrete demonstration or screenshot of the interactive code explorer, confirmation that examples can be executed directly from docs, and independent/hands-on corroboration.

   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Issuing—none0/10

   The evidence pack shows explicit probing for OpenAPI/Swagger spec endpoints on docs.stripe.com all returned 404, and no other citation confirms a downloadable OpenAPI or equivalent machine-readable spec; only markdown docs and llms.txt are shown to work.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [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/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote—none0/10

   Highnote's API is GraphQL-based, and explicit probes for standard OpenAPI/swagger spec paths all returned 404, with no evidence of any downloadable machine-readable spec (OpenAPI, GraphQL SDL, or introspection export) offered elsewhere. missing for 10: a published OpenAPI/GraphQL schema file, a documented download/export endpoint, any mention of schema introspection support.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”

   proof ↗⚑ flag

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

   weight 1 · round to Highnote
   Stripe Issuing~partialcommunity6/10

   Docs explicitly mention simulating test purchases before going live, and community evidence shows a user relying on the API for QA/test automation, supporting a sandbox-style workflow. However, there's no detailed documentation of Stripe's standard test-mode/live-mode key separation or confirmation that all Issuing features (card issuance, authorizations) work identically in test mode without any production side-effects. missing for 10: explicit test-mode vs live-mode API key documentation, hands-on confirmation of full feature parity in test mode, independent verification of sandbox fidelity.

   • [claimed-docs] “Test the integration: Simulate test purchases before going live.”
   • [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”

   proof ↗⚑ flag

   Highnote✓fullclaimed8/10

   Highnote explicitly documents a Test environment that replicates full Live functionality, allowing simulation of real-time transactions and compliance scenarios without touching production/live data, and this is directly tied to API development workflows relevant to agentic/AI-native usage. Missing for 10: independent/hands-on corroboration of the sandbox's fidelity and details on how test data is isolated or reset.

   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Issuing—none0/10

   The evidence pack covers Issuing features (cards, cardholders, controls, agents, MCP) but contains no documentation of API versioning scheme or a deprecation policy. Missing for 10: any docs page or changelog describing dated API versions, backward-compatibility guarantees, or deprecation timelines.

   ⚑ flag

   Highnote—none0/10

   No evidence pack item mentions API versioning scheme, version headers, or any documented deprecation policy; even the OpenAPI spec probe returned 404s. missing for 10: versioning scheme documentation, deprecation/sunset policy, changelog or migration guides.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

Auth context

1. developerEvery authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   The evidence covers real-time authorization webhooks, spending controls (merchant category, MID), risk scores, and wallet support, but there is no evidence that Stripe surfaces MCC codes, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth signals within the authorization payload itself. Missing for 10: explicit documentation of MCC field, enhanced merchant metadata, wallet/entry-mode indicators, and partial-approval/incremental-auth signal support in the authorization object.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
   • [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”

   proof ↗⚑ flag

   Highnote~partialclaimed3/10

   Docs confirm authorization-time data such as MCC-based spend rules and real-time collaborative-authorization decisioning, implying some transaction context is passed to business logic, but there is no evidence of enhanced merchant data, wallet/entry-mode details, partial-approval, or incremental-auth signals being exposed. missing for 10: merchant name/enhanced merchant data fields, wallet and entry-mode details, partial-approval signals, incremental-auth signals.

   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”

   proof ↗⚑ flag

Auth stream

1. developerApprove or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control

   weight 3 · round drawn
   Stripe Issuing~partialclaimed6/10

   Stripe Issuing explicitly documents a synchronous webhook for real-time authorization approve/decline decisions, matching the core of the story. However, the evidence pack does not show documentation of the exact timeout window or how developers can configure/control the fallback (approve/decline) behavior when their endpoint doesn't respond in time. Missing for 10: explicit timeout budget details, developer-configurable fallback decision, and independent/hands-on confirmation of real-time latency behavior.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Highnote's Collaborative Authorization feature explicitly lets developers approve/decline transactions in real time via their own business logic, and webhooks/notification targets are documented with signing-key rotation for verification. However, the evidence pack lacks specifics on the exact time budget the network/webhook enforces, or a documented timeout fallback behavior developers can configure if their endpoint doesn't respond in time. missing for 10: documented response time budget/SLA for the collaborative authorization webhook, explicit fallback/timeout behavior (e.g. default approve/decline on timeout) that developers can configure, and independent/hands-on confirmation of real-time latency behavior.

   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”

   proof ↗⚑ flag

Simulation

1. developerSimulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes

   weight 2 · round to Highnote
   Stripe Issuing~partialprobed4/10

   Docs confirm a sandbox/test mode exists ("Simulate test purchases before going live") and separately describe real-time authorization webhooks and spending-control declines, which together imply some lifecycle testing capability. However, no evidence explicitly documents simulating clearings, reversals, or refunds in the test environment, only authorizations/purchases and controls-based declines. Missing for 10: explicit documentation/tooling for simulating clearing, reversal, and refund events in sandbox, and any independent/hands-on confirmation that the full lifecycle can be tested end-to-end.

   • [claimed-docs] “Test the integration: Simulate test purchases before going live.”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Highnote documents a full-featured Test environment that 'replicates the full functionality of the Live environment' and lets developers 'simulate real-time transactions and compliance scenarios' [highnote-docs-11], plus API support for the full authorization→capture→refund lifecycle [highnote-docs-20] and real-time approve/decline logic via collaborative authorization [highnote-docs-7]. However, the pack never explicitly confirms simulation of clearings or reversals specifically, or a documented list of simulated transaction states/test cards for each lifecycle stage. Missing for 10: explicit documentation of clearing/reversal simulation, test-card/scenario catalog enumerating each transaction state, and independent developer confirmation of sandbox fidelity.

   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”

   proof ↗⚑ flag

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

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   Stripe Issuing's documented API only shows single-resource create endpoints for cards and cardholders, with no evidence of batch/bulk endpoints or documented patterns for issuing or managing many cards/cardholders in one call. While an API-driven product could plausibly support bulk automation, the evidence pack contains nothing about batch operations, bulk imports, or multi-item API calls.

   ⚑ flag

   Highnote~partialclaimed4/10

   Highnote's docs show program-level rule application across all cards (docs-21) and per-agent card issuance/closure (docs-17), which imply some scale-level automation, but there is no explicit documentation of bulk/batch API operations (e.g., batch mutations, bulk export, multi-item update endpoints) that would let an AI-native user act on many items in one call. Missing for 10: explicit bulk/batch API endpoints or mutations, batch processing docs, and evidence of pagination/bulk query support for acting on many records at once.

   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Issuing~partialclaimed6/10

   Stripe Issuing supports rule-like automation via spending controls (block by MCC, country, merchant ID, card presence, spending limits) and synchronous webhooks that programmatically approve/decline authorizations in real time, which is a form of event-triggered automated action. However, this is scoped narrowly to authorization events rather than a general-purpose rule engine for arbitrary triggers/actions across the product. Missing for 10: evidence of a broader declarative rules/automation framework beyond authorization controls, and independent/hands-on validation of custom rule logic in production.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Highnote supports rule-based automated actions on events via spend rules, velocity controls, and collaborative authorization that automatically permit/restrict transactions based on business logic, plus webhooks that deliver configurable events to trigger downstream actions. However, these are financial/authorization-specific rules (MCC, amount, velocity) rather than a general-purpose event-condition-action automation engine, and there's no evidence of user-defined arbitrary triggers/actions spanning non-payment events. Missing for 10: a general rules engine beyond payment authorization scenarios, evidence of custom trigger definitions outside spend/velocity/collaborative-auth constructs, and independent confirmation of automation reliability at scale.

   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”

   proof ↗⚑ flag

Lifecycle states

1. developerThe full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close

   weight 2 · round to Stripe Issuing
   Stripe Issuing~partialclaimed5/10

   Docs confirm card creation, cardholder creation, and replacement of lost/stolen/expired/damaged cards via API (docs-1, docs-3, docs-7), which covers reissue-with-replacement-link and lost/stolen reporting in spirit, but the evidence pack never explicitly documents API calls for activating, pausing/unpausing a card's status, or permanently closing a card. missing for 10: explicit API docs for activate/pause/unpause status transitions, explicit 'permanently close' endpoint, and confirmation that the replacement card is API-linked to the original card object.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”

   proof ↗⚑ flag

   Highnote~partialclaimed3/10

   Docs confirm cards can be created and 'managed' via API (highnote-docs-1) and that agentic-use cards 'close automatically' via API (highnote-docs-17), implying some lifecycle control, but there is no explicit documentation of activate, pause/unpause, report-lost-or-stolen, or reissue-with-linked-replacement mutations. missing for 10: explicit API mutations/docs for pause, unpause, lost/stolen reporting, and reissue linked to original card, and confirmation these are exposed as first-class API operations.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”

   proof ↗⚑ flag

Physical cards

1. ops userOrder personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself

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

   Docs confirm API-driven physical card issuance with custom card art/logo (docs-1, docs-2, docs-8) and Stripe handles printing/shipping without an ops-managed manufacturer relationship, plus replacement cards for lost/damaged/stolen (docs-7). However, there is no explicit evidence of bulk ordering workflows, choice of shipping methods, or shipment tracking details in the API. Missing for 10: bulk order API/batch issuance evidence, shipping method selection, and tracking number/status documentation.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “A physical card will be printed and shipped. It can be used at physical terminals.”
   • [claimed-docs] “Configure the appearance of your physical cards, such as by adding a company logo, and customize the accompanying content.”
   • [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”

   proof ↗⚑ flag

   Highnote~partialclaimed3/10

   Docs confirm Highnote supports issuing physical (not just virtual) cards via API alongside virtual/tokenized cards, but no evidence details custom card art, bulk ordering, shipping method selection, or shipment tracking capabilities. missing for 10: custom card art/design upload, bulk order API, shipping method selection, tracking integration, evidence of not needing a separate card manufacturer relationship.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”

   proof ↗⚑ flag

Virtual cards

1. developerCreate a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cycle

   weight 3 · round drawn
   Stripe Issuing~partialprobed5/10

   Docs confirm a single API call creates an Issuing Card object and that sandbox-mode purchase simulation exists before going live, supporting the core lifecycle claim. However, the evidence pack never explicitly confirms that PAN, CVV, and expiry are returned/retrievable programmatically at issuance, nor does it document that moving from test to live mode requires no approval or sales process (Issuing often needs business verification). missing for 10: explicit API field/endpoint returning PAN+CVV+expiry, documentation of frictionless sandbox-to-live activation without account review.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Test the integration: Simulate test purchases before going live.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote~partialclaimed5/10

   Docs confirm virtual card issuance via GraphQL API and a full-featured test/sandbox environment (highnote-docs-4, highnote-docs-11), plus PCI-compliant SDKs for embedding sensitive card data (highnote-docs-14). However, issuance requires an account holder with an approved application first (highnote-docs-4), implying a multi-step onboarding rather than a single API call, and there is no evidence of self-serve sandbox-to-live activation without a compliance/sales process (KYC/KYB is handled by an in-house team per highnote-docs-23). Missing for 10: explicit single-call PAN/CVV/expiry issuance example, and documented self-serve path from sandbox to live production without manual review/sales engagement.

   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”

   proof ↗⚑ flag

Agent cards

1. ai-native userGive an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name

   weight 3 · round drawn
   Stripe Issuing✓fullclaimed8/10

   Stripe documents a dedicated agents.md page describing virtual cards scoped to a single task/session that auto-invalidate after use, combined with spending controls (merchant category/ID/country locks, per-authorization/monthly amount caps) and real-time authorization webhooks, directly matching the story's named use case. missing for 10: independent/hands-on third-party corroboration of the agent-specific card flow (only vendor docs cited), and no explicit example of setting card expiry alongside merchant locks in a single documented workflow.

   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Creates an Issuing `Card` object.”

   proof ↗⚑ flag

   Highnote✓fullclaimed8/10

   Highnote explicitly documents issuing per-agent virtual cards with merchant category restrictions, velocity limits, and per-transaction caps enforced at authorization, plus auto-closing cards when a workflow ends, directly naming the agentic-commerce use case. Missing for 10: no explicit mention of a hard expiry field/date on agent cards (only workflow-end auto-closure) and no independent/hands-on corroboration of the feature working in production.

   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials

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

   Stripe Issuing offers full API coverage for card/cardholder creation, spend controls, and an agents-specific doc describing task-scoped single-use virtual cards with ML risk scoring, plus a documented official MCP server. However, the evidence doesn't show the MCP server exposing Issuing-specific tools (balances, transactions, card/spend-control management) or confirm scoped/limited credentials for agent use via MCP rather than just full API keys. missing for 10: evidence of MCP server exposing Issuing read/write tools (balances, transactions, card updates, spend control adjustments), and evidence of scoped/restricted API keys for agent use.

   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Highnote~partialprobed5/10

   Highnote's API/GraphQL surface clearly supports agent-driven card issuance, spend controls (velocity, MCC, per-transaction caps), balance/transaction ledger visibility, and even an agentic-commerce solution page describing per-agent card issuance and program-level rule enforcement. However, there is no evidence of an MCP server or MCP-scoped credential surface, and no explicit documentation of scoped API credentials/permissions specifically for agent use (e.g., agent-specific API keys with restricted scopes) — the OpenAPI spec itself is not discoverable (404s), suggesting limited machine-readable API surface for agent tooling. missing for 10: an official MCP server/integration, documented scoped-credential mechanism for agents, and a discoverable OpenAPI/schema for programmatic tool generation.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

Kyc

1. ops userCardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   The evidence pack covers card creation, cardholder objects, spending controls, disputes, and agent-scoped virtual cards, but contains no documentation of KYC/KYB data requirements, cardholder verification review states, or re-verification workflows. Cardholder identity verification is a plausible and expected axis for a card-issuing platform, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Docs confirm in-house KYC/KYB compliance handling, account holder application approval flow, manual review state with identity document collection, and internal notes for servicing — covering the core of the story. However, there's no documented breakdown of specific data requirements per verification type, no explicit re-verification/periodic refresh flow, and review-state transitions beyond 'manual review' aren't detailed. Missing for 10: documented data requirements per KYC/KYB type, explicit re-verification/refresh flows, and full review-state lifecycle documentation.

   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
   • [claimed-docs] “Collect identity verification documents from account holders when a card product application enters manual review”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
   • [claimed-docs] “you can use the following mutation to allow your agents to add notes to a financial account. Adding notes is useful for various internal ser…”

   proof ↗⚑ flag

Pci scope

1. developerShow cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   The evidence pack covers card creation, controls, disputes, funding, and agent-scoped virtual cards, but contains no mention of PAN/CVV reveal UI, hosted Elements components, or ephemeral key issuance for reducing PCI SAQ D scope. Missing for 10: documentation of hosted card reveal components (e.g., Stripe Elements 'Issuing Elements'), ephemeral key generation for PAN/CVV display, and explicit PCI SAQ A/D scope-reduction claims.

   ⚑ flag

   Highnote~partialclaimed6/10

   Highnote documents SDKs specifically designed to embed sensitive card data (PAN/CVV) in a developer's UI while keeping raw PCI data out of their systems ("Embed sensitive card data in your UI and avoid PCI data from being compromised"), and its docs site markets "PCI-compliant SDKs" as a core offering. However, the evidence lacks explicit detail on ephemeral-key reveal mechanics, SAQ D scope reduction claims, or independent/hands-on confirmation that this actually keeps a developer out of SAQ D. Missing for 10: explicit SAQ-level scope claims, technical detail on the reveal flow (ephemeral keys, hosted iframe/component architecture), and third-party/compliance corroboration.

   • [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
   • [claimed-docs] “Accept payment card details in a configured checkout experience”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”

   proof ↗⚑ flag

Dispute filing

1. ops userFile and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution

   weight 2 · round to Stripe Issuing
   Stripe Issuing~partialclaimed4/10

   Stripe confirms an API + Dashboard flow to submit and monitor Issuing disputes through resolution, but the evidence pack gives no detail on network reason codes, evidence submission fields, provisional credit handling, or dispute-specific status webhooks. Missing for 10: reason-code taxonomy documentation, evidence-submission API specifics, provisional credit mechanics, and dispute webhook event examples.

   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”

   proof ↗⚑ flag

   Highnote~partialclaimed3/10

   Highnote documents a dedicated Disputes Team and processes for dispute/chargeback handling, and separately offers generic webhook notifications, but the evidence never confirms programmatic dispute filing via API, network reason codes, evidence submission endpoints, provisional credit handling, or dispute-specific status webhooks through resolution. Missing for 10: reason code taxonomy, evidence-submission API, provisional credit mechanics, dispute status webhook events, and any confirmation that filing/tracking is API-driven rather than handled manually by Highnote's in-house team.

   • [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”

   proof ↗⚑ flag

Fraud monitoring

1. ops userThe platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cards

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

   Docs show real-time authorization webhooks for approve/decline, ML-generated risk scores (fraud risk, merchant dispute risk, card testing detection) surfaced at authorization, spending controls to block merchant categories/countries, and replacement-card issuance for lost/stolen/damaged cards, plus a dispute workflow. However, there is no explicit documentation of a dedicated suspicious-activity alerting/notification system for ops, nor clear card-level 'freeze/block' tooling distinct from spending controls. missing for 10: explicit suspicious-activity alert mechanism, explicit card status/block (vs. reissue) API evidence, independent/hands-on corroboration of fraud-score accuracy.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
   • [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”

   proof ↗⚑ flag

   Highnote~partialclaimed4/10

   Highnote provides real-time authorization controls (collaborative authorization, spend rules, velocity controls) that could incorporate custom fraud logic, plus a Disputes Team for chargebacks and account notes for servicing, but evidence never mentions network fraud scores, in-house fraud models surfaced at auth, dedicated suspicious-activity alerts, or explicit card block/reissue tooling for compromised cards. Missing for 10: fraud-score/model evidence at authorization, suspicious-activity alerting, and documented card block-and-reissue workflow.

   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
   • [claimed-docs] “you can use the following mutation to allow your agents to add notes to a financial account. Adding notes is useful for various internal ser…”

   proof ↗⚑ flag

Balances

1. finance leadSee money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny

   weight 3 · round to Highnote
   Stripe Issuing~partialclaimed4/10

   Docs show real-time authorization webhooks, funding balance/bank details, and dispute handling, implying underlying ledger and clearing mechanics, but there is no explicit documentation of a transaction ledger that ties authorizations to clearing or of settlement reporting that reconciles to the penny. Missing for 10: dedicated ledger/transaction API description, settlement reporting/reconciliation tools, and evidence of penny-accurate reconciliation.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Docs describe an integrated ledger that tracks balances and posts every transaction in real time (not batched), and the platform's in-house team handles daily reconciliation and settlement, which aligns with the finance-lead need for real-time money movement visibility. However, there is no explicit documentation of settlement reports reconciling to the penny, no detail on how authorizations tie to clearing entries in the ledger, and no independent/hands-on corroboration of reconciliation accuracy. Missing for 10: explicit settlement reporting docs/screenshots, authorization-to-clearing ledger linkage detail, and third-party verification of reconciliation accuracy.

   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”

   proof ↗⚑ flag

Recon reports

1. finance leadI get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   The evidence pack covers card creation, controls, disputes, funding, and agent-specific virtual cards, but contains no mention of settlement files, interchange/fee reporting, or reconciliation report APIs that a finance stack could consume. Missing for 10: any documentation of daily settlement/report files, interchange or fee breakdowns, or reconciliation API endpoints.

   ⚑ flag

   Highnote~partialclaimed4/10

   Highnote documents an integrated, transaction-level ledger and states its in-house teams handle 'daily reconciliation, settlement' plus real-time webhooks for events, suggesting some machine-consumable data exists. However, there is no explicit documentation of settlement files or report APIs that itemize interchange, fees, or network adjustments for finance-stack consumption. Missing for 10: dedicated reconciliation/settlement report API or file export, interchange/fee/network-adjustment breakdown fields, and confirmation the ledger data is structured for automated finance-system ingestion.

   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
   • [claimed-docs] “You can configure specific events to be delivered to each webhook”

   proof ↗⚑ flag

Settlement events

1. developerPost-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts

   weight 2 · round to Highnote
   Stripe Issuing~partialclaimed3/10

   Docs mention a synchronous webhook for real-time authorization decisions and a separate API/dashboard flow for disputes, implying some post-auth event handling, but the pack never documents webhook events for clearings, refunds, or reversals, nor stable transaction identifiers for ledger reconciliation. Missing for 10: explicit webhook events for captures/refunds/reversals, documentation of a Transaction object with stable IDs, and confirmation that disputes/chargebacks are delivered via webhook rather than only dashboard/API polling.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”

   proof ↗⚑ flag

   Highnote~partialclaimed6/10

   Highnote's docs confirm a configurable webhook/events system (highnote-docs-12,13), a unified transaction-level ledger (highnote-docs-3,19), programmatic refund/capture across the payment lifecycle (highnote-docs-20), and a dedicated disputes/chargeback process (highnote-docs-10), which together support post-auth events flowing to a developer's own ledger. However, the evidence never explicitly enumerates clearing/reversal/chargeback as distinct webhook event types or confirms stable transaction identifiers tying these events together across the lifecycle. Missing for 10: explicit webhook event-type list showing clearings/reversals/chargebacks, and documentation of a stable transaction ID field used consistently across auth→settlement→dispute events.

   • [claimed-docs] “You can configure specific events to be delivered to each webhook”
   • [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
   • [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Issuing
   Stripe Issuing~partialprobed7/10

   Stripe Issuing is API-first: cards, cardholders, spending controls, disputes, funding, and even agent-specific ephemeral virtual cards are all documented as API operations, and community evidence confirms teams building entirely on the API. However, some dashboard-only conveniences (physical card design/appearance configuration, guided dispute UX, some Connect platform setup flows) are described primarily through the Dashboard with API as a secondary/parallel path, and there's no independent audit confirming 1:1 parity between UI and API surface area. missing for 10: independent verification of full UI/API parity, explicit API equivalents for all dashboard-guided workflows (e.g., card design/appearance, guided dispute UI), and a published OpenAPI spec (probe found only 404s).

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Issue cards to connected accounts: Learn how to issue cards as a Connect platform to third parties represented as connected accounts.”
   • [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
   • [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

   Highnote~partialprobed6/10

   Highnote is documented as an API-first platform (GraphQL API, typed SDKs, webhooks) with broad coverage of issuing, spend controls, ledger, disputes, and account management all exposed via API, and the Test environment is said to 'replicate the full functionality' of Live. However, there is no explicit statement that the dashboard/UI has 100% parity with the API (no confirmation that every dashboard action, e.g. dispute case management or manual reviews, is scriptable via API), and no OpenAPI/Swagger spec was discoverable via probe. Missing for 10: an explicit UI/API parity statement or documentation section, and a discoverable machine-readable API spec confirming full surface coverage.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
   • [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
   • [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”

   proof ↗⚑ flag

Card types

1. founderThe platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail

   weight 2 · round to Highnote
   Stripe Issuing—none0/10

   The evidence pack covers card creation, controls, funding, and network partnerships but never specifies which underlying program types (debit, prepaid, commercial credit, consumer credit) Stripe Issuing supports — the only hint is a truncated snippet ('Commercial iss...') that provides no substantive detail. Missing for 10: explicit documentation distinguishing prepaid vs. debit vs. commercial credit vs. consumer credit program support, eligibility/underwriting differences, or customer examples confirming multiple program types in production.

   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote~partialclaimed3/10

   Highnote's docs describe a general card-issuing platform (virtual/physical/tokenized cards, financial accounts, customizable card programs) and mention 'launch or migrate your card program,' implying support for multiple program types, but the evidence never explicitly names debit, prepaid, commercial credit, or consumer credit program types. Missing for 10: explicit documentation or product pages listing debit, prepaid, commercial credit, and consumer credit as distinct supported program types, and independent confirmation of multi-rail support.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
   • [claimed-docs] “Launch or migrate your card program with speed and flexibility.”
   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”

   proof ↗⚑ flag

Funding models

1. finance leadChoose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented

   weight 2 · round drawn
   Stripe Issuing~partialclaimed5/10

   Stripe Issuing documents a balance-based (prefunded) funding model where finance pushes funds from an external bank account (stripe-issuing-docs-9), and separately documents real-time authorization webhooks that let a system approve/decline each authorization synchronously, which is the core of just-in-time funding control (stripe-issuing-docs-4). However, the evidence never explicitly frames these as two alternative 'prefunded vs JIT' funding models nor discusses the cash-flow tradeoffs between them. Missing for 10: explicit documentation contrasting prefunded balance funding vs JIT funding as named options, and cash-flow tradeoff guidance for finance leads.

   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”

   proof ↗⚑ flag

   Highnote~partialclaimed5/10

   Highnote documents collaborative authorization (real-time approve/decline of authorizations, i.e. JIT-style funding control) and an integrated ledger for tracking balances, plus prefunded-style financial accounts and Plaid-connected external bank accounts, implying both prefunded and JIT funding models exist. However, there is no explicit documentation contrasting 'prefunded balance' vs 'just-in-time funding' as named funding models, nor any discussion of the cash-flow tradeoffs between them. Missing for 10: explicit naming/documentation of prefunded vs JIT funding modes as a configurable choice, and any cash-flow tradeoff analysis or guidance comparing the two.

   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Track money movement and balances with the integrated ledger.”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
   • [claimed-docs] “Externally connected bank accounts via Plaid”
   • [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”

   proof ↗⚑ flag

Program launch

1. founderLaunch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented

   weight 3 · round drawn
   Stripe Issuing~partialprobed5/10

   Docs show Stripe handles cardholder/card creation, network partnerships (Mastercard/Visa), controls, funding, and disputes — all evidence that program management, network membership, and card issuance mechanics are Stripe's responsibility, not the founder's. However, there is no explicit documentation of BIN sponsorship terminology or a stated timeline from signup to first live card. Missing for 10: explicit 'no bank charter/BIN sponsorship' framing, and a documented signup-to-first-live-card timeframe or onboarding SLA.

   • [claimed-docs] “Creates an Issuing `Card` object.”
   • [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
   • [claimed-docs] “We also partner with the Mastercard and Visa card networks so you can issue cards on either network or on both.”
   • [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
   • [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote~partialclaimed5/10

   Docs show Highnote absorbs core program-management burdens (in-house KYC/KYB compliance, transaction monitoring, reconciliation, settlement, disputes team) so a founder doesn't need banking infrastructure themselves, and marketing claims 'launch or migrate your card program with speed and flexibility.' However, there is no explicit mention of BIN sponsorship or card network membership being handled by Highnote, and no documented signup-to-first-live-card timeline or benchmark. Missing for 10: explicit BIN sponsor/network membership details, a concrete documented time-to-launch metric or case study.

   • [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
   • [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
   • [claimed-docs] “Launch or migrate your card program with speed and flexibility.”
   • [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”

   proof ↗⚑ flag

Limits

1. ops userSet spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code

   weight 3 · round to Highnote
   Stripe Issuing~partialprobed5/10

   Docs confirm platform-enforced spending controls (merchant category/country/MID/card-presence blocks) and spending limits, but only mention 'per authorization or per month' intervals — no explicit mention of daily or all-time windows, transaction-count velocity rules, or per-cardholder (vs per-card) limit distinctions. Real-time authorization webhook (docs-4) supports enforcement flow but isn't itself the velocity/amount-cap mechanism. missing for 10: daily/all-time window support, transaction-count velocity rules, explicit per-cardholder vs per-card scoping detail.

   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”

   proof ↗⚑ flag

   Highnote✓fullclaimed8/10

   Docs explicitly describe spend rules (MCC, dollar amount, authorization count) and velocity controls (e.g., weekly spending limit example) that are configured and enforced platform-side at authorization time, plus per-card, per-account, and program-level scoping (docs-8, docs-9, docs-18, docs-21). This directly matches per-card/cardholder amount caps and transaction-count velocity rules enforced by Highnote rather than custom code. missing for 10: explicit documentation of all-time (lifetime) window caps distinct from daily/monthly/weekly, and independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”

   proof ↗⚑ flag

Merchant controls

1. ops userRestrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time

   weight 2 · round to Highnote
   Stripe Issuing~partialclaimed6/10

   Docs confirm spending controls can block by merchant category (MCC) and merchant IDs (single-merchant lock) applied via authorization-time controls, and real-time webhook authorization confirms enforcement at auth time. However, the evidence does not explicitly confirm an 'allowlist' mode (only 'block' is described) nor detail how single-merchant locking works beyond blocking by merchant ID, leaving allowlist behavior unproven. missing for 10: explicit allowlist (allow-only) MCC configuration, explicit documentation of single-merchant lock as a distinct feature, independent/hands-on verification of authorization-time enforcement.

   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”

   proof ↗⚑ flag

   Highnote~partialclaimed7/10

   Highnote's Spend Rules explicitly support MCC-based logic evaluated at authorization time, and rules can be scoped per card, account, or program (including single-card/single-merchant-like restriction via card-level rules). However, the evidence does not explicitly confirm an MCC allowlist/blocklist distinction or a dedicated 'single-merchant lock' feature—only general merchant category restriction and per-transaction/velocity caps. Missing for 10: explicit documentation of MCC allowlist vs blocklist configuration and a named single-merchant lock capability.

   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
   • [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”

   proof ↗⚑ flag

Scoped cards

1. developerIssue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used

   weight 2 · round drawn
   Stripe Issuing✓fullclaimed8/10

   Stripe Issuing supports single-use virtual cards scoped to a task/session that auto-invalidate after use, plus per-authorization spending controls (exact amount, merchant category, merchant ID, single presence) to tightly scope a card to one purchase/merchant. missing for 10: no independent/hands-on corroboration of single-use card behavior beyond docs, and no explicit example combining exact-amount + single-merchant lock in one workflow.

   • [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
   • [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
   • [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”

   proof ↗⚑ flag

   Highnote✓fullclaimed8/10

   Highnote docs explicitly support issuing virtual cards with spend rules configurable by MCC, dollar amount, and authorization count, plus velocity controls (e.g., weekly $1,000 limits) and per-workflow cards that auto-close when a task ends — directly matching one-purchase/one-merchant/exact-amount scoping. Collaborative authorization further allows real-time accept/decline logic enforced before funds move. missing for 10: no explicit documentation of a strict 'single-use, exact amount, auto-expire after one transaction' card type or independent/hands-on confirmation that a single-use card is truly unusable after one authorization.

   • [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
   • [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
   • [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
   • [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
   • [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
   • [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”

   proof ↗⚑ flag

Credentials

1. developerCardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets

   weight 2 · round drawn
   Stripe Issuing—none0/10

   The evidence pack covers card/cardholder creation, spending controls, wallets, disputes, and replacement cards, but contains no mention of PIN set/reset APIs or 3DS enrollment flows, which are a plausible and expected capability for a card-issuing API. Absence of evidence for this applicable axis means it cannot be credited.

   ⚑ flag

   Highnote—none0/10

   No evidence in the pack describes PIN set/reset APIs or 3DS enrollment flows; the closest items (SDKs for embedding sensitive card data, checkout details collection) do not mention PIN management or 3DS enrollment specifically. This is a fair axis for a card issuing platform, but the capability is unevidenced.

   ⚑ flag

Tokenization

1. developerNetwork tokens are first-class — I can see and manage the tokens created for a card, know which wallet or merchant holds them, and revoke them independently of the PAN

   weight 2 · round drawn
   Stripe Issuing—none0/10

   Evidence only shows that cards can be added to digital wallets (Apple Pay/Google Pay/Samsung Pay) but nothing about a distinct network-token object, listing which wallet/merchant holds a token, or revoking a token independently of the underlying PAN. Missing for 10: token object/API reference, wallet/merchant attribution per token, token-level revocation endpoint or dashboard control.

   • [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”

   proof ↗⚑ flag

   Highnote—none0/10

   The evidence pack covers card issuing, spend controls, ledger, disputes, webhooks, and agentic card provisioning, but there is no mention of network tokens, tokenized digital cards' token-level management, wallet/merchant token association, or ability to revoke a token independently of the PAN. missing for 10: network token visibility/management APIs, wallet/merchant identification for tokens, token-level revocation separate from card cancellation.

   • [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
   • [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”

   proof ↗⚑ flag

Wallet provisioning

1. developerCards land in Apple Pay and Google Pay — push provisioning from my app with the entitlements process documented, plus in-wallet card art and manual provisioning as a fallback

   weight 2 · round to Stripe Issuing
   Stripe Issuing~partialclaimed4/10

   Docs confirm cards can be added to Apple Pay, Google Pay, and Samsung Pay and that physical card art/customization and replacement (manual provisioning fallback) exist, but there is no documentation of the push provisioning API/SDK flow, entitlements process, or in-app provisioning implementation details a developer would need. missing for 10: push provisioning API/SDK documentation, entitlements process details, in-wallet card art specification, independent/hands-on confirmation of the provisioning flow.

   • [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”
   • [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
   • [claimed-docs] “Configure the appearance of your physical cards, such as by adding a company logo, and customize the accompanying content.”

   proof ↗⚑ flag

   Highnote—none0/10

   Evidence covers card issuance, spend controls, ledger, disputes, and SDKs, but nowhere mentions Apple Pay/Google Pay push provisioning, entitlements process, in-wallet card art, or manual provisioning fallback for digital wallets.

   ⚑ flag