Rank #2 of 5 in Card Issuing Platforms
Install
npm install lithicTry itExperimental
See what an agent can do with Lithic before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://api.lithic.com/v1/cards | head -3 # keyless → 401recorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Auth decisioning — stories about auth decisioning in this arenaAuth decisioningevidence →
Stories about auth decisioning in this arena
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Card lifecycle — stories about card lifecycle in this arenaCard lifecycleevidence →
Stories about card lifecycle in this arena
Issuing agent access — stories about issuing agent access in this arenaIssuing agent accessevidence →
Stories about issuing agent access in this arena
Issuing compliance — stories about issuing compliance in this arenaIssuing complianceevidence →
Stories about issuing compliance in this arena
Issuing disputes — stories about issuing disputes in this arenaIssuing disputesevidence →
Stories about issuing disputes in this arena
Ledger settlement — stories about ledger settlement in this arenaLedger settlementevidence →
Stories about ledger settlement in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Program management — stories about program management in this arenaProgram managementevidence →
Stories about program management in this arena
Spend controls — stories about spend controls in this arenaSpend controlsevidence →
Stories about spend controls in this arena
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenizationevidence →
Stories about wallets tokenization in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Lithic stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Official SDKs · Machine-readable spec · Official CLI · Full data export
Subscribe to events via webhooks
✓8/10
Build against official SDKs
—–
Issue scoped/least-privilege API credentials for an agent
~6/10
Connect an agent via an official MCP server
✓8/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
~4/10
Test against a sandbox environment without touching production data
✓8/10
Explore an interactive API reference with runnable examples
—0/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
✓8/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
—0/10
Operate the product with natural-language commands
✓7/10
Plug MCP servers into this product so it can use their tools
n/an/a
Get AI-generated insights and suggestions from my data inside the product
—–
Set up automations that run autonomously in the background
~6/10
Auth decisioning — stories about auth decisioning in this arenaAuth decisioning
Stories about auth decisioning in this arena
Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals
—–
Approve 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
~6/10
Simulate 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
~6/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Card lifecycle — stories about card lifecycle in this arenaCard lifecycle
Stories about card lifecycle in this arena
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
~3/10
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
~4/10
Create 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
~5/10
Issuing agent access — stories about issuing agent access in this arenaIssuing agent access
Stories about issuing agent access in this arena
Give 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
✓7/10
An 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
~6/10
Issuing compliance — stories about issuing compliance in this arenaIssuing compliance
Stories about issuing compliance in this arena
Cardholder 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
~3/10
Show 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
—–
Issuing disputes — stories about issuing disputes in this arenaIssuing disputes
Stories about issuing disputes in this arena
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution
~4/10
The 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
~5/10
Ledger settlement — stories about ledger settlement in this arenaLedger settlement
Stories about ledger settlement in this arena
See 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
—–
I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically
—–
Post-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
~4/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Program management — stories about program management in this arenaProgram management
Stories about program management in this arena
The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail
—–
Choose 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
~4/10
Launch 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
~4/10
Spend controls — stories about spend controls in this arenaSpend controls
Stories about spend controls in this arena
Set 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
✓9/10
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
~6/10
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
~7/10
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization
Stories about wallets tokenization in this arena
Cardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets
—–
Network 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
—–
Cards 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
—–
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | 0/10 | ||
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Cclaimed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Tprobed | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Cclaimed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Cclaimed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Tprobed | |
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 4/10 | Cclaimed | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | full | 8/10 | Cclaimed | |
Set 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 C Limits | ops user | Spend controls — stories about spend controls in this arenaSpend controls | 3 | full | 9/10 | Cclaimed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | full | 7/10 | Cclaimed | |
Give 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 C Agent cards | ai-native user | Issuing agent access — stories about issuing agent access in this arenaIssuing agent access | 3 | full | 7/10 | Cclaimed | |
Approve 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 C Auth stream | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 3 | partial | 6/10 | Cclaimed | |
Create 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 C Virtual cards | developer | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 3 | partial | 5/10 | Cclaimed | |
Launch 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 C Program launch | founder | Program management — stories about program management in this arenaProgram management | 3 | partial | 4/10 | Xcommunity | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | none | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
See 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 C Balances | finance lead | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 3 | none | untested | none yet | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used C Scoped cards | developer | Spend controls — stories about spend controls in this arenaSpend controls | 2 | partial | 7/10 | Cclaimed | |
An 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 C Agent operations | ai-native user | Issuing agent access — stories about issuing agent access in this arenaIssuing agent access | 2 | partial | 6/10 | Tprobed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 6/10 | Tprobed | |
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time C Merchant controls | ops user | Spend controls — stories about spend controls in this arenaSpend controls | 2 | partial | 6/10 | Cclaimed | |
Simulate 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 C Simulation | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 2 | partial | 6/10 | Cclaimed | |
The 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 C Fraud monitoring | ops user | Issuing disputes — stories about issuing disputes in this arenaIssuing disputes | 2 | partial | 5/10 | Cclaimed | |
Choose 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 C Funding models | finance lead | Program management — stories about program management in this arenaProgram management | 2 | partial | 4/10 | Cclaimed | |
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution C Dispute filing | ops user | Issuing disputes — stories about issuing disputes in this arenaIssuing disputes | 2 | partial | 4/10 | Cclaimed | |
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself C Physical cards | ops user | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 2 | partial | 4/10 | Cclaimed | |
Post-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 C Settlement events | developer | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 2 | partial | 4/10 | Cclaimed | |
Cardholder 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 C Kyc | ops user | Issuing compliance — stories about issuing compliance in this arenaIssuing compliance | 2 | partial | 3/10 | Cclaimed | |
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close C Lifecycle states | developer | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 2 | partial | 3/10 | Cclaimed | |
Cardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets C Credentials | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | untested | none yet | |
Cards 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 C Wallet provisioning | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | untested | none yet | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals C Auth context | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 2 | none | untested | none yet | |
I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically C Recon reports | finance lead | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 2 | none | untested | none yet | |
Network 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 C Tokenization | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | untested | none yet | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | untested | none yet | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | n/a | untested | none yet | |
Show 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 C Pci scope | developer | Issuing compliance — stories about issuing compliance in this arenaIssuing compliance | 2 | none | untested | none yet | |
The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail C Card types | founder | Program management — stories about program management in this arenaProgram management | 2 | none | untested | none yet | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | none | 0/10 |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 38 stories with headroom
What would move Lithic’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productDelegate tasks to a built-in AI assistant inside the product
nonemoves Built-in AIimpact 45
Lithic'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.
Ledger settlement — stories about ledger settlement in this arenaSee 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
nonemoves PA Scoreimpact 30
Missing: balance/ledger API docs, authorization-to-clearing linkage evidence, settlement/reconciliation reporting documentation.
Openness — open source, data portability, and self-hosting storiesExport all of my data in open formats and leave
nonemoves PA Scoreimpact 30
Lithic is a card-issuing/payments API platform that stores account, transaction, and card data, so a data-export/portability axis is plausible to ask, but nothing in the evidence pack shows any bulk export tool, open-format data dump, or account-closure data portability feature — only API endpoints for operational use (webhooks, disputes, rules, sandbox).
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
nonemoves Built-in AIimpact 30
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.
Agenticness — how well agents can access and operate the productUse an official CLI
nonemoves agent-readyimpact 30
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.
Agenticness — how well agents can access and operate the productBuild against official SDKs
nonemoves agent-readyimpact 30
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.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Evidence shows a docs.lithic.com/reference section exists (e.g.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
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.
Showing the top 8 of 38 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map7 surfaces · 28 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs27 stories
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Test against a sandbox environment without touching production data
- Rely on versioned APIs with a documented deprecation policy
- Approve 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
- Simulate 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
- Define rules that trigger actions automatically on events
- The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
- Create 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
- Give 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
- An 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
- Cardholder 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
- File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution
- The 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
- Post-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
- Do everything through the API that I can do in the UI
- Choose 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
- Launch 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
- Set 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
- Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
- Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
Blog docs11 stories
- Connect an agent via an official MCP server
- Issue scoped/least-privilege API credentials for an agent
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Test against a sandbox environment without touching production data
- Simulate 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
- Give 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
- An 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
- Set 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
- Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
- Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
API reference10 stories
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
- Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
- Create 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
- Give 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
- An 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
- The 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
- Do everything through the API that I can do in the UI
- Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
Solutions docs4 stories
- Issue scoped/least-privilege API credentials for an agent
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Give 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
llms.txt3 stories
OpenAPI spec2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si https://api.lithic.com/v1/cards | head -3 # keyless → 401reproduced$ curl -si https://api.lithic.com/v1/cards | head -3 # [redacted]less → 401 HTTP/2 401 date: Tue, 15 Sep 2026 09:12:12 GMT content-type: application/json
$curl -sL https://docs.lithic.com/llms.txt | head -3reproduced$ curl -sL https://docs.lithic.com/llms.txt | head -3 # Lithic Developer Documentation Documentation > The Lithic developer API provides a predictable and programmatic interface to create and configure virtual cards. Get real-time payment data, programmatically issue cards, configure card permissions, and set spending limits all through the API.
$curl -s -X POST https://docs.lithic.com/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # keyless initialize completes with serverInforeproduced$ curl -s -X POST https://docs.lithic.com/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # [redacted]less initialize completes with serverInfo
"serverInfo":{"name":"Lithic Developer Documentation","version":"2026-07-01"}
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
2 of 14 testable claims verified · 1 contradicted → integrity 0/100
14 distinct capability claims found in Lithic’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
2
Verified
11
Unverified
1
Contradicted
15
Undersold
Verified (2)
“AI assistant integration lets you search docs, inspect schemas, generate code, and run live API calls from your editor”
“Platform positions itself for autonomous, AI-powered issuing, payments, and card controls”
An 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 credentialspartialproof ↗
Unverified (11)
“Authorization Stream Access delivers each auth as a real-time HTTP POST your endpoint must approve or decline with a 200 response”
Approve 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 controlpartialproof ↗
“Authorization rules can be scoped to the whole program, a specific account, or a single card”
Define rules that trigger actions automatically on eventsfullproof ↗
“Sandbox has extra endpoints to simulate merchant-acquirer transaction events for testing”
Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipespartialproof ↗
“Webhook system lets you register/manage endpoint URLs, replay past events, manage subscription secrets, and search event history”
“API requests can specify an api-version header to pin to a particular API version”
Rely on versioned APIs with a documented deprecation policypartialproof ↗
“KYC_BYO option lets pre-approved API users bypass Lithic's KYC process and create individual accounts themselves”
Cardholder 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 flowspartialproof ↗
“Create a virtual card via API in a single call”
Create 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 cyclepartialproof ↗
“Create physical cards via API with shipping address and product/card-art selection”
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myselfpartialproof ↗
“Lithic can file chargeback disputes and handle network representment on cardholders' behalf”
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolutionpartialproof ↗
“Sandbox testing workflow: create a test card, configure MCC/limit/velocity rules, and run transactions to validate rule behavior”
Test against a sandbox environment without touching production datafullproof ↗
“Card- and account-level spend limits control spend velocity”
Set 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 codefullproof ↗
Contradicted (1)
“Draft rules can run in shadow mode to observe live auth traffic plus backtesting/performance reports before going live”
Undersold (15)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationpartialproof ↗
Drive the product through a documented public APIfullproof ↗
Issue scoped/least-privilege API credentials for an agentpartialproof ↗
Set up automations that run autonomously in the backgroundpartialproof ↗
Operate the product with natural-language commandsfullproof ↗
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently closepartialproof ↗
Give 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 namefullproof ↗
The 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 cardspartialproof ↗
Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never driftspartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documentedpartialproof ↗
Launch 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 documentedpartialproof ↗
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization timepartialproof ↗
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's usedpartialproof ↗
Business model
No public rate card (lithic.com/pricing redirects home): free self-serve sandbox, production programs are sales-led with per-card and interchange economics negotiated per program.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
