Stripe Issuing vs Marqeta

Agent access

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

   weight 2 · round to Stripe Issuing
   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

   Marqeta~partialprobed4/10

   Marqeta's docs are available in machine-readable .md format per-page (e.g., cards.md, introduction.md), which is agent-friendly, but there is no llms.txt index file and probes for llms.txt and a consolidated docs.md both return 404. Missing for 10: a dedicated llms.txt manifest, a single agent-oriented entry point, and confirmation that individual .md pages are discoverable/crawlable without prior knowledge of URLs.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”

   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

   Marqeta~partialclaimed5/10

   Marqeta's Core API is a REST API with a sandbox environment for programmatic testing/simulation (card products, users, transactions), which is inherently usable headlessly via scripts or CI pipelines. However, there is no explicit documentation of CI/CD integration, SDKs for automated testing, or a CLI—automation must be inferred from generic REST API access. Missing for 10: explicit CI/CD guides or examples, official SDK/CLI for automation, and evidence of headless usage patterns beyond sandbox simulation endpoints.

   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”

   proof ↗⚑ flag

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

   weight 3 · round to Marqeta
   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

   Marqeta✓fullprobed8/10

   Marqeta documents an official MCP Server that AI agents can use to query Core API endpoints, issue virtual cards, and set spend controls, confirmed by both docs and a probe verifying the page exists. Missing for 10: independent/hands-on corroboration of setup and real-world agent integration beyond first-party docs.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   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

   Marqeta—none0/10

   Marqeta is a card issuing platform; an official CLI is a plausible developer-tooling axis, but evidence only shows a Core API, sandbox, interactive doc widgets, and an MCP server — no mention of a CLI tool anywhere. missing for 10: any evidence of an official CLI, CLI documentation, or CLI installation instructions.

   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”

   proof ↗⚑ 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

   Marqeta✓fullprobed8/10

   Marqeta publishes extensive Core API documentation covering cards, users, transactions, controls, webhooks, disputes, and a full interactive sandbox with browser-based widgets for testing endpoints directly, clearly enabling an AI-native developer to drive the product programmatically. Missing for 10: a discoverable machine-readable OpenAPI/llms.txt spec (probes show 404s at standard paths), which would make API discovery more agent-friendly.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”

   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

   Marqeta~partialprobed4/10

   Marqeta's MCP server is described as letting agents query only 'a designated set of Marqeta's Core API endpoints,' implying some endpoint-level scoping for agent access, and spend/velocity controls could theoretically constrain an agent-issued card's usage. However, there is no explicit documentation of issuing scoped or least-privilege API credentials (e.g., API keys/OAuth tokens with configurable permission scopes) specifically for an AI agent. Missing for 10: explicit scoped-credential/API-key issuance mechanism, permission granularity documentation, and independent confirmation of least-privilege enforcement for agents.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Stripe Issuing
   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

   Marqeta—none0/10

   The evidence pack documents Marqeta's Core API, sandbox, webhooks, and an MCP server, but contains no mention of official client SDKs (e.g., Python, Java, Node libraries) that AI-native developers could build against. Probes for openapi.json/docs.md/llms.txt all returned 404, further indicating no discoverable machine-readable SDK artifacts.

   • [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Marqeta
   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

   Marqeta✓fullclaimed8/10

   Marqeta's docs explicitly describe webhooks as notifications about API events sent as they occur, providing a documented subscription mechanism for real-time events. Missing for 10: no independent/hands-on corroboration or detail on webhook configuration/management API specifics beyond the single doc reference.

   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”

   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

   Marqeta—none0/10

   Marqeta offers an MCP server for agents to query API data and act on it (card issuance, spend controls), but there is no evidence of AI-generated insights, analytics, or suggestions surfaced to users inside the product itself — it's raw data querying, not insight generation. Missing for 10: any dashboard, report, or in-product AI feature that analyzes user data and proactively surfaces insights/recommendations.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”

   proof ↗⚑ 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

   Marqeta~partialprobed5/10

   Marqeta provides infrastructure that supports autonomous background operation — webhooks fire automatically on events, JIT funding lets a system auto-approve/deny in real time using business rules, and an MCP server lets AI agents query Core API data and act on it (issue cards, set spend controls) without human intervention. However, there is no documented 'automation builder', scheduler, or explicit background-job orchestration feature — the autonomy comes from combining APIs/webhooks/MCP yourself. Missing for 10: a dedicated automation/workflow engine, scheduling capability, and evidence of persistent unattended agent runs beyond query/action tooling.

   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   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

   Marqeta~partialprobed5/10

   Marqeta ships an official MCP Server that lets external AI agents query Core API data, issue virtual cards, and set spend controls, which indirectly enables natural-language operation via a connected agent — but this requires the user's own AI agent tooling rather than a built-in NL interface, and there's no evidence of a native chat/NL command surface in the product itself. missing for 10: evidence of a first-party natural-language interface/chat UI, independent/hands-on confirmation of NL command usage via the MCP server, and broader coverage beyond the limited endpoint set mentioned.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Marqeta
   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

   Marqeta~partialprobed6/10

   Marqeta's docs explicitly state interactive widgets let developers explore and test the Core API directly from the browser, plus a sandbox environment and simulation endpoints support runnable, hands-on exploration. However, there's no evidence of a full interactive API reference (e.g., try-it-console with live request/response, OpenAPI-spec-based explorer) and probes show no discoverable OpenAPI/swagger spec, so the extent of interactivity is unclear. Missing for 10: confirmed OpenAPI/swagger-based reference, visible runnable code snippets per endpoint, independent corroboration of the widget experience.

   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”

   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

   Marqeta—none0/10

   Direct probes for OpenAPI/Swagger specs and llms.txt/docs.md all returned 404, and no evidence pack item links to a downloadable machine-readable API spec despite extensive Core API docs; interactive widgets and MCP server access don't substitute for a downloadable spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”

   proof ↗⚑ flag

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

   weight 1 · round to Marqeta
   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

   Marqeta✓fullclaimed8/10

   Marqeta explicitly documents a sandbox environment for testing Core API without production data, including simulated card network transactions (authorizations, reversals, balance inquiries) and a quick-start tutorial showing how to create test objects and simulate transactions. This sandbox is also accessible via the official MCP server for agentic AI use cases. Missing for 10: independent/hands-on third-party confirmation of sandbox fidelity or limitations.

   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”

   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

   Marqeta—none0/10

   The evidence pack shows extensive Core API docs, sandbox, and an MCP server, but nothing documents API versioning scheme or a deprecation policy; probes for openapi/spec files also failed. Missing for 10: any mention of API versioning, version headers/URLs, or a documented deprecation/sunset policy.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”

   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 Marqeta
   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

   Marqeta~partialclaimed5/10

   Evidence confirms transaction retrieval by merchant/card/account holder and authorization/velocity controls, but no explicit documentation of MCC codes, enhanced merchant data, wallet/entry-mode fields, or partial-approval and incremental-auth signals in the authorization payload. missing for 10: MCC field detail, enhanced merchant data enrichment, wallet/entry-mode metadata, partial-approval and incremental-auth signal documentation.

   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”

   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 to Stripe Issuing
   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

   Marqeta~partialclaimed4/10

   Marqeta's JIT Funding gateway lets a developer's own system approve or decline funding/authorization requests in real time using custom business rules, which is the core of this story, but the evidence never documents the network's response-time budget or a configurable timeout/fallback behavior the developer controls. Webhooks (docs-9) are described only as async event notifications, not the real-time decisioning channel, so they don't fully substantiate the 'auth-stream endpoint' framing either. Missing for 10: documented timeout window/SLA for JIT funding responses, explicit fallback/default-decision configuration, and clarity on webhook vs. JIT funding as the real-time decision channel.

   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”

   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 Marqeta
   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

   Marqeta~partialclaimed7/10

   Docs confirm a sandbox with endpoints to simulate authorizations, reversals, and balance inquiries, plus a quick-start tutorial covering card/user/product creation and transaction simulation, and separate endpoints for transactions and disputes. However, explicit simulation coverage for clearings, refunds, and declines is not documented, and no independent/hands-on corroboration is provided. missing for 10: explicit simulation of clearings, refunds, and declines; independent developer confirmation of full lifecycle simulation.

   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Marqeta—none0/10

   Evidence shows single-resource CRUD endpoints (create one card, one dispute, one user) and an MCP server for querying/creating individual cards, but nothing about batch/bulk endpoints or operations across many items at once. Missing for 10: bulk create/update APIs, batch job endpoints, any documentation of multi-item operations.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”

   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

   Marqeta~partialclaimed6/10

   Marqeta supports event-driven automation in the payments domain: velocity/authorization controls automatically restrict spend based on transaction events, JIT funding lets your system approve/deny in real time, and webhooks notify external systems as API events occur. This is rule-triggered action, but it's domain-specific (spend limits, approvals) rather than a general-purpose rule/workflow engine for arbitrary triggers and actions. Missing for 10: a broader configurable rule/automation builder beyond spend controls, and independent evidence of custom event-to-action workflows.

   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”

   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

   Marqeta~partialclaimed3/10

   Evidence confirms card creation via Core API and sandbox simulation of transactions, plus velocity/authorization controls, but none of the citations explicitly document activate, pause/unpause, report lost/stolen, reissue-linked-to-original, or permanent close endpoints. Missing for 10: explicit docs on card state-transition endpoints (activate/suspend/unsuspend), lost/stolen reporting, reissue linkage, and card termination/closure.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”

   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

   Marqeta—none0/10

   Evidence only covers virtual/instant card issuance, sandbox testing, and general card creation via the Core API — there is no mention of physical card manufacturing, custom card art, bulk ordering, shipping methods, or tracking integration. Missing for 10: physical card fulfillment API docs, custom art/design options, bulk order endpoints, carrier/shipping and tracking integration.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”

   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 to Marqeta
   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

   Marqeta~partialclaimed6/10

   Docs confirm one-call card creation via API (marqeta-docs-1), a sandbox environment for testing (marqeta-docs-2, marqeta-docs-14), and instant-issue virtual cards ready for immediate use (marqeta-docs-12, marqeta-docs-16). However, there is no explicit evidence that PAN/CVV/expiry are all returned synchronously in the creation response, nor any documentation of a self-serve path from sandbox to live/production credentials without a sales engagement. missing for 10: explicit confirmation that PAN, CVV, and expiry are returned in the create-card API response, and evidence of self-service sandbox-to-production activation without a sales cycle.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [claimed-docs] “Issue virtual cards”

   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

   Marqeta✓fullprobed8/10

   Marqeta explicitly documents an AI-agent-focused MCP server that supports instant-issue virtual cards, spend caps/velocity limits, and merchant restrictions, directly naming the agent use case (marqeta-docs-11,12,13), backed by general card issuance, merchant lock, and velocity control APIs (marqeta-docs-1,5,6). Missing for 10: independent/hands-on corroboration of an agent actually using scoped cards in production, and explicit documentation of expiry controls specifically tied to agent cards.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   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 drawn
   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

   Marqeta~partialprobed6/10

   Marqeta documents an official MCP server for agentic AI that lets agents query Core API data (docs-11) and lists virtual card issuance and spend-control features on that same page (docs-12, docs-13), alongside full Core API support for reading balances/transactions (docs-7), creating/updating cards (docs-1), and setting velocity/merchant controls (docs-5, docs-6). However, the MCP server's own description emphasizes 'query data' rather than confirming write actions (create/update cards, adjust controls) run through the MCP surface itself, and there is no explicit mention of scoped-credential mechanics for the MCP server. Missing for 10: explicit confirmation that create/update-card and spend-control actions (not just queries) are exposed via the MCP server, and documentation of scoped/least-privilege credentials for MCP access.

   • [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”

   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 drawn
   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

   Marqeta—none0/10

   Evidence covers card issuance, velocity/authorization controls, transactions, disputes, and simulations, but nothing in the pack documents KYC for consumers or KYB for businesses, associated data requirements, review states, or re-verification flows. Missing for 10: KYC/KYB documentation, identity verification data requirements, review/approval states, and re-verification workflow evidence.

   ⚑ 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 Marqeta
   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

   Marqeta~partialclaimed3/10

   The only relevant evidence is a bare marketing bullet naming 'PCI widgets' with no elaboration on how they reduce PCI scope, SAQ D applicability, or ephemeral-key reveal mechanics. Missing for 10: documentation of the hosted PAN/CVV reveal component's implementation, explicit PCI SAQ D scope-reduction claims, and independent/hands-on confirmation that integrators avoid full PCI scope.

   • [claimed-docs] “PCI widgets”

   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 Marqeta
   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

   Marqeta~partialclaimed5/10

   Marqeta docs confirm a dedicated dispute-case API (disputes-mastercard.md) for creating cases with network/type-specific details, and a general webhooks system exists for API event notifications, plus transaction retrieval endpoints. However, the evidence pack never documents evidence-submission endpoints, provisional credit handling, or dispute-specific status webhooks through resolution. Missing for 10: evidence submission workflow, provisional credit issuance/reversal mechanics, dispute-status webhook events, and multi-network (Visa) reason code coverage beyond Mastercard.

   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”

   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

   Marqeta~partialclaimed3/10

   Marqeta docs show velocity/authorization spend controls (docs-5, docs-6), transaction retrieval (docs-7), webhooks for event notifications (docs-9), and a disputes API for handling compromised-card claims (docs-8) — these provide some fraud-adjacent tooling. However, there is no evidence of network fraud scores or Marqeta's own fraud-risk models surfaced at authorization time, no dedicated suspicious-activity/fraud alerting feature, and no explicit card-block-and-reissue workflow described. Missing for 10: fraud score/model surfaced at auth, suspicious-activity alerting, explicit block-and-reissue tooling for compromised cards.

   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”

   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 Marqeta
   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

   Marqeta~partialclaimed5/10

   Marqeta provides transaction retrieval endpoints (docs-7), dispute case creation (docs-8), webhooks for real-time event notification (docs-9), and JIT funding approval flows tied to authorizations (docs-4), which together give partial visibility into authorization-to-clearing flows. However, there is no evidence of a dedicated settlement reporting module, penny-accurate reconciliation reports, or a finance-lead-facing balance/ledger dashboard. Missing for 10: settlement reporting/reconciliation documentation, account/card balance reporting UI, ledger reconciliation guarantees, and independent verification of accuracy.

   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”

   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 drawn
   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

   Marqeta—none0/10

   Evidence covers transactions API, disputes, webhooks, and sandbox simulations, but nothing addresses settlement/reconciliation files, interchange/fee reporting, or network adjustment reporting APIs that a finance stack could consume. No mention of settlement or reconciliation artifacts anywhere in the docs pack.

   ⚑ 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 Marqeta
   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

   Marqeta~partialclaimed6/10

   Marqeta documents webhooks for API events generally and has explicit endpoints/objects for transactions and disputes (chargebacks), plus transaction retrieval by card/merchant/account holder, suggesting stable identifiers exist across the transaction lifecycle. However, evidence does not explicitly confirm that clearings, refunds, reversals, and chargebacks each fire dedicated webhook events with stable transaction IDs tying back to the original auth — the webhook doc is generic and disputes are described as case creation rather than webhook-driven updates. Missing for 10: explicit webhook event types/payloads for clearings, refunds, reversals, and chargebacks, and confirmation of stable transaction ID linkage across these events.

   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”

   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

   Marqeta~partialprobed6/10

   Marqeta is API-first: docs show broad Core API coverage (cards, users, controls, transactions, disputes, webhooks, simulations) suggesting most operations available programmatically, and dashboards reference features like 'PCI widgets' and 'dynamic spend controls' that map to documented API endpoints. However, there's no explicit mapping or claim confirming full UI-API parity, and openapi/spec discovery probes failed (404s), making it hard to verify completeness. Missing for 10: an explicit parity statement or comprehensive OpenAPI spec confirming every UI action has an API equivalent, and independent confirmation of no UI-only features.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “Dynamic spend controls”
   • [claimed-docs] “Issue virtual cards”
   • [claimed-docs] “PCI widgets”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Issuing—none0/10

   No evidence of a data export/portability feature or open-format export mechanism for Stripe Issuing account data; the API allows retrieving records via API calls but there's no documented bulk export tool or open-format data portability guarantee for users to 'take their data and leave'.

   ⚑ flag

   Marqeta—none0/10

   Marqeta is a card-issuing API platform; there's no evidence of any bulk data export/portability feature in open formats, and probes for llms.txt, docs.md, and openapi specs all returned 404. The evidence only covers API endpoints for retrieving transactions individually, not a data export/leave capability.

   • [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
   • [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Issuing—none0/10

   No evidence in the pack addresses data residency or region selection for Stripe Issuing data; nothing discusses where card/cardholder data is stored or regional data controls.

   ⚑ flag

   Marqeta—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data controls for Marqeta's platform or API; the docs focus on card issuance, controls, and MCP server features. Missing for 10: any mention of data region selection, residency guarantees, or storage location configuration.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Issuing—none0/10

   The evidence pack covers card issuance, spending controls, disputes, and agent-scoped virtual cards, but contains no mention of data retention policies, data deletion APIs, or privacy controls for cardholder/transaction data. Card auto-invalidation (docs-12) is about card lifecycle, not data retention/deletion of stored information, so it doesn't satisfy this axis.

   ⚑ flag

   Marqeta—none0/10

   No evidence pack items address data retention policies, deletion controls, or privacy/data lifecycle management for AI agent interactions or API data; documentation covers card issuance, controls, transactions, disputes, and MCP server capabilities but nothing on retention/deletion.

   ⚑ 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 drawn
   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

   Marqeta—none0/10

   The evidence pack shows generic 'card product' creation, sandbox simulation, and general statements about 'creating new payment products' but never names or documents specific program types (debit, prepaid, commercial credit, consumer credit) that Marqeta supports. Without explicit documentation distinguishing these card/program types, there's no evidence the platform is positioned beyond a generic card-issuing API.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
   • [claimed-docs] “Use open APIs to create new payment products or streamline supplier and workforce payments.”

   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

   Marqeta~partialclaimed5/10

   JIT funding is clearly documented — the merchant's own system approves/denies funding requests per authorization (marqeta-docs-4) — but the evidence pack contains no explicit documentation of a prefunded-balance funding option or any comparison of cash-flow tradeoffs between the two models. Missing for 10: explicit prefunded balance funding docs, side-by-side cash-flow tradeoff guidance, finance-lead-oriented configuration guidance for choosing between models.

   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”

   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 to Stripe Issuing
   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

   Marqeta~partialclaimed4/10

   Docs show Marqeta's Core API letting a founder create card products, users, cards, spend/velocity controls, disputes, and webhooks via a sandbox quick-start (marqeta-docs-1,5,6,8,9,14), implying program management is handled by the platform. However, there is no explicit mention of BIN sponsorship or network membership arrangements, and no documented signup-to-first-live-card timeline metric anywhere in the pack. Missing for 10: explicit BIN sponsorship/bank-partner language, network membership details, and a concrete time-to-live-card benchmark.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
   • [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
   • [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”

   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 Marqeta
   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

   Marqeta✓fullclaimed8/10

   Marqeta's velocity controls docs explicitly describe platform-enforced amount and count limits per user/card over configurable time windows, with multiple controls stacking (user cannot exceed any defined limit), plus authorization controls for merchant restrictions — all enforced server-side rather than in client code. missing for 10: no independent/hands-on corroboration of exact daily/monthly/all-time window options or precise velocity rule syntax beyond doc summaries.

   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”

   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 Marqeta
   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

   Marqeta✓fullclaimed8/10

   Marqeta's authorization-controls docs explicitly support limiting transactions to a single merchant or group of merchants (single-merchant lock), and merchant restrictions are called out as a spend-control feature alongside velocity limits; these controls apply at authorization time per the Core API design. Missing for 10: explicit documentation of MCC allowlist vs blocklist semantics and independent/hands-on confirmation beyond first-party docs.

   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”

   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

   Marqeta✓fullclaimed8/10

   Marqeta's Core API documents virtual card issuance, merchant-restriction controls, velocity/spend-limit controls, and JIT funding that lets the issuer approve/deny each transaction against custom rules — together these let a developer create a card scoped to one merchant and exact amount, and JIT funding means an unused/leaked number can be denied. Missing for 10: explicit 'single-use card' terminology/flag in docs and independent/hands-on confirmation that a card auto-invalidates after one authorization.

   • [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
   • [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
   • [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
   • [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
   • [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
   • [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”

   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

   Marqeta—none0/10

   The evidence pack lists card, transaction, dispute, and control APIs but never mentions PIN set/reset endpoints or 3DS enrollment flows; the only tangential hint is a vague 'PCI widgets' bullet with no detail on PIN or 3DS functionality. Missing for 10: PIN set/reset API documentation, 3DS enrollment endpoint or workflow description, any explicit mention of cardholder credential self-service via API.

   • [claimed-docs] “PCI widgets”

   proof ↗⚑ 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

   Marqeta—none0/10

   The evidence pack covers card creation, velocity/authorization controls, transactions, disputes, webhooks, and simulations, but nowhere mentions network tokens, token-to-wallet/merchant association, token visibility, or independent token revocation separate from the PAN — this is a distinct tokenization capability not evidenced here.

   ⚑ 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

   Marqeta—none0/10

   No evidence in the pack addresses push provisioning into Apple Pay/Google Pay, wallet entitlements processes, in-wallet card art, or manual provisioning fallback; the docs cover card creation, velocity controls, transactions, disputes, webhooks, and simulations but never wallet tokenization.

   ⚑ flag