Stripe Issuing vs Adyen Issuing
usage-based
·usage-based
Stripe Issuing wins · 22–3 (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 drawnStripe's docs.stripe.com/llms.txt returns HTTP 200 and .md variants of docs pages (e.g., issuing.md, mcp.md) are directly accessible, confirming agent-oriented documentation formats exist and are served for Issuing docs. There's also an official MCP server for AI agents to interact with the Stripe API. missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully for Issuing-specific tasks, and no explicit Issuing-specific llms.txt (only the site-wide one).
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/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 to Stripe IssuingStripe Issuing exposes a complete REST API for creating cards/cardholders, real-time authorization webhooks, and a documented test-simulation mode for pre-production automation, plus an official CLI (stripe-cli) — all consistent with headless/CI operation. Community evidence confirms real-world usage of the API for automated QA workflows. missing for 10: explicit CI/pipeline integration guides or SDK examples showing scripted deployment in CI systems.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Test the integration: Simulate test purchases before going live.”
- [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
- [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
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 Stripe IssuingStripe documents an official MCP server that lets AI agents interact with the Stripe API (which includes Issuing endpoints) and search its knowledge base, confirmed by both docs and a probe hit at docs.stripe.com/mcp. However, the evidence doesn't detail Issuing-specific MCP tools or independent hands-on confirmation of agent usage with Issuing specifically. Missing for 10: explicit list of Issuing-specific MCP tool calls, independent/community verification of agent integration.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
ai-native userUse an official CLI
weight 2 · round to Stripe IssuingStripe documents an official CLI (stripe-issuing-probe-5) as part of the broader Stripe platform, which would apply to Issuing API usage, but the evidence pack contains no Issuing-specific CLI commands, examples, or independent hands-on confirmation of CLI use for Issuing workflows. missing for 10: Issuing-specific CLI command examples, hands-on/community confirmation of using the CLI for Issuing tasks, documentation tying the CLI explicitly to agentic/AI-native workflows.
- [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
ai-native userDrive the product through a documented public API
weight 3 · round to Stripe IssuingStripe Issuing exposes a comprehensive, well-documented REST API covering cards, cardholders, webhooks, disputes, spending controls, and funding, plus an official CLI and MCP server for programmatic/agentic access, corroborated by a live probe of docs and community reports of API-driven automation. missing for 10: a directly reachable machine-readable OpenAPI spec (probe returned 404 on standard paths).
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
- [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
- [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
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 Stripe IssuingStripe Issuing has a dedicated agents doc describing issuing virtual cards scoped to a single task/session that auto-invalidate after use, plus fine-grained spending controls (merchant category, country, amount limits) and real-time authorization webhooks that let an issuer approve/decline per-transaction — together these constitute least-privilege, scoped credential issuance for agentic use. missing for 10: independent/hands-on third-party validation of the agent-scoping feature specifically (only vendor docs), and no evidence of programmatic revocation/audit-trail APIs tailored to agent credential lifecycle beyond card invalidation.
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
ai-native userBuild against official SDKs
weight 2 · round to Stripe IssuingStripe's docs reference the Issuing API and general Stripe SDK/CLI/MCP infrastructure, implying official SDKs exist for building Issuing integrations, but the evidence pack contains no direct mention of language-specific SDK libraries (e.g., stripe-node, stripe-python) or their coverage of Issuing endpoints specifically. missing for 10: explicit documentation of official SDK libraries and language coverage for Issuing, code samples showing SDK usage for Issuing objects, independent developer corroboration of SDK quality for Issuing specifically.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
- [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
- [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
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 drawnDocs confirm Issuing supports a synchronous webhook for real-time authorization decisions, showing webhook-based event delivery exists, but the pack contains no evidence of broader webhook event subscription (e.g., issuing_card.*, issuing_dispute.* events, webhook endpoint management API) that a general 'subscribe to events' story implies. Missing for 10: documentation of the full Issuing webhook event catalog, webhook endpoint setup/management API, and any AI-native tooling (e.g. MCP) for consuming these events.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
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 to Stripe IssuingDocs mention machine-learning-generated risk scores (fraud, dispute risk, card testing) surfaced on every authorization, which is a narrow form of AI-generated insight from transaction data, but there's no evidence of broader in-product AI insights/suggestions (e.g., spend analytics, natural-language querying, dashboard copilot) beyond this fraud-risk scoring. Missing for 10: evidence of general AI-generated insights/suggestions across spending data, dashboard-level AI summaries, or proactive recommendations beyond fraud risk scoring.
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
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 Stripe IssuingStripe Issuing exposes real-time authorization webhooks, spending controls, and agent-specific virtual cards that auto-invalidate after a task/session (docs-4, docs-5, docs-12, docs-13), enabling autonomous, unattended card issuance and approval flows. It also ships an official MCP server so AI agents can drive the Issuing API programmatically (docs-16, probe-4), supporting background automation setups. Missing for 10: independent/hands-on evidence of a fully autonomous end-to-end automation running in production, and more detail on scheduling/orchestration beyond webhook-triggered decisions.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
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 Stripe IssuingStripe documents an official MCP server that lets AI agents interact with the Stripe API (including Issuing) via natural-language-driven tool calls, and separately markets Issuing itself for agentic/AI-driven card issuance. However there's no hands-on evidence of natural-language command execution specifically against Issuing endpoints, and the CLI (a non-NL surface) is the only other control surface mentioned. Missing for 10: independent/hands-on proof of NL commands operating Issuing resources, documentation of MCP tool coverage for Issuing-specific actions.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to Stripe IssuingThe evidence pack shows Stripe publishes detailed API reference pages for Issuing endpoints (cards, cardholders, etc.) and markdown-accessible docs, but nothing explicitly confirms an interactive, runnable-example experience (e.g., live code sandboxes or in-browser request execution) — the OpenAPI spec probe even returned 404s. Missing for 10: explicit documentation or demonstration of runnable/interactive code snippets, live API console, or sandboxed example execution within the reference pages.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.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 drawnStripe Issuingnone0/10The 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.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 Stripe IssuingDocs explicitly mention simulating test purchases before going live, and community evidence shows a user relying on the API for QA/test automation, supporting a sandbox-style workflow. However, there's no detailed documentation of Stripe's standard test-mode/live-mode key separation or confirmation that all Issuing features (card issuance, authorizations) work identically in test mode without any production side-effects. missing for 10: explicit test-mode vs live-mode API key documentation, hands-on confirmation of full feature parity in test mode, independent verification of sandbox fidelity.
- [claimed-docs] “Test the integration: Simulate test purchases before going live.”
- [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
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 drawnStripe Issuingnone0/10The evidence pack covers Issuing features (cards, cardholders, controls, agents, MCP) but contains no documentation of API versioning scheme or a deprecation policy. Missing for 10: any docs page or changelog describing dated API versions, backward-compatibility guarantees, or deprecation timelines.
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 drawnStripe Issuingnone0/10The evidence covers real-time authorization webhooks, spending controls (merchant category, MID), risk scores, and wallet support, but there is no evidence that Stripe surfaces MCC codes, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth signals within the authorization payload itself. Missing for 10: explicit documentation of MCC field, enhanced merchant metadata, wallet/entry-mode indicators, and partial-approval/incremental-auth signal support in the authorization object.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
- [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”
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 IssuingStripe Issuing explicitly documents a synchronous webhook for real-time authorization approve/decline decisions, matching the core of the story. However, the evidence pack does not show documentation of the exact timeout window or how developers can configure/control the fallback (approve/decline) behavior when their endpoint doesn't respond in time. Missing for 10: explicit timeout budget details, developer-configurable fallback decision, and independent/hands-on confirmation of real-time latency behavior.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
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 drawnDocs confirm a sandbox/test mode exists ("Simulate test purchases before going live") and separately describe real-time authorization webhooks and spending-control declines, which together imply some lifecycle testing capability. However, no evidence explicitly documents simulating clearings, reversals, or refunds in the test environment, only authorizations/purchases and controls-based declines. Missing for 10: explicit documentation/tooling for simulating clearing, reversal, and refund events in sandbox, and any independent/hands-on confirmation that the full lifecycle can be tested end-to-end.
- [claimed-docs] “Test the integration: Simulate test purchases before going live.”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 drawnStripe Issuingnone0/10Stripe 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. While an API-driven product could plausibly support bulk automation, the evidence pack contains nothing about batch operations, bulk imports, or multi-item API calls.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnStripe Issuing supports rule-like automation via spending controls (block by MCC, country, merchant ID, card presence, spending limits) and synchronous webhooks that programmatically approve/decline authorizations in real time, which is a form of event-triggered automated action. However, this is scoped narrowly to authorization events rather than a general-purpose rule engine for arbitrary triggers/actions across the product. Missing for 10: evidence of a broader declarative rules/automation framework beyond authorization controls, and independent/hands-on validation of custom rule logic in production.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
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 IssuingDocs confirm card creation, cardholder creation, and replacement of lost/stolen/expired/damaged cards via API (docs-1, docs-3, docs-7), which covers reissue-with-replacement-link and lost/stolen reporting in spirit, but the evidence pack never explicitly documents API calls for activating, pausing/unpausing a card's status, or permanently closing a card. missing for 10: explicit API docs for activate/pause/unpause status transitions, explicit 'permanently close' endpoint, and confirmation that the replacement card is API-linked to the original card object.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
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 Stripe IssuingDocs confirm API-driven physical card issuance with custom card art/logo (docs-1, docs-2, docs-8) and Stripe handles printing/shipping without an ops-managed manufacturer relationship, plus replacement cards for lost/damaged/stolen (docs-7). However, there is no explicit evidence of bulk ordering workflows, choice of shipping methods, or shipment tracking details in the API. Missing for 10: bulk order API/batch issuance evidence, shipping method selection, and tracking number/status documentation.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “A physical card will be printed and shipped. It can be used at physical terminals.”
- [claimed-docs] “Configure the appearance of your physical cards, such as by adding a company logo, and customize the accompanying content.”
- [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
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 Stripe IssuingDocs confirm a single API call creates an Issuing Card object and that sandbox-mode purchase simulation exists before going live, supporting the core lifecycle claim. However, the evidence pack never explicitly confirms that PAN, CVV, and expiry are returned/retrievable programmatically at issuance, nor does it document that moving from test to live mode requires no approval or sales process (Issuing often needs business verification). missing for 10: explicit API field/endpoint returning PAN+CVV+expiry, documentation of frictionless sandbox-to-live activation without account review.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Test the integration: Simulate test purchases before going live.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 Stripe IssuingStripe documents a dedicated agents.md page describing virtual cards scoped to a single task/session that auto-invalidate after use, combined with spending controls (merchant category/ID/country locks, per-authorization/monthly amount caps) and real-time authorization webhooks, directly matching the story's named use case. missing for 10: independent/hands-on third-party corroboration of the agent-specific card flow (only vendor docs cited), and no explicit example of setting card expiry alongside merchant locks in a single documented workflow.
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Creates an Issuing `Card` object.”
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 Stripe IssuingStripe Issuing offers full API coverage for card/cardholder creation, spend controls, and an agents-specific doc describing task-scoped single-use virtual cards with ML risk scoring, plus a documented official MCP server. However, the evidence doesn't show the MCP server exposing Issuing-specific tools (balances, transactions, card/spend-control management) or confirm scoped/limited credentials for agent use via MCP rather than just full API keys. missing for 10: evidence of MCP server exposing Issuing read/write tools (balances, transactions, card updates, spend control adjustments), and evidence of scoped/restricted API keys for agent use.
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/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 drawnStripe Issuingnone0/10The evidence pack covers card creation, cardholder objects, spending controls, disputes, and agent-scoped virtual cards, but contains no documentation of KYC/KYB data requirements, cardholder verification review states, or re-verification workflows. Cardholder identity verification is a plausible and expected axis for a card-issuing platform, so absence of evidence yields 'none' rather than 'na'.
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
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 drawnStripe Issuingnone0/10The evidence pack covers card creation, controls, disputes, funding, and agent-scoped virtual cards, but contains no mention of PAN/CVV reveal UI, hosted Elements components, or ephemeral key issuance for reducing PCI SAQ D scope. Missing for 10: documentation of hosted card reveal components (e.g., Stripe Elements 'Issuing Elements'), ephemeral key generation for PAN/CVV display, and explicit PCI SAQ A/D scope-reduction claims.
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 drawnStripe confirms an API + Dashboard flow to submit and monitor Issuing disputes through resolution, but the evidence pack gives no detail on network reason codes, evidence submission fields, provisional credit handling, or dispute-specific status webhooks. Missing for 10: reason-code taxonomy documentation, evidence-submission API specifics, provisional credit mechanics, and dispute webhook event examples.
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
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 Stripe IssuingDocs show real-time authorization webhooks for approve/decline, ML-generated risk scores (fraud risk, merchant dispute risk, card testing detection) surfaced at authorization, spending controls to block merchant categories/countries, and replacement-card issuance for lost/stolen/damaged cards, plus a dispute workflow. However, there is no explicit documentation of a dedicated suspicious-activity alerting/notification system for ops, nor clear card-level 'freeze/block' tooling distinct from spending controls. missing for 10: explicit suspicious-activity alert mechanism, explicit card status/block (vs. reissue) API evidence, independent/hands-on corroboration of fraud-score accuracy.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
- [claimed-docs] “Get machine learning-generated risk scores on every authorization, including fraud risk, merchant dispute risk, and card testing detections.”
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 drawnDocs show real-time authorization webhooks, funding balance/bank details, and dispute handling, implying underlying ledger and clearing mechanics, but there is no explicit documentation of a transaction ledger that ties authorizations to clearing or of settlement reporting that reconciles to the penny. Missing for 10: dedicated ledger/transaction API description, settlement reporting/reconciliation tools, and evidence of penny-accurate reconciliation.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
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 drawnStripe Issuingnone0/10The evidence pack covers card creation, controls, disputes, funding, and agent-specific virtual cards, but contains no mention of settlement files, interchange/fee reporting, or reconciliation report APIs that a finance stack could consume. Missing for 10: any documentation of daily settlement/report files, interchange or fee breakdowns, or reconciliation API endpoints.
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 drawnDocs mention a synchronous webhook for real-time authorization decisions and a separate API/dashboard flow for disputes, implying some post-auth event handling, but the pack never documents webhook events for clearings, refunds, or reversals, nor stable transaction identifiers for ledger reconciliation. Missing for 10: explicit webhook events for captures/refunds/reversals, documentation of a Transaction object with stable IDs, and confirmation that disputes/chargebacks are delivered via webhook rather than only dashboard/API polling.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
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 to Stripe IssuingStripe Issuing is API-first: cards, cardholders, spending controls, disputes, funding, and even agent-specific ephemeral virtual cards are all documented as API operations, and community evidence confirms teams building entirely on the API. However, some dashboard-only conveniences (physical card design/appearance configuration, guided dispute UX, some Connect platform setup flows) are described primarily through the Dashboard with API as a secondary/parallel path, and there's no independent audit confirming 1:1 parity between UI and API surface area. missing for 10: independent verification of full UI/API parity, explicit API equivalents for all dashboard-guided workflows (e.g., card design/appearance, guided dispute UI), and a published OpenAPI spec (probe found only 404s).
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Issue cards to connected accounts: Learn how to issue cards as a Connect platform to third parties represented as connected accounts.”
- [community] “We would be entirely API used for QA automation. Looked through the docs and meets the same needs that Emburse meets.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.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 drawnStripe Issuingnone0/10No 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'.
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 drawnStripe Issuingnone0/10No evidence in the pack addresses data residency or region selection for Stripe Issuing data; nothing discusses where card/cardholder data is stored or regional data controls.
ai-native userControl data retention and deletion
weight 2 · round drawnStripe Issuingnone0/10The evidence pack covers card issuance, spending controls, disputes, and agent-scoped virtual cards, but contains no mention of data retention policies, data deletion APIs, or privacy controls for cardholder/transaction data. Card auto-invalidation (docs-12) is about card lifecycle, not data retention/deletion of stored information, so it doesn't satisfy this axis.
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 drawnStripe Issuingnone0/10The evidence pack covers card creation, controls, funding, and network partnerships but never specifies which underlying program types (debit, prepaid, commercial credit, consumer credit) Stripe Issuing supports — the only hint is a truncated snippet ('Commercial iss...') that provides no substantive detail. Missing for 10: explicit documentation distinguishing prepaid vs. debit vs. commercial credit vs. consumer credit program support, eligibility/underwriting differences, or customer examples confirming multiple program types in production.
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 drawnStripe Issuing documents a balance-based (prefunded) funding model where finance pushes funds from an external bank account (stripe-issuing-docs-9), and separately documents real-time authorization webhooks that let a system approve/decline each authorization synchronously, which is the core of just-in-time funding control (stripe-issuing-docs-4). However, the evidence never explicitly frames these as two alternative 'prefunded vs JIT' funding models nor discusses the cash-flow tradeoffs between them. Missing for 10: explicit documentation contrasting prefunded balance funding vs JIT funding as named options, and cash-flow tradeoff guidance for finance leads.
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
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 to Stripe IssuingDocs show Stripe handles cardholder/card creation, network partnerships (Mastercard/Visa), controls, funding, and disputes — all evidence that program management, network membership, and card issuance mechanics are Stripe's responsibility, not the founder's. However, there is no explicit documentation of BIN sponsorship terminology or a stated timeline from signup to first live card. Missing for 10: explicit 'no bank charter/BIN sponsorship' framing, and a documented signup-to-first-live-card timeframe or onboarding SLA.
- [claimed-docs] “Creates an Issuing `Card` object.”
- [claimed-docs] “Creates a new Issuing `Cardholder` object that can be issued cards.”
- [claimed-docs] “We also partner with the Mastercard and Visa card networks so you can issue cards on either network or on both.”
- [claimed-docs] “Using the Stripe Dashboard or API, you can access the bank account and routing information you need to push funds from your external bank ac…”
- [claimed-docs] “Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 Stripe IssuingDocs confirm platform-enforced spending controls (merchant category/country/MID/card-presence blocks) and spending limits, but only mention 'per authorization or per month' intervals — no explicit mention of daily or all-time windows, transaction-count velocity rules, or per-cardholder (vs per-card) limit distinctions. Real-time authorization webhook (docs-4) supports enforcement flow but isn't itself the velocity/amount-cap mechanism. missing for 10: daily/all-time window support, transaction-count velocity rules, explicit per-cardholder vs per-card scoping detail.
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
- [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/issuing.md # Issuing Use the Stripe Issuing API to create, manage, and distribute paymen…”
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 Stripe IssuingDocs confirm spending controls can block by merchant category (MCC) and merchant IDs (single-merchant lock) applied via authorization-time controls, and real-time webhook authorization confirms enforcement at auth time. However, the evidence does not explicitly confirm an 'allowlist' mode (only 'block' is described) nor detail how single-merchant locking works beyond blocking by merchant ID, leaving allowlist behavior unproven. missing for 10: explicit allowlist (allow-only) MCC configuration, explicit documentation of single-merchant lock as a distinct feature, independent/hands-on verification of authorization-time enforcement.
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
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 Stripe IssuingStripe Issuing supports single-use virtual cards scoped to a task/session that auto-invalidate after use, plus per-authorization spending controls (exact amount, merchant category, merchant ID, single presence) to tightly scope a card to one purchase/merchant. missing for 10: no independent/hands-on corroboration of single-use card behavior beyond docs, and no explicit example combining exact-amount + single-merchant lock in one workflow.
- [claimed-docs] “You can use spending controls to block merchant categories (for example, bakeries), countries, merchant IDs, or card presence, and to set sp…”
- [claimed-docs] “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.”
- [claimed-docs] “Using the synchronous webhook, you can approve or decline authorization requests in real time.”
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 IssuingStripe Issuingnone0/10The evidence pack covers card/cardholder creation, spending controls, wallets, disputes, and replacement cards, but contains no mention of PIN set/reset APIs or 3DS enrollment flows, which are a plausible and expected capability for a card-issuing API. Absence of evidence for this applicable axis means it cannot be credited.
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 drawnStripe Issuingnone0/10Evidence only shows that cards can be added to digital wallets (Apple Pay/Google Pay/Samsung Pay) but nothing about a distinct network-token object, listing which wallet/merchant holds a token, or revoking a token independently of the underlying PAN. Missing for 10: token object/API reference, wallet/merchant attribution per token, token-level revocation endpoint or dashboard control.
- [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”
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 to Stripe IssuingDocs confirm cards can be added to Apple Pay, Google Pay, and Samsung Pay and that physical card art/customization and replacement (manual provisioning fallback) exist, but there is no documentation of the push provisioning API/SDK flow, entitlements process, or in-app provisioning implementation details a developer would need. missing for 10: push provisioning API/SDK documentation, entitlements process details, in-wallet card art specification, independent/hands-on confirmation of the provisioning flow.
- [claimed-docs] “Add cards to digital wallets: Spend cards with Apple Pay, Google Pay, or Samsung Pay.”
- [claimed-docs] “Get replacement cards: Replace cards that are expired, damaged, lost, or stolen.”
- [claimed-docs] “Configure the appearance of your physical cards, such as by adding a company logo, and customize the accompanying content.”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableStripe Issuingn/aStripe Issuing is a card-issuing API/platform, not an agent runtime or assistant that itself consumes external MCP servers as a client; the evidence instead shows Stripe exposing its own MCP server so that AI agents can call Issuing's tools, which is the reverse (server) role and a separate story.
- [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
- [probe] “official MCP server documented at https://docs.stripe.com/mcp”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableStripe Issuingn/aStripe Issuing is a card-issuing API/platform, not an AI agent product with a built-in assistant UI to delegate tasks to; it does offer an MCP server for external agents to call it, but that's a different axis (agent enablement, not an in-product assistant). No evidence of a built-in AI assistant that users delegate tasks to within Stripe Issuing itself.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableStripe Issuingnone0/10The 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.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableStripe Issuingn/aStripe Issuing is a card-issuing API, not an automation/workflow-building tool; versioning, reviewing, and rolling back 'automations' is not a concept this product category addresses (it has no automation/workflow builder to version or roll back).
ai-native userRead the product's source under an open license
weight 2 · not comparableStripe Issuingn/aStripe Issuing is a closed proprietary SaaS/API product for card issuing, not open-source software; there is no source code to read under any license. This axis applies to open-source projects, not to a commercial financial API service — category error.
ai-native userSelf-host the core product
weight 3 · not comparableStripe Issuingn/aStripe Issuing is a regulated financial/card-issuing SaaS platform tied to banking partners and card networks; self-hosting the core product is a category error, not an applicable capability.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableStripe Issuingn/aStripe Issuing is a card-issuing/payments API product, not an AI model or AI training data pipeline; controlling whether user data trains AI models is a category error for this axis.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableStripe Issuingn/aStripe Issuing is a card-issuing API/platform, not an AI agent or developer tool with client-side telemetry to opt out of; telemetry opt-out is not a relevant axis for this product category.