Lithic vs Marqeta

Agent access

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

   weight 2 · round to Lithic
   Lithic✓fullprobed8/10

   Lithic hosts a working llms.txt confirmed by direct probe (HTTP 200) with structured developer docs, plus a dedicated MCP server that lets agents search docs, inspect schemas, and execute API requests. Missing for 10: independent/third-party confirmation of agents actually consuming llms.txt in practice, and no broader agent-oriented docs index beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lithic.com/llms.txt # Lithic Developer Documentation Documentation > The Lithic developer API prov…”
   • [claimed-docs] “Once connected, your AI assistant can search Lithic documentation, inspect endpoint schemas, generate integration code, and execute live API…”
   • [probe] “official MCP server documented at https://docs.lithic.com/docs/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 drawn
   Lithic~partialprobed5/10

   Lithic is a REST API platform with a sandbox environment for simulating transactions (lithic-docs-5) and versioned API headers (lithic-docs-7), which implies it can be scripted/automated in CI pipelines since it's inherently API-driven rather than GUI-driven. However, there is no explicit documentation of CI/CD integration, headless test runners, or automation-specific tooling/SDKs for pipeline use. missing for 10: explicit CI/CD examples, dedicated automation SDK/CLI, documented headless test workflows, independent confirmation of CI usage.

   • [claimed-docs] “The sandbox environment has additional endpoints to simulate transaction events originating from a merchant acquirer.”
   • [claimed-docs] “Send the `api-version` request header with the version you want”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lithic.com/llms.txt # Lithic Developer Documentation Documentation > The Lithic developer API prov…”

   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 drawn
   Lithic✓fullprobed8/10

   Lithic is not itself an agent but a payments API platform, so publishing an official MCP server is a fair axis; docs and a probe confirm an official MCP server exists that lets AI assistants search docs, inspect schemas, and execute live API calls, with a blog walkthrough of agentic use (creating cards, configuring rules, running test transactions). Missing for 10: independent/third-party hands-on confirmation beyond vendor docs and blog.

   • [claimed-docs] “Once connected, your AI assistant can search Lithic documentation, inspect endpoint schemas, generate integration code, and execute live API…”
   • [probe] “official MCP server documented at https://docs.lithic.com/docs/mcp”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”

   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 drawn
   Lithic—none0/10

   No evidence of an official Lithic CLI; the product offers an MCP server and REST API but nothing about a dedicated CLI tool for AI-native workflows.

   ⚑ 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 drawn
   Lithic✓fullprobed8/10

   Lithic exposes an extensive documented REST API covering cards, disputes, webhooks, KYC, spend limits, and versioning headers, plus reference pages for direct endpoint invocation, showing a fully documented public API surface an AI-native user could drive programmatically. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe returned 404s on standard paths) and independent third-party corroboration of API usability.

   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”
   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “Send the `api-version` request header with the version you want”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “Lithic can help power your cardholders' disputes by handling networking filing for chargebacks and representment responses.”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lithic.com/llms.txt # Lithic Developer Documentation Documentation > The Lithic developer API prov…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lithic.com/openapi.json, https://docs.lithic.com/swagger.json, https://docs.lithic.com/…”

   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 Lithic
   Lithic~partialclaimed6/10

   Lithic doesn't document scoped API keys/OAuth tokens per se, but it does support issuing virtual cards with tightly scoped authorization rules (merchant category, spend limits, velocity, entity-level rules) explicitly for AI agent use cases, as shown in the agentic payments blog and MCP server docs. This effectively delivers least-privilege 'credentials' (cards) for agents, though not classic API-key scoping. Missing for 10: explicit API key/token permission scoping mechanism, documentation of restricting an agent's API access (vs. card spend controls), independent verification of this workflow.

   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [claimed-docs] “Make the leap from insights to action with secure and autonomous issuing, payments, and controls for AI-powered workflows.”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”

   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 drawn
   Lithic—none0/10

   The evidence pack covers Lithic's API documentation, MCP server, and various API features (auth rules, disputes, webhooks, etc.), but contains no mention of official SDKs (e.g., Python, Node, Java client libraries) that developers could build against. Absence of evidence for this applicable capability means it cannot be credited.

   ⚑ 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 drawn
   Lithic✓fullclaimed8/10

   Lithic's Events API explicitly supports registering/managing webhook URLs, subscription secrets, replaying messages, and searching past events, and ASA webhooks deliver real-time transaction events via HTTP POST — directly enabling event subscription for agentic workflows. Missing for 10: independent/hands-on corroboration of webhook reliability and no direct mention of AI-agent-specific webhook consumption patterns.

   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”

   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 drawn
   Lithic—none0/10

   Lithic's evidence covers an MCP server for developers to query docs/API and 'agentic commerce' messaging about autonomous issuing/payments, but there is no evidence of the product itself surfacing AI-generated insights or suggestions from a user's own transaction/account data inside a Lithic dashboard or interface.

   ⚑ 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 Lithic
   Lithic~partialclaimed6/10

   Lithic's Authorization Rules v2, ASA webhooks, and Events API let developers configure rules and endpoints that autonomously evaluate and act on transactions in real time without human intervention (lithic-docs-2,3,4,6), and Lithic explicitly markets 'autonomous issuing, payments, and controls for AI-powered workflows' with an MCP server that can configure and test such rules (lithic-docs-11,12). However, this is transaction-rule automation rather than a general-purpose scheduler/agent framework for arbitrary background tasks, and there's no dedicated docs on setting up recurring/cron-style AI agent jobs beyond the payments rules domain. Missing for 10: evidence of a general task-scheduling/automation framework beyond payment authorization rules, and independent/hands-on confirmation that these automations run reliably unattended.

   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [claimed-docs] “Make the leap from insights to action with secure and autonomous issuing, payments, and controls for AI-powered workflows.”

   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 Lithic
   Lithic✓fullprobed7/10

   Lithic ships an official MCP server that lets an AI assistant search docs, inspect schemas, generate integration code, and execute live API requests in natural language, and a dedicated blog post walks through using it to create cards, set authorization rules, and run test transactions conversationally. Missing for 10: independent/hands-on third-party corroboration of the MCP workflow and broader coverage of natural-language commands outside the MCP/IDE context.

   • [claimed-docs] “Once connected, your AI assistant can search Lithic documentation, inspect endpoint schemas, generate integration code, and execute live API…”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [probe] “official MCP server documented at https://docs.lithic.com/docs/mcp”
   • [claimed-docs] “Make the leap from insights to action with secure and autonomous issuing, payments, and controls for AI-powered workflows.”

   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
   Lithic—none0/10

   Evidence shows a docs.lithic.com/reference section exists (e.g. postcards reference) but nothing describes runnable/interactive examples (a 'try it' console) and the OpenAPI spec probe returned 404s across all candidate paths, suggesting no exposed interactive spec. The MCP integration lets an AI assistant execute live requests from an editor, but that's a separate agent-tooling feature, not an interactive API reference page.

   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lithic.com/openapi.json, https://docs.lithic.com/swagger.json, https://docs.lithic.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
   Lithic—none0/10

   A probe explicitly checked standard OpenAPI spec locations (openapi.json, swagger.json, etc.) and all returned 404, and no documentation citation offers a downloadable machine-readable API spec; only an llms.txt (a documentation index, not an API schema) was found.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lithic.com/openapi.json, https://docs.lithic.com/swagger.json, https://docs.lithic.com/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lithic.com/llms.txt # Lithic Developer Documentation Documentation > The Lithic developer API prov…”

   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 drawn
   Lithic✓fullclaimed8/10

   Lithic explicitly documents a sandbox environment with endpoints to simulate transaction events (merchant acquirer simulation) separate from production, and a blog post walks through creating test accounts/cards and running transactions against rules in this sandbox — directly matching the AI-native testing story. missing for 10: independent/hands-on confirmation beyond vendor docs and blog, and no explicit statement on data isolation guarantees.

   • [claimed-docs] “The sandbox environment has additional endpoints to simulate transaction events originating from a merchant acquirer.”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”

   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 to Lithic
   Lithic~partialclaimed4/10

   Lithic documents versioned APIs via an `api-version` header (lithic-docs-7), confirming versioning support, but there is no evidence of a documented deprecation policy, sunset timelines, or changelog process for older API versions. missing for 10: documented deprecation/sunset policy, version lifecycle timelines, changelog or migration guidance for AI agents consuming the API.

   • [claimed-docs] “Send the `api-version` request header with the version you want”

   proof ↗⚑ 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
   Lithic—none0/10

   Evidence covers ASA transaction metadata generically, authorization rules, and spend limits, but no citation specifically confirms merchant name/MCC, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth fields in authorization events.

   ⚑ 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 Lithic
   Lithic~partialclaimed6/10

   Lithic's Auth Stream Access (ASA) is documented as an HTTP POST-based real-time endpoint that must respond with an approval/decline decision during authorization [lithic-docs-2], directly matching the core of this story. However, the evidence pack does not document the specific time budget (latency window) or a configurable timeout fallback policy the developer controls, which the story explicitly requires. Missing for 10: documented response-time budget/SLA, explicit timeout fallback configuration options, and independent/hands-on confirmation of real-time behavior.

   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”

   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
   Lithic~partialclaimed6/10

   Docs confirm a sandbox with endpoints to simulate merchant-acquirer transaction events (lithic-docs-5), and a blog walkthrough shows simulating authorizations against rules in a test environment (lithic-docs-11). However, there's no explicit documentation confirming simulation of the full lifecycle — clearings, reversals, refunds, and declines specifically — only general 'transaction events' language. missing for 10: explicit sandbox endpoints/examples for clearings, reversals, refunds, and declines individually; independent developer corroboration of full lifecycle simulation.

   • [claimed-docs] “The sandbox environment has additional endpoints to simulate transaction events originating from a merchant acquirer.”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”

   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
   Lithic—none0/10

   No evidence of batch/bulk endpoints (e.g., bulk card creation, bulk transaction listing, or batch job APIs) in the documentation pack; only single-resource operations (create card, single ASA request, single rule) are described. Axis applies since a payments API could plausibly offer bulk operations, but nothing in the evidence supports it.

   ⚑ 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 to Lithic
   Lithic✓fullclaimed7/10

   Lithic's Authorization Rules v2 let users define conditional rules (velocity, merchant category, spend limits) at program/account/card level that automatically trigger approve/decline actions on transaction events, with shadow-mode testing and backtesting, plus webhooks/events API for reacting to other events. missing for 10: no evidence of broader arbitrary event-to-action rule engine beyond authorization/spend/webhook events, and no independent/hands-on confirmation of rule reliability at scale.

   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”

   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

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Lithic—none0/10

   There's a shadow-mode/backtesting feature for authorization rules, but no evidence of general versioning, review workflows, or rollback capability for automations/agent actions across Lithic's platform. Missing for 10: version history for automations, review/approval workflow, rollback mechanism beyond authorization-rule drafts.

   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”

   proof ↗⚑ flag

   Marqeta—none0/10

   Marqeta is a card-issuing API platform; there is no evidence of any versioning, review, or rollback mechanism for automations/configurations (e.g., no audit trail, no version history UI, no rollback API). This is a plausible axis for an automation-capable platform, but nothing in the evidence pack supports it.

   ⚑ 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 drawn
   Lithic~partialclaimed3/10

   Evidence confirms API-driven card creation (virtual/physical) and spend/authorization controls, but there is no documentation covering activate, pause/unpause, lost-or-stolen reporting, reissue-with-linked-replacement, or permanent closure endpoints. missing for 10: pause/unpause endpoint docs, lost/stolen reporting, reissue linking to original card, permanent closure endpoint, independent confirmation of these lifecycle actions.

   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”

   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 Lithic
   Lithic~partialclaimed4/10

   Docs confirm the core capability — creating physical cards via the API with `shipping_address` and `product_id` (card design) parameters — meaning ops doesn't need a separate manufacturer relationship. However, there is no evidence of bulk ordering, choice of shipping methods, or shipment tracking, which are explicit parts of the story. Missing for 10: bulk-order endpoints/docs, shipping method options, tracking/status endpoints for shipped cards.

   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”

   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
   Lithic~partialclaimed5/10

   Docs confirm a single API call (POST /cards) creates virtual cards and a sandbox environment exists for testing, supporting the core create-in-one-call claim, but no evidence explicitly confirms PAN/CVV/expiry are returned in the creation response or that moving from sandbox to live production requires no sales process. missing for 10: explicit documentation of PAN/CVV/expiry fields in the card creation response, and evidence of self-serve production activation without a sales cycle.

   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “The sandbox environment has additional endpoints to simulate transaction events originating from a merchant acquirer.”

   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 to Marqeta
   Lithic✓fullclaimed7/10

   Lithic explicitly targets this use case: a dedicated 'agentic commerce' solutions page and blog post walk through creating a virtual card for an AI agent, assigning authorization rules that cap merchant categories, transaction limits and velocity, and testing that agent's purchases stay within policy — with card/account-level rule scoping and spend limits documented as first-class primitives. Missing for 10: explicit documentation of expiry as an agent-specific control (only general card creation docs cover expiry), and independent/third-party hands-on validation beyond the vendor's own demo blog post.

   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [claimed-docs] “Make the leap from insights to action with secure and autonomous issuing, payments, and controls for AI-powered workflows.”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”

   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
   Lithic~partialprobed6/10

   Lithic's REST API clearly supports reading transactions, creating/updating cards, and configuring spend/authorization controls (lithic-docs-3, lithic-docs-9, lithic-docs-13), and Lithic ships an official MCP server (lithic-probe-3) that a blog post shows being used to create a card, configure authorization rules, and run test transactions (lithic-docs-11), going beyond mere doc lookup described in lithic-docs-1. However, the official MCP docs frame the server primarily as a docs/code-generation aid rather than a first-class operational surface, and there is no explicit description of scoped-credential issuance for agent use via MCP or API keys. Missing for 10: explicit scoped-credential/API-key model for agent access, first-party documentation confirming MCP as a full operational (not just dev-assist) surface, independent corroboration of agentic use beyond one blog example.

   • [claimed-docs] “Once connected, your AI assistant can search Lithic documentation, inspect endpoint schemas, generate integration code, and execute live API…”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [probe] “official MCP server documented at https://docs.lithic.com/docs/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 to Lithic
   Lithic~partialclaimed3/10

   Evidence confirms Lithic has a KYC process for individual account holders (and a bypass option, KYC_BYO) but provides no detail on data requirements, review states, or re-verification flows, and no mention of KYB for business entities at all. missing for 10: KYB business verification documentation, explicit data requirement fields, review-state lifecycle, re-verification/periodic review flows, independent corroboration.

   • [claimed-docs] “KYC_BYO allows an API user to bypass the Lithic KYC process and create an individual account (available only to users with KYC processes pre…”

   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
   Lithic—none0/10

   No evidence in the pack mentions PAN/CVV reveal, hosted card components, ephemeral keys, or PCI SAQ D scope reduction; the pack covers card creation, ASA, rules, disputes, webhooks, and MCP tooling but nothing about cardholder-facing secure data display.

   ⚑ 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
   Lithic~partialclaimed4/10

   Lithic documents a Disputes API that handles network filing for chargebacks and representment responses, and a general Events/Webhooks API for status notifications, but the evidence pack lacks any documentation of specific network reason codes, evidence submission workflows, or provisional credit handling tied to disputes. missing for 10: reason code taxonomy, evidence submission endpoint details, provisional credit mechanics, dispute-specific webhook event examples.

   • [claimed-docs] “Lithic can help power your cardholders' disputes by handling networking filing for chargebacks and representment responses.”
   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”

   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 Lithic
   Lithic~partialclaimed5/10

   Lithic exposes strong authorization control infrastructure — configurable Authorization Rules at program/account/card level, shadow-mode/backtesting, real-time ASA hooks for custom decisioning, spend/velocity limits, and a disputes/chargeback API — which ops teams can use to build fraud logic and respond to compromise. However, there's no evidence of network fraud scores or Lithic's own ML fraud models surfaced at auth time, no dedicated suspicious-activity alerting, and no explicit block/reissue workflow documented in the pack. Missing for 10: documented fraud-score/model signal at authorization, proactive suspicious-activity alerts, and explicit card block-and-reissue tooling.

   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Lithic can help power your cardholders' disputes by handling networking filing for chargebacks and representment responses.”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”

   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
   Lithic—none0/10

   The evidence pack covers authorization rules, disputes, ASA, sandbox simulation, and webhooks, but contains no documentation of real-time balance views, a transaction ledger linking authorizations to clearing, or settlement reporting that reconciles to the penny — all of which are core to this finance-lead story for a card-issuing platform. Missing for 10: balance/ledger API docs, authorization-to-clearing linkage evidence, settlement/reconciliation reporting documentation.

   ⚑ 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
   Lithic—none0/10

   No evidence of settlement/reconciliation files, interchange/fee reporting APIs, or finance-stack-consumable reports in the provided documentation set; the pack covers auth rules, disputes, KYC, cards, webhooks, and MCP tooling but nothing on settlement reconciliation artifacts. This is a reasonable axis for a card-issuing platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ 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
   Lithic~partialclaimed4/10

   Lithic's Events API supports webhook registration, replay, and searching past events (lithic-docs-6), and the Disputes API mentions chargeback/representment handling (lithic-docs-10), suggesting some post-auth events reach developers programmatically. However, there is no explicit documentation confirming that clearings, refunds, and reversals are delivered as webhooks with stable transaction identifiers guaranteeing ledger consistency. Missing for 10: explicit event types for clearings/refunds/reversals, confirmation of stable transaction IDs across auth-to-settlement lifecycle, and independent/hands-on verification that ledger drift is prevented.

   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “Lithic can help power your cardholders' disputes by handling networking filing for chargebacks and representment responses.”

   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 drawn
   Lithic~partialprobed6/10

   Lithic's docs show a very extensive, API-first surface (cards, KYC, authorization rules with shadow-mode/backtesting, disputes, webhooks, spend limits, sandbox simulation) suggesting the API is the primary interface for core issuing operations, and an official MCP server lets AI agents call this API directly from an editor. However, there is no explicit documentation confirming 1:1 parity between the Lithic Dashboard UI and the API (e.g., admin/reporting features unique to the dashboard), and no OpenAPI spec was discoverable via probe. Missing for 10: explicit UI-vs-API parity statement, confirmation that all dashboard-only features (reporting, team management, etc.) are also API-exposed, and independent verification of parity.

   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “KYC_BYO allows an API user to bypass the Lithic KYC process and create an individual account (available only to users with KYC processes pre…”
   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “you can register and manage webhook URLs, replay webhook messages, control event subscription secrets, and search past events”
   • [claimed-docs] “The sandbox environment has additional endpoints to simulate transaction events originating from a merchant acquirer.”
   • [probe] “official MCP server documented at https://docs.lithic.com/docs/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lithic.com/openapi.json, https://docs.lithic.com/swagger.json, https://docs.lithic.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
   Lithic—none0/10

   Lithic is a card-issuing/payments API platform that stores account, transaction, and card data, so a data-export/portability axis is plausible to ask, but nothing in the evidence pack shows any bulk export tool, open-format data dump, or account-closure data portability feature — only API endpoints for operational use (webhooks, disputes, rules, sandbox).

   ⚑ 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
   Lithic—none0/10

   No evidence in the pack addresses data residency, region selection, or storage location controls for Lithic; all citations concern API functionality, cards, rules, and MCP integration, not data residency choices.

   ⚑ 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
   Lithic—none0/10

   No evidence in the pack addresses data retention policies, deletion of stored data/cardholder data, or AI-native controls over data lifecycle; the pack covers API mechanics, MCP integration, and card/authorization features but nothing about data retention/deletion controls.

   ⚑ 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
   Lithic—none0/10

   The evidence pack covers authorization rules, KYC, disputes, sandbox testing, and MCP tooling, but contains no mention of distinct program types (debit, prepaid, commercial credit, consumer credit) or how Lithic supports each — missing for 10: any documentation of program-type variety, funding models (prepaid vs charge vs credit), or commercial vs consumer credit support.

   ⚑ 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 to Marqeta
   Lithic~partialclaimed4/10

   Lithic's Auth Stream Access (ASA) documents a just-in-time model where the finance lead's system receives an HTTP POST per authorization and returns an approval decision, which is direct evidence of JIT funding control. However, there is no evidence in the pack describing a prefunded-balance funding option or any documentation comparing cash-flow tradeoffs between the two models. Missing for 10: explicit prefunded balance funding mechanism, comparative cash-flow guidance/documentation, and finance-lead-facing tradeoff analysis.

   • [claimed-docs] “ASA requests are delivered as an HTTP POST request during authorization. The request body includes transaction metadata... Your endpoint sho…”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”

   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 drawn
   Lithic~partialcommunity4/10

   Evidence shows Lithic handles several program-management functions (KYC bypass, authorization rules at program/account/card levels, disputes/chargeback filing, spend limits) that reduce the founder's compliance burden, but there is no explicit mention of BIN sponsorship or bank/network membership being abstracted away, and no documented timeline from signup to first live card. Missing for 10: explicit BIN sponsorship/network membership claims, a documented onboarding timeline, and independent confirmation of speed-to-launch.

   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “KYC_BYO allows an API user to bypass the Lithic KYC process and create an individual account (available only to users with KYC processes pre…”
   • [claimed-docs] “Lithic can help power your cardholders' disputes by handling networking filing for chargebacks and representment responses.”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [community] “Card issuing as a service providers like Lithic have brought the technology cost of building neobanks way down, though compliance/legal rema…”

   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 Lithic
   Lithic✓fullclaimed9/10

   Lithic docs show spend limits at account/card level with daily/monthly/all-time windows (lithic-docs-13), plus Authorization Rules v2 enforcing velocity and transaction-count rules at program/account/card levels, entirely server-side (lithic-docs-3, lithic-docs-11). Blog and docs confirm platform-enforced velocity/limit checks during authorization, not client code. Missing for 10: no independent/hands-on third-party confirmation of exact windowing behavior beyond vendor docs.

   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”

   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
   Lithic~partialclaimed6/10

   Lithic's Authorization Rules v2 explicitly support controlling merchant categories (MCC) and can be applied at program/account/card level, with shadow-mode testing before enforcement (lithic-docs-3, lithic-docs-4, lithic-docs-11). However, the evidence never explicitly describes an MCC allowlist/blocklist distinction or a single-merchant lock feature. missing for 10: explicit allowlist vs blocklist configuration semantics, single-merchant lock capability, and independent confirmation these apply strictly at authorization time.

   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure …”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”

   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 to Marqeta
   Lithic~partialclaimed7/10

   Docs show card creation (virtual/physical) plus authorization rules and spend limits that can be scoped to card level, merchant category, and velocity/amount, which supports tight per-card restrictions (lithic-docs-9, lithic-docs-3, lithic-docs-13, lithic-docs-11). However, no explicit documentation of a 'single-use' card type or automatic one-time-use invalidation is present, only generic spend/authorization controls. Missing for 10: explicit single-use card mechanism, explicit exact-amount lock enforcement, and independent/hands-on confirmation that a leaked card number becomes unusable after one transaction.

   • [claimed-docs] “Create a new virtual or physical card. Parameters `shipping_address` and `product_id` only apply to physical cards.”
   • [claimed-docs] “Rules can be applied at three entity levels: Program level: across the entire card program, Account level: to specific accounts, Card level:…”
   • [claimed-docs] “Lithic's Card and Account Spend Limits provide basic controls that help customers manage spend velocity.”
   • [claimed-docs] “Create a virtual card and assign it to a test account... Configure Authorization Rules controlling merchant categories, transaction limits, …”

   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
   Lithic—none0/10

   The evidence pack covers card creation, spend limits, rules, disputes, webhooks, and simulation, but nowhere mentions PIN set/reset endpoints or 3DS enrollment/authentication flows for cardholders. Since Lithic is a card issuing API, this axis clearly applies, but no documentation or endpoint evidence supports it.

   ⚑ 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
   Lithic—none0/10

   No evidence pack items mention network tokens, tokenization, wallet association, or token-specific revocation independent of the PAN; coverage is limited to cards, rules, disputes, and webhooks.

   ⚑ 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 drawn
   Lithic—none0/10

   No evidence in the pack addresses Apple Pay/Google Pay push provisioning, entitlements process, in-wallet card art, or manual provisioning fallback; evidence covers unrelated topics like authorization rules, disputes, webhooks, and MCP integration.

   ⚑ 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