Rank #1 of 5 in Card Issuing Platforms
Install
npm install stripeProducts
Stripe, product by product →Stripe ships more than one product — each judged line competes in its own arena on the same stories as everyone else.
| Line | Arena | Rank | PA Score | Agent-ready |
|---|---|---|---|---|
| Payments | Online Payments | #1/10 | 55/100 | 89/100 |
| Terminal | Mobile & In-Person Payments | #1/4 | 32/100 | 59/100 |
| Atlas | Startup Legal & Incorporation | #6/7 | 11/100 | 32/100 |
| Clerkyacquired | Startup Legal & Incorporation | #4/7 | 14/100 | 37/100 |
| Billing | Billing & Subscriptions | #3/7 | 28/100 | 65/100 |
| Metronomeacquired | Billing & Subscriptions | #5/7 | 21/100 | 28/100 |
| Connect | Marketplace & Platform Payments | #2/6 | 31/100 | 65/100 |
| Radar | Payment Fraud Prevention | #2/5 | 22/100 | 50/100 |
| Tax | Sales Tax Automation | #1/6 | 22/100 | 43/100 |
| TaxJaracquired | Sales Tax Automation | #6/6 | 13/100 | 26/100 |
| Issuingthis page | Card Issuing Platforms | #1/5 | 33/100 | 65/100 |
| Treasury | Banking as a Service | #4/6 | 17/100 | 44/100 |
| Identity | Identity Verification & KYC | #3/6 | 24/100 | 47/100 |
| Financial Connections | Banking Data APIs | #4/7 | 22/100 | 54/100 |
| Crypto & Stablecoins | Stablecoin Payments | #6/6 | 19/100 | 39/100 |
| Agentic Commerce | Agentic Commerce | #1/7 | 37/100 | 80/100 |
Not yet judged (10 — no arena where they compete): Invoicing · Capital · Revenue Recognition · Sigma · Data Pipeline · Managed Payments · Lemon Squeezy · Directory · Projects · Climate
Try itExperimental
See what an agent can do with Stripe Issuing 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); the live MCP handshake runs real requests from our edge, right now — including, where the server allows it, one real read-only tool call (bring your own key for auth-gated servers); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://api.stripe.com/v1/issuing/cards | head -4 # Issuing cards API, 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 Stripe Issuing 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
✓9/10
unlocks → Machine-readable spec · Versioning policy · Full data export
Subscribe to events via webhooks
~5/10
Build against official SDKs
~6/10
Issue scoped/least-privilege API credentials for an agent
✓8/10
Connect an agent via an official MCP server
✓7/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—–
Test against a sandbox environment without touching production data
~6/10
Explore an interactive API reference with runnable examples
~3/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
n/an/a
Operate the product with natural-language commands
~6/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
~3/10
Set up automations that run autonomously in the background
✓7/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
—0/10
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
~4/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
~5/10
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
~6/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
✓8/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
—0/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
~6/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
~4/10
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
~3/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
—0/10
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
~5/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
~5/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
~5/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
✓8/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
—0/10
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
~4/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
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 | 9/10 | Tprobed | |
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 | 7/10 | Tprobed | |
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 | ||
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 | n/a | untested | none yet | |
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 | full | 8/10 | Cclaimed | |
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 | |
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 | full | 8/10 | Tprobed | |
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 | full | 7/10 | Tprobed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Cclaimed | |
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 | partial | 3/10 | Tprobed | |
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 | partial | 3/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 | ||
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 | 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 | partial | 6/10 | Xcommunity | |
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 | 8/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 | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 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 | Tprobed | |
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 | 5/10 | Tprobed | |
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 | partial | 5/10 | Tprobed | |
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 | partial | 4/10 | Cclaimed | |
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 | |
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 | full | 8/10 | Cclaimed | |
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 | 7/10 | Tprobed | |
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 | |
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 | 6/10 | Cclaimed | |
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 | |
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 | 6/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 | 5/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 | 5/10 | Cclaimed | |
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 | 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 | |
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 | 4/10 | Tprobed | |
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 | 3/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 | none | 0/10 | ||
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 | 0/10 | ||
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 | 0/10 | ||
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 | 0/10 | ||
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 | |
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 | |
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 | |
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 | none | 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 | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | n/a | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 38 stories with headroom
What would move Stripe Issuing’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.
Openness — open source, data portability, and self-hosting storiesExport all of my data in open formats and leave
nonemoves PA Scoreimpact 30
No evidence of a data export/portability feature or open-format export mechanism for Stripe Issuing account data; the API allows retrieving records via API calls but there's no documented bulk export tool or open-format data portability guarantee for users to 'take their data and leave'.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
The evidence pack shows explicit probing for OpenAPI/Swagger spec endpoints on docs.stripe.com all returned 404, and no other citation confirms a downloadable OpenAPI or equivalent machine-readable spec; only markdown docs and llms.txt are shown to work.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
nonemoves API qualityimpact 30
Missing: any docs page or changelog describing dated API versions, backward-compatibility guarantees, or deprecation timelines.
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
partialq3/10moves Built-in AIimpact 21
Missing: evidence of general AI-generated insights/suggestions across spending data, dashboard-level AI summaries, or proactive recommendations beyond fraud risk scoring.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
partialq3/10moves API qualityimpact 21
Missing: explicit documentation or demonstration of runnable/interactive code snippets, live API console, or sandboxed example execution within the reference pages.
Auth decisioning — stories about auth decisioning in this arenaEvery authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals
nonemoves PA Scoreimpact 20
Missing: explicit documentation of MCC field, enhanced merchant metadata, wallet/entry-mode indicators, and partial-approval/incremental-auth signal support in the authorization object.
Automation depth — how much of the product can run unattendedPerform bulk operations across many items at once
nonemoves PA Scoreimpact 20
Stripe Issuing's documented API only shows single-resource create endpoints for cards and cardholders, with no evidence of batch/bulk endpoints or documented patterns for issuing or managing many cards/cardholders in one call.
Automation depth — how much of the product can run unattendedSchedule recurring jobs or workflows
nonemoves PA Scoreimpact 20
The evidence pack covers card creation, spending controls, disputes, and real-time authorization webhooks, but nothing describes a scheduling or recurring-job/workflow automation feature (e.g., cron-like triggers, scheduled disbursements, or workflow orchestration) for AI-native users.
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 · 32 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
Issuing docs30 stories
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- Build against official SDKs
- Subscribe to events via webhooks
- Get AI-generated insights and suggestions from my data inside the product
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Explore an interactive API reference with runnable examples
- Test against a sandbox environment without touching production data
- 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
- 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
- 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
- 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
- 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
- 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
API reference11 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- Build against official SDKs
- Explore an interactive API reference with runnable examples
- 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
- Do everything through the API that I can do in the UI
- 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
MCP docs6 stories
- Point an agent at llms.txt or agent-oriented docs
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- 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
Hacker News5 stories
Stripe CLI docs4 stories
OpenAPI spec3 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.stripe.com/v1/issuing/cards | head -4 # Issuing cards API, keyless → 401reproduced$ curl -si https://api.stripe.com/v1/issuing/cards | head -4 # Issuing cards API, [redacted]less → 401 HTTP/2 401 server: nginx date: Tue, 15 Sep 2026 09:12:11 GMT content-type: application/json
$curl -sL https://docs.stripe.com/llms.txt | head -3reproduced$ curl -sL https://docs.stripe.com/llms.txt | head -3 # Stripe Documentation When installing Stripe packages, always check the npm registry for the latest version rather than relying on memorized version numbers. Run `npm view stripe version` or check https://www.npmjs.com/package/stripe before pinning a version. For Python, check https://pypi.org/project/stripe/. Never hardcode an old version number from training data — always install with `@latest` or verify the current version first.
$curl -si -X POST https://mcp.stripe.com/ -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # the remote MCP server Stripe documents at docs.stripe.com/mcpreproduced$ curl -si -X POST https://mcp.stripe.com/ -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # the remote MCP server Stripe documents at docs.stripe.com/mcp HTTP/2 401 www-authenticate: Bearer resource_metadata=https://mcp.stripe.com/.well-known/oauth-protected-resource
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
5 of 14 testable claims verified · 0 contradicted → integrity 36/100
17 distinct capability claims found in Stripe Issuing’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
5
Verified
9
Unverified
0
Contradicted
18
Undersold
Verified (5)
“Create a virtual Issuing Card object via the API in one 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 ↗
“Set spending limits per authorization or per month”
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 codepartialproof ↗
“Simulate test purchases in a sandbox before going live”
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 ↗
“Issue cards on Mastercard, Visa, or both networks without needing direct network membership”
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 ↗
“Official MCP server exposes tools for AI agents to call the Stripe API and search Stripe's knowledge base”
Unverified (10)
“Order physical cards that are printed, shipped, and usable at physical terminals”
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myselfpartialproof ↗
“Approve or decline card authorizations in real time via a synchronous webhook”
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 ↗
“Block spend by merchant category, country, or merchant ID, and restrict card-present usage”
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization timepartialproof ↗
“Push cards into Apple Pay, Google Pay, or Samsung Pay digital wallets”
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 fallbackpartialproof ↗
“Issue replacement cards for expired, damaged, lost, or stolen cards”
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 ↗
“Customize physical card appearance with company logo and accompanying content”
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myselfpartialproof ↗
“Retrieve bank account and routing details via Dashboard or API to fund the program from an external bank account”
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 ↗
“Submit and monitor disputes through resolution via Dashboard or API”
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolutionpartialproof ↗
“Issue single-use virtual cards scoped to a task or session that auto-invalidate after use”
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's usedfullproof ↗
“Get machine-learning risk scores at authorization time covering fraud, dispute risk, and card testing”
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 ↗
Undersold (18)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationfullproof ↗
Drive the product through a documented public APIfullproof ↗
Issue scoped/least-privilege API credentials for an agentfullproof ↗
Get AI-generated insights and suggestions from my data inside the productpartialproof ↗
Set up automations that run autonomously in the backgroundfullproof ↗
Operate the product with natural-language commandspartialproof ↗
Explore an interactive API reference with runnable examplespartialproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Define rules that trigger actions automatically on eventspartialproof ↗
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 ↗
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 ↗
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 pennypartialproof ↗
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 ↗
Claims outside our story set (2)
Real capability claims found in Stripe Issuing’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Create an Issuing Cardholder object that cards can be issued to”
source ↗“Issue cards to third-party connected accounts as a Connect platform”
source ↗
Business model
Published usage-based pricing: $0.10 per virtual card, $3.50 per standard physical card, $15 per dispute, cross-border 1% + $0.30 plus 1% FX; no setup fees; interchange revenue share exists but the split is negotiated, not published.
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
