Lithic vs Highnote

Agent access

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

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

   Highnote✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

   Highnote~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   Highnote—none0/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Highnote—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

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

   Highnote✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Highnote—none0/10

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

   ⚑ flag

7. ai-native userBuild against official SDKs

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

   Highnote~partialprobed6/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Highnote✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Agentic features

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

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

   Highnote—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Highnote—none0/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   Highnote~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Highnote—none0/10

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

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

   proof ↗⚑ flag

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

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

   Highnote✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Highnote—none0/10

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

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

   proof ↗⚑ flag

Auth context

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

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

   Highnote~partialclaimed3/10

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

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

   proof ↗⚑ flag

Auth stream

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

Simulation

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Highnote~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

Lifecycle states

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

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

   Highnote~partialclaimed3/10

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

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

   proof ↗⚑ flag

Physical cards

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

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

   Highnote~partialclaimed3/10

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

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

   proof ↗⚑ flag

Virtual cards

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

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

   Highnote~partialclaimed5/10

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

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

   proof ↗⚑ flag

Agent cards

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

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

   Highnote✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Agent operations

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

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

   Highnote~partialprobed5/10

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

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

   proof ↗⚑ flag

Kyc

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

Pci scope

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

Dispute filing

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

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

   Highnote~partialclaimed3/10

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

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

   proof ↗⚑ flag

Fraud monitoring

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

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

   Highnote~partialclaimed4/10

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

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

   proof ↗⚑ flag

Balances

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

Recon reports

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

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

   Highnote~partialclaimed4/10

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

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

   proof ↗⚑ flag

Settlement events

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

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

   Highnote~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Highnote~partialprobed6/10

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

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

   proof ↗⚑ flag

Card types

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

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

   Highnote~partialclaimed3/10

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

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

   proof ↗⚑ flag

Funding models

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

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

   Highnote~partialclaimed5/10

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

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

   proof ↗⚑ flag

Program launch

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

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

   Highnote~partialclaimed5/10

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

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

   proof ↗⚑ flag

Limits

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

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

   Highnote✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Merchant controls

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

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

   Highnote~partialclaimed7/10

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

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

   proof ↗⚑ flag

Scoped cards

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

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

   Highnote✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Credentials

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

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

   Highnote—none0/10

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

   ⚑ flag

Tokenization

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

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

   Highnote—none0/10

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

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

   proof ↗⚑ flag

Wallet provisioning

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

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

   Highnote—none0/10

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

   ⚑ flag