Lithic vs Adyen Issuing
Lithic
Lithic, Inc.
Lithic wins · 20–5 (20 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round drawnLithic 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”
A direct probe confirms Adyen hosts a working llms.txt (HTTP 200) with real descriptive content pointing to its Issuing and other docs, and individual doc pages are available in markdown form (e.g. relayed-authorisation.md, raise-disputes.md), showing agent-friendly documentation structure. Missing for 10: a full docs-root markdown index (docs/.md returned 404) and an OpenAPI/machine-readable spec endpoint (all candidates 404), so agent tooling coverage is incomplete.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [probe] “PROBE docs-md: HTTP 404 at https://docs.adyen.com/issuing/.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round drawnLithic 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…”
Adyen Issuing is API/webhook-driven (creating payment instruments, relayed authorization webhooks, transaction rules via API calls), which inherently supports headless/programmatic use outside a UI. However, there is no explicit documentation of CI pipelines, SDKs, or automated testing workflows beyond a generic error-simulation endpoint, and the OpenAPI spec discovery probe returned 404s, limiting confidence in API-first automation packaging. Missing for 10: explicit CI/CD integration guides, official SDKs/automation examples, and a discoverable OpenAPI spec.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userConnect an agent via an official MCP server
weight 3 · round to LithicLithic 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, …”
ai-native userUse an official CLI
weight 2 · round drawnLithicnone0/10No 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.
ai-native userDrive the product through a documented public API
weight 3 · round to LithicLithic 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/…”
Multiple documented REST-style API endpoints (paymentInstruments, balanceAccounts, authorization webhooks, disputes API) confirm Adyen Issuing is API-driven and well documented, with llms.txt indicating AI-friendly doc structure. However, no discoverable OpenAPI/Swagger spec was found (all candidate paths 404'd), which weakens machine-readability for AI-native tooling. missing for 10: publicly discoverable OpenAPI/Swagger spec, explicit SDK/agent-friendly API reference, independent corroboration of API usability by third parties.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to LithicLithic 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.”
ai-native userBuild against official SDKs
weight 2 · round drawnLithicnone0/10The 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.
Adyen Issuingnone0/10The evidence pack covers Adyen Issuing's API capabilities (cards, authorization, disputes, webhooks) but contains no mention of official client SDKs in any language, nor any SDK repository links; probes for OpenAPI specs also failed (404). Missing for 10: any reference to official SDKs, language coverage, or SDK documentation/repos.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userSubscribe to events via webhooks
weight 2 · round to LithicLithic'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…”
Adyen Issuing supports webhooks for relayed authorization events with strict reply-time requirements, configured via Customer Area, indicating webhook-based event subscription exists. However, there's no evidence of a general-purpose webhook subscription API/config for arbitrary event types beyond authorization, nor documentation of a standard/self-service webhook management endpoint typical of agentic integration. Missing for 10: broader webhook event catalog (non-authorization events), programmatic webhook subscription/management API, and independent corroboration of webhook reliability.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round drawnLithicnone0/10Lithic'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.
Adyen Issuingnone0/10No evidence of AI-generated insights, analytics, or suggestions surfaced from cardholder/transaction data; all evidence covers card issuing mechanics, authorization rules, and dispute management. Missing for 10: any mention of AI/ML-based insight generation, natural-language querying of data, or suggestion features.
ai-native userSet up automations that run autonomously in the background
weight 2 · round to LithicLithic'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.”
Adyen Issuing supports background automation via transaction rules that automatically approve/decline authorizations without manual intervention, and relayed-authorization webhooks that must be answered programmatically within 2000ms, both of which run autonomously once configured. However, there's no evidence of AI-native automation tooling, scheduling, or agent-style orchestration beyond simple rule-based logic. Missing for 10: AI-specific automation/agent framework, richer workflow/orchestration docs, and independent corroboration of rules running reliably in production.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
ai-native userOperate the product with natural-language commands
weight 2 · round to LithicLithic 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.”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnLithicnone0/10Evidence 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/…”
Adyen Issuingnone0/10No evidence of an interactive API reference with runnable examples; the probe explicitly shows OpenAPI spec files return 404 at all candidate paths, and no docs mention a try-it-now console or embedded runnable code samples.
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round drawnLithicnone0/10A 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…”
Adyen Issuingnone0/10The evidence pack contains no documentation link to an OpenAPI/Swagger spec for Adyen Issuing, and explicit probes for common OpenAPI paths (openapi.json, swagger.json, etc.) all returned 404, indicating no discoverable machine-readable spec.
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to LithicLithic 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, …”
There is only indirect evidence: docs mention forcing verification-check failures to test error handling flows, implying some testing capability, but no explicit documentation of a distinct sandbox/test environment, test API keys, or assurance that test activity never touches production data. missing for 10: explicit sandbox environment description, test-mode credentials, isolation guarantees from production, independent confirmation of sandbox parity.
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round to LithicLithic 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”
Adyen Issuingnone0/10No evidence pack item addresses API versioning or a documented deprecation policy for Adyen Issuing APIs; docs cover product features, webhooks, and disputes but not version lifecycle/deprecation commitments. OpenAPI spec probes also 404'd, providing no supporting evidence of versioning structure.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
Auth decisioning — stories about auth decisioning in this arenaAuth decisioning
Stories about auth decisioning in this arena
Auth context
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 drawnLithicnone0/10Evidence 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.
Adyen Issuingnone0/10The evidence confirms Adyen Issuing sends relayed authorization webhooks for approve/decline decisions, but nothing in the pack documents specific decision-grade fields like merchant name/MCC, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth signals. missing for 10: merchant name/MCC field documentation, enhanced merchant data schema, wallet/entry-mode indicators, partial-approval and incremental-auth support evidence.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Auth stream
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 Adyen IssuingLithic'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…”
Adyen documents relayed authorization webhooks sent to the developer's own servers with an explicit 2000ms reply budget to approve/decline, plus transaction rules as an automatic fallback/complement to real-time decisioning. Missing for 10: explicit documentation of what happens on timeout (default accept/decline behavior) and independent/hands-on corroboration beyond Adyen's own docs.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Simulation
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 LithicDocs 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, …”
Docs confirm sandbox-testable authorization webhooks (relayed authorization) and a dedicated way to force verification-check failures for testing error handling, which supports testing decline/approval logic pre-production. However, there's no evidence of simulating the full lifecycle (clearings, reversals, refunds) in sandbox specifically for auth-decisioning testing. missing for 10: explicit sandbox simulation of clearings, reversals, and refunds; end-to-end lifecycle test guide; independent/hands-on confirmation of sandbox fidelity.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnLithicnone0/10No 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.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to LithicLithic'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…”
Adyen Issuing supports rule-based automation via transaction rules that automatically approve/decline authorizations and relayed authorization webhooks that let servers respond within 2000ms based on custom logic, which qualifies as event-triggered automation. However, this is transaction/authorization-scoped rather than a general-purpose 'define rules for any event' engine, and there's no evidence of a broader rules/workflow builder covering arbitrary events beyond card authorizations and disputes. Missing for 10: evidence of a general event-driven rules engine spanning all Issuing events (not just authorizations), and any AI-native tooling or examples for constructing such rules programmatically.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Card lifecycle — stories about card lifecycle in this arenaCard lifecycle
Stories about card lifecycle in this arena
Lifecycle states
developerThe full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
weight 2 · round to Adyen IssuingEvidence 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:…”
Docs confirm activate, suspend (pause), and permanently close via API (docs-10), plus balance/account management (docs-11, docs-14), giving core lifecycle coverage. However, evidence does not explicitly show 'unpause' as distinct from activate, nor a documented lost/stolen reporting endpoint or a reissue-with-replacement-linked-to-original flow — missing for 10: explicit unpause/reactivate API call, lost-or-stolen reporting endpoint, and reissue/replacement-linkage API documentation.
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Physical cards
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 LithicDocs 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.”
Docs confirm Adyen Issuing lets you create fully customizable physical (and virtual) cards via API without a direct manufacturer relationship, but the evidence pack has no mention of bulk ordering, shipping method selection, or shipment tracking capabilities. missing for 10: bulk card order API, shipping method configuration, shipment tracking documentation/evidence.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
Virtual cards
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 LithicDocs 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.”
Docs confirm Adyen Issuing lets you create fully customizable virtual and physical cards via the platform (adyen-issuing-docs-1) and manage their lifecycle (activate/suspend/close) via API (adyen-issuing-docs-10), implying some programmatic card creation, but nothing in the evidence confirms that PAN/CVV/expiry are returned synchronously in the same API call, nor is there any mention of a self-serve sandbox-to-production path without a sales/onboarding process. missing for 10: explicit API response schema showing PAN/CVV/expiry returned instantly, evidence of self-serve account activation from sandbox to live without a sales cycle.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
Issuing agent access — stories about issuing agent access in this arenaIssuing agent access
Stories about issuing agent access in this arena
Agent cards
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 LithicLithic 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.”
Adyen Issuingnone0/10Adyen Issuing docs show generic virtual card creation, transaction rules, and authorization controls, but nothing in the evidence pack mentions AI agents, agentic purchasing, or a named 'agent card' use case — the specific vendor-documented AI-agent framing required by the story is absent. missing for 10: any mention of AI agents, agent-scoped cards, or documentation naming this use case by name.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Agent operations
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 LithicLithic'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”
Adyen Issuing's API supports core card-program actions an agent would need—creating cards, activating/suspending/closing them, updating balance account linkage, and defining transaction rules for spend control (docs-1, docs-3, docs-10, docs-11)—but there is no mention of an MCP surface, no explicit scoped API-credential/permission model, and no clear API endpoint documentation for reading balances/transaction history (only a Customer Area UI view is cited, docs-13). missing for 10: MCP server/tool surface, scoped API-key/credential scoping documentation, explicit balance/transaction-read API endpoints.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “Viewing card payments in the Customer Area”
Issuing compliance — stories about issuing compliance in this arenaIssuing compliance
Stories about issuing compliance in this arena
Kyc
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 LithicEvidence 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…”
Adyen Issuingnone0/10The evidence pack only mentions generic 'verification checks' in a testing context (adyen-issuing-docs-12) with no documented KYC/KYB data requirements, review states, or re-verification flows for cardholders or businesses. No citations describe onboarding verification processes, only card lifecycle, authorization, and dispute handling.
Pci scope
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 drawnLithicnone0/10No 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.
Issuing disputes — stories about issuing disputes in this arenaIssuing disputes
Stories about issuing disputes in this arena
Dispute filing
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 drawnLithic 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”
Adyen documents a Raise Disputes API letting cardholders initiate disputes/fraud reports, but evidence submission is only via a pilot manual zip-upload through the Customer Area rather than a full programmatic evidence API, and there's no documentation of network reason codes, provisional credit handling, or dispute-specific status webhooks through resolution. missing for 10: network reason code mapping, provisional credit issuance/tracking, dispute status webhooks/resolution lifecycle, non-pilot programmatic evidence submission.
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
Fraud monitoring
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 LithicLithic 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.”
Adyen Issuing lets ops build transaction rules and relayed authorization logic to approve/decline in real time, and provides card suspend/close controls plus a Raise Disputes API for cardholders to report fraud or lost cards — covering blocking and dispute workflows. However there is no evidence of network fraud scores or Adyen's own risk models surfaced at auth time, no mention of suspicious-activity alerting, and no explicit card-reissue tooling (only activate/suspend/close). missing for 10: fraud-score/model signals at authorization, proactive suspicious-activity alerts, dedicated reissue flow for compromised cards.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
Ledger settlement — stories about ledger settlement in this arenaLedger settlement
Stories about ledger settlement in this arena
Balances
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 Adyen IssuingLithicnone0/10The 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.
Docs show balance accounts/payment instruments architecture, authorization webhooks, and a Customer Area view of card payments, which supports basic balance and transaction visibility. However there is no evidence of a transaction ledger explicitly tying each authorization to its clearing event, nor of settlement/reconciliation reporting that ties to the penny. missing for 10: settlement report documentation, authorization-to-clearing ledger detail, reconciliation accuracy claims or tooling.
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “Viewing card payments in the Customer Area”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Recon reports
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 drawnLithicnone0/10No 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'.
Adyen Issuingnone0/10The evidence pack covers card issuance, authorization webhooks, disputes, and balance accounts, but contains no mention of daily settlement files, report APIs, or interchange/fee/network adjustment reconciliation artifacts. No documentation references machine-readable reconciliation exports for finance systems.
Settlement events
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 LithicLithic'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.”
Evidence confirms authorization webhooks (relayed auth) and a dispute/chargeback API, but nothing in the pack documents webhooks for clearings, refunds, or reversals, nor stable transaction identifiers tying post-auth events back to the original authorization for ledger reconciliation. missing for 10: clearing/refund/reversal webhook events, explicit stable transaction ID linkage across auth→clearing→refund, independent corroboration of ledger accuracy.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnLithic'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/…”
Docs show extensive API coverage (card creation, authorization rules, balance management, card lifecycle, disputes) mirroring Customer Area capabilities, and Adyen exposes APIs as the primary interface. However, some features like uploading dispute zip files and viewing card payments are explicitly Customer Area-only (pilot feature), and no discoverable OpenAPI spec was found via probes, undercutting full API-parity claims. missing for 10: evidence of API equivalents for Customer-Area-only dispute upload and payment viewing features, a public OpenAPI/machine-readable spec confirming full API surface, independent confirmation of full UI-API parity.
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
- [claimed-docs] “Viewing card payments in the Customer Area”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userExport all of my data in open formats and leave
weight 3 · round drawnLithicnone0/10Lithic 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).
Adyen Issuingnone0/10No evidence of any data export/portability feature or open-format bulk export capability; documentation covers card issuing, authorization, disputes, and management APIs but nothing about exporting all account/transaction data or facilitating account closure with data portability.
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnLithicnone0/10No 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.
ai-native userControl data retention and deletion
weight 2 · round drawnLithicnone0/10No 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.
Adyen Issuingnone0/10The evidence pack covers card issuing, authorization, disputes, and management features but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management for AI-native users. This is an applicable axis for a payments platform handling sensitive cardholder data, but no evidence supports it.
Program management — stories about program management in this arenaProgram management
Stories about program management in this arena
Card types
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 drawnLithicnone0/10The 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.
Adyen Issuingnone0/10The evidence only shows generic card creation (virtual/physical, Visa/Mastercard) and balance-pooling/per-card balance options, but never distinguishes or confirms support for debit, prepaid, commercial credit, and consumer credit program types. Missing for 10: explicit documentation of credit line/revolving credit program support, commercial vs consumer credit distinctions, and debit vs prepaid program configuration options.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Funding models
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 Adyen IssuingLithic'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.”
Docs confirm relayed authorization (JIT-style, real-time approve/decline within 2000ms) and pooled vs per-card balance funding options, showing both funding models exist. However, there is no explicit finance-lead-oriented documentation contrasting prefunded vs JIT cash-flow tradeoffs. missing for 10: explicit cash-flow tradeoff documentation, guidance on choosing between prefunded and JIT funding, finance-focused framing rather than developer/webhook mechanics.
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Program launch
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 drawnEvidence 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…”
Docs show Adyen issues Visa/Mastercard cards and manages authorization, transaction rules, and card lifecycle, implying Adyen handles network membership so founders don't need their own bank charter — but there is no explicit statement about BIN sponsorship, no discussion of becoming/not becoming a bank, and no documented timeline from signup to first live card. missing for 10: explicit BIN sponsorship/network membership language, articulation that founders avoid bank licensing, and a documented signup-to-live-card timeline.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Spend controls — stories about spend controls in this arenaSpend controls
Stories about spend controls in this arena
Limits
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 LithicLithic 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 …”
Adyen Issuing docs reference configurable 'transaction rules to automatically approve or decline authorizations' (docs-3) and relayed authorization webhooks giving full custom control (docs-2, docs-5, docs-6), implying some platform-side rule enforcement exists, but the evidence never specifies per-card/per-cardholder amount caps over daily/monthly/all-time windows or transaction-count velocity rules as platform-native controls. Missing for 10: explicit documentation of spend-limit configuration fields (daily/monthly/all-time caps), velocity/transaction-count rule specifics, and confirmation these are enforced natively rather than via custom relayed-authorization logic.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Merchant controls
ops userRestrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
weight 2 · round to LithicLithic'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.”
Adyen Issuing supports configurable 'transaction rules' to automatically approve or decline authorizations and relayed authorization webhooks allowing custom logic at auth time, which could implement MCC or merchant restrictions, but the evidence never explicitly describes MCC allow/blocklists or single-merchant locking as a documented feature. missing for 10: explicit documentation of MCC-based allow/block rules, single-merchant lock configuration, and confirmation these are evaluated at authorization time.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Scoped cards
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 LithicDocs 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, …”
Adyen Issuing supports transaction rules and real-time relayed authorization webhooks that let a developer approve/decline based on merchant, amount, or other criteria, and cards can be activated/suspended/closed, giving the building blocks for tight scoping. However, there is no explicit documented 'single-use card' primitive or per-card merchant-lock/exact-amount enforcement — that logic must be built entirely by the developer via custom rules/webhook logic rather than a first-class feature. Missing for 10: native single-use card issuance, built-in per-merchant locking, built-in exact-amount matching, independent confirmation these controls work as designed.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization
Stories about wallets tokenization in this arena
Credentials
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 to Adyen IssuingLithicnone0/10The 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.
Docs confirm 3DS enrollment via API (OTP and out-of-band authentication) which addresses regional 3DS requirements without support tickets, and card lifecycle actions (activate/suspend/close, balance account updates) are API-driven. However, there is no evidence of PIN set/reset flows being exposed through the API — missing for 10: PIN set API, PIN reset API, any documentation of PIN management endpoints.
- [claimed-docs] “There are two ways to enroll your Adyen-issued cards in 3D Secure: One-time password authentication ... Out-of-band authentication”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
Tokenization
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 drawnLithicnone0/10No 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.
Adyen Issuingnone0/10The evidence pack covers card creation, authorization handling, transaction rules, disputes, 3DS enrollment, and card lifecycle management, but contains no mention of network tokens, tokenization, wallet/merchant token visibility, or token-specific revocation independent of the PAN.
Wallet provisioning
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 drawnLithicnone0/10No 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.
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableLithicn/aLithic is a card-issuing/payments API platform, not an AI agent or assistant that itself acts as an MCP client consuming external tool servers. The evidence shows Lithic publishes an MCP *server* so other AI assistants can use Lithic's tools — the reverse direction from this story, which asks whether users can plug MCP servers into Lithic. This client-side axis is a category error for this product type.
- [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”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableLithicnone0/10Lithic's evidence describes an MCP server that lets external AI assistants (in the user's editor) connect to Lithic's API/docs, not a built-in assistant embedded inside Lithic's own product/dashboard for delegating tasks. No evidence of an in-product AI assistant feature exists in the pack.
- [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, …”
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableLithicn/aLithic is a card issuing/payments API platform, not a workflow/job-scheduling or automation orchestration product; scheduling recurring jobs/workflows is outside its product category (wrong axis) rather than a missing feature.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableLithicnone0/10There'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 …”
ai-native userRead the product's source under an open license
weight 2 · not comparableLithicn/aLithic is a closed proprietary fintech/card-issuing API platform, not an open-source project; there's no indication its source code is published under any license. Source availability is not a fair axis for this kind of commercial financial API product.
ai-native userSelf-host the core product
weight 3 · not comparableLithicn/aLithic is a hosted card-issuing/payments API/SaaS platform, not open-source infrastructure meant to be self-hosted; self-hosting is a category error for this type of product.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableLithicn/aLithic is a card issuing/payments API platform, not an AI model provider or data-processing service where 'AI training data usage' opt-outs would apply; this privacy axis is a category error for this product type.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableLithicn/aLithic is a card issuing/payments API platform, not an AI assistant or telemetry-collecting client tool; opting out of telemetry/usage tracking is not a relevant axis for this kind of product's evidence pack, which focuses on payment infrastructure APIs.