Marqeta vs Adyen Issuing
Marqeta
Marqeta, Inc.
Marqeta wins · 19–6 (21 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 to Adyen IssuingMarqeta's docs are available in machine-readable .md format per-page (e.g., cards.md, introduction.md), which is agent-friendly, but there is no llms.txt index file and probes for llms.txt and a consolidated docs.md both return 404. Missing for 10: a dedicated llms.txt manifest, a single agent-oriented entry point, and confirmation that individual .md pages are discoverable/crawlable without prior knowledge of URLs.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”
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 drawnMarqeta's Core API is a REST API with a sandbox environment for programmatic testing/simulation (card products, users, transactions), which is inherently usable headlessly via scripts or CI pipelines. However, there is no explicit documentation of CI/CD integration, SDKs for automated testing, or a CLI—automation must be inferred from generic REST API access. Missing for 10: explicit CI/CD guides or examples, official SDK/CLI for automation, and evidence of headless usage patterns beyond sandbox simulation endpoints.
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
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 MarqetaMarqeta documents an official MCP Server that AI agents can use to query Core API endpoints, issue virtual cards, and set spend controls, confirmed by both docs and a probe verifying the page exists. Missing for 10: independent/hands-on corroboration of setup and real-world agent integration beyond first-party docs.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
ai-native userUse an official CLI
weight 2 · round drawnMarqetanone0/10Marqeta is a card issuing platform; an official CLI is a plausible developer-tooling axis, but evidence only shows a Core API, sandbox, interactive doc widgets, and an MCP server — no mention of a CLI tool anywhere. missing for 10: any evidence of an official CLI, CLI documentation, or CLI installation instructions.
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
ai-native userDrive the product through a documented public API
weight 3 · round to MarqetaMarqeta publishes extensive Core API documentation covering cards, users, transactions, controls, webhooks, disputes, and a full interactive sandbox with browser-based widgets for testing endpoints directly, clearly enabling an AI-native developer to drive the product programmatically. Missing for 10: a discoverable machine-readable OpenAPI/llms.txt spec (probes show 404s at standard paths), which would make API discovery more agent-friendly.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
Multiple documented REST-style API endpoints (paymentInstruments, balanceAccounts, authorization webhooks, disputes API) confirm Adyen Issuing is API-driven and well documented, with llms.txt indicating AI-friendly doc structure. However, no discoverable OpenAPI/Swagger spec was found (all candidate paths 404'd), which weakens machine-readability for AI-native tooling. missing for 10: publicly discoverable OpenAPI/Swagger spec, explicit SDK/agent-friendly API reference, independent corroboration of API usability by third parties.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to MarqetaMarqeta's MCP server is described as letting agents query only 'a designated set of Marqeta's Core API endpoints,' implying some endpoint-level scoping for agent access, and spend/velocity controls could theoretically constrain an agent-issued card's usage. However, there is no explicit documentation of issuing scoped or least-privilege API credentials (e.g., API keys/OAuth tokens with configurable permission scopes) specifically for an AI agent. Missing for 10: explicit scoped-credential/API-key issuance mechanism, permission granularity documentation, and independent confirmation of least-privilege enforcement for agents.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
ai-native userBuild against official SDKs
weight 2 · round drawnMarqetanone0/10The evidence pack documents Marqeta's Core API, sandbox, webhooks, and an MCP server, but contains no mention of official client SDKs (e.g., Python, Java, Node libraries) that AI-native developers could build against. Probes for openapi.json/docs.md/llms.txt all returned 404, further indicating no discoverable machine-readable SDK artifacts.
- [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
Adyen Issuingnone0/10The evidence pack covers Adyen Issuing's API capabilities (cards, authorization, disputes, webhooks) but contains no mention of official client SDKs in any language, nor any SDK repository links; probes for OpenAPI specs also failed (404). Missing for 10: any reference to official SDKs, language coverage, or SDK documentation/repos.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userSubscribe to events via webhooks
weight 2 · round to MarqetaMarqeta's docs explicitly describe webhooks as notifications about API events sent as they occur, providing a documented subscription mechanism for real-time events. Missing for 10: no independent/hands-on corroboration or detail on webhook configuration/management API specifics beyond the single doc reference.
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
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 drawnMarqetanone0/10Marqeta offers an MCP server for agents to query API data and act on it (card issuance, spend controls), but there is no evidence of AI-generated insights, analytics, or suggestions surfaced to users inside the product itself — it's raw data querying, not insight generation. Missing for 10: any dashboard, report, or in-product AI feature that analyzes user data and proactively surfaces insights/recommendations.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
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 drawnMarqeta provides infrastructure that supports autonomous background operation — webhooks fire automatically on events, JIT funding lets a system auto-approve/deny in real time using business rules, and an MCP server lets AI agents query Core API data and act on it (issue cards, set spend controls) without human intervention. However, there is no documented 'automation builder', scheduler, or explicit background-job orchestration feature — the autonomy comes from combining APIs/webhooks/MCP yourself. Missing for 10: a dedicated automation/workflow engine, scheduling capability, and evidence of persistent unattended agent runs beyond query/action tooling.
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
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 MarqetaMarqeta ships an official MCP Server that lets external AI agents query Core API data, issue virtual cards, and set spend controls, which indirectly enables natural-language operation via a connected agent — but this requires the user's own AI agent tooling rather than a built-in NL interface, and there's no evidence of a native chat/NL command surface in the product itself. missing for 10: evidence of a first-party natural-language interface/chat UI, independent/hands-on confirmation of NL command usage via the MCP server, and broader coverage beyond the limited endpoint set mentioned.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to MarqetaMarqeta's docs explicitly state interactive widgets let developers explore and test the Core API directly from the browser, plus a sandbox environment and simulation endpoints support runnable, hands-on exploration. However, there's no evidence of a full interactive API reference (e.g., try-it-console with live request/response, OpenAPI-spec-based explorer) and probes show no discoverable OpenAPI/swagger spec, so the extent of interactivity is unclear. Missing for 10: confirmed OpenAPI/swagger-based reference, visible runnable code snippets per endpoint, independent corroboration of the widget experience.
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “Marqeta's developer documentation includes interactive widgets that you can use to explore and test the Core API directly from your browser.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.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 drawnMarqetanone0/10Direct probes for OpenAPI/Swagger specs and llms.txt/docs.md all returned 404, and no evidence pack item links to a downloadable machine-readable API spec despite extensive Core API docs; interactive widgets and MCP server access don't substitute for a downloadable spec file.
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 MarqetaMarqeta explicitly documents a sandbox environment for testing Core API without production data, including simulated card network transactions (authorizations, reversals, balance inquiries) and a quick-start tutorial showing how to create test objects and simulate transactions. This sandbox is also accessible via the official MCP server for agentic AI use cases. Missing for 10: independent/hands-on third-party confirmation of sandbox fidelity or limitations.
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
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 drawnMarqetanone0/10The evidence pack shows extensive Core API docs, sandbox, and an MCP server, but nothing documents API versioning scheme or a deprecation policy; probes for openapi/spec files also failed. Missing for 10: any mention of API versioning, version headers/URLs, or a documented deprecation/sunset policy.
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 to MarqetaEvidence confirms transaction retrieval by merchant/card/account holder and authorization/velocity controls, but no explicit documentation of MCC codes, enhanced merchant data, wallet/entry-mode fields, or partial-approval and incremental-auth signals in the authorization payload. missing for 10: MCC field detail, enhanced merchant data enrichment, wallet/entry-mode metadata, partial-approval and incremental-auth signal documentation.
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
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 IssuingMarqeta's JIT Funding gateway lets a developer's own system approve or decline funding/authorization requests in real time using custom business rules, which is the core of this story, but the evidence never documents the network's response-time budget or a configurable timeout/fallback behavior the developer controls. Webhooks (docs-9) are described only as async event notifications, not the real-time decisioning channel, so they don't fully substantiate the 'auth-stream endpoint' framing either. Missing for 10: documented timeout window/SLA for JIT funding responses, explicit fallback/default-decision configuration, and clarity on webhook vs. JIT funding as the real-time decision channel.
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
Adyen documents relayed authorization webhooks sent to the developer's own servers with an explicit 2000ms reply budget to approve/decline, plus transaction rules as an automatic fallback/complement to real-time decisioning. Missing for 10: explicit documentation of what happens on timeout (default accept/decline behavior) and independent/hands-on corroboration beyond Adyen's own docs.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Simulation
developerSimulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes
weight 2 · round to MarqetaDocs confirm a sandbox with endpoints to simulate authorizations, reversals, and balance inquiries, plus a quick-start tutorial covering card/user/product creation and transaction simulation, and separate endpoints for transactions and disputes. However, explicit simulation coverage for clearings, refunds, and declines is not documented, and no independent/hands-on corroboration is provided. missing for 10: explicit simulation of clearings, refunds, and declines; independent developer confirmation of full lifecycle simulation.
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
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 drawnMarqetanone0/10Evidence shows single-resource CRUD endpoints (create one card, one dispute, one user) and an MCP server for querying/creating individual cards, but nothing about batch/bulk endpoints or operations across many items at once. Missing for 10: bulk create/update APIs, batch job endpoints, any documentation of multi-item operations.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnMarqeta supports event-driven automation in the payments domain: velocity/authorization controls automatically restrict spend based on transaction events, JIT funding lets your system approve/deny in real time, and webhooks notify external systems as API events occur. This is rule-triggered action, but it's domain-specific (spend limits, approvals) rather than a general-purpose rule/workflow engine for arbitrary triggers and actions. Missing for 10: a broader configurable rule/automation builder beyond spend controls, and independent evidence of custom event-to-action workflows.
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
Adyen Issuing supports rule-based automation via transaction rules that automatically approve/decline authorizations and relayed authorization webhooks that let servers respond within 2000ms based on custom logic, which qualifies as event-triggered automation. However, this is transaction/authorization-scoped rather than a general-purpose 'define rules for any event' engine, and there's no evidence of a broader rules/workflow builder covering arbitrary events beyond card authorizations and disputes. Missing for 10: evidence of a general event-driven rules engine spanning all Issuing events (not just authorizations), and any AI-native tooling or examples for constructing such rules programmatically.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Card lifecycle — stories about card lifecycle in this arenaCard lifecycle
Stories about card lifecycle in this arena
Lifecycle states
developerThe full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
weight 2 · round to Adyen IssuingEvidence confirms card creation via Core API and sandbox simulation of transactions, plus velocity/authorization controls, but none of the citations explicitly document activate, pause/unpause, report lost/stolen, reissue-linked-to-original, or permanent close endpoints. Missing for 10: explicit docs on card state-transition endpoints (activate/suspend/unsuspend), lost/stolen reporting, reissue linkage, and card termination/closure.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
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 Adyen IssuingMarqetanone0/10Evidence only covers virtual/instant card issuance, sandbox testing, and general card creation via the Core API — there is no mention of physical card manufacturing, custom card art, bulk ordering, shipping methods, or tracking integration. Missing for 10: physical card fulfillment API docs, custom art/design options, bulk order endpoints, carrier/shipping and tracking integration.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
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 MarqetaDocs confirm one-call card creation via API (marqeta-docs-1), a sandbox environment for testing (marqeta-docs-2, marqeta-docs-14), and instant-issue virtual cards ready for immediate use (marqeta-docs-12, marqeta-docs-16). However, there is no explicit evidence that PAN/CVV/expiry are all returned synchronously in the creation response, nor any documentation of a self-serve path from sandbox to live/production credentials without a sales engagement. missing for 10: explicit confirmation that PAN, CVV, and expiry are returned in the create-card API response, and evidence of self-service sandbox-to-production activation without a sales cycle.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “The Marqeta platform provides a sandbox environment where you can explore the capabilities of the Core API.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [claimed-docs] “Issue virtual cards”
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 MarqetaMarqeta explicitly documents an AI-agent-focused MCP server that supports instant-issue virtual cards, spend caps/velocity limits, and merchant restrictions, directly naming the agent use case (marqeta-docs-11,12,13), backed by general card issuance, merchant lock, and velocity control APIs (marqeta-docs-1,5,6). Missing for 10: independent/hands-on corroboration of an agent actually using scoped cards in production, and explicit documentation of expiry controls specifically tied to agent cards.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
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 MarqetaMarqeta documents an official MCP server for agentic AI that lets agents query Core API data (docs-11) and lists virtual card issuance and spend-control features on that same page (docs-12, docs-13), alongside full Core API support for reading balances/transactions (docs-7), creating/updating cards (docs-1), and setting velocity/merchant controls (docs-5, docs-6). However, the MCP server's own description emphasizes 'query data' rather than confirming write actions (create/update cards, adjust controls) run through the MCP surface itself, and there is no explicit mention of scoped-credential mechanics for the MCP server. Missing for 10: explicit confirmation that create/update-card and spend-control actions (not just queries) are exposed via the MCP server, and documentation of scoped/least-privilege credentials for MCP access.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
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 drawnMarqetanone0/10Evidence covers card issuance, velocity/authorization controls, transactions, disputes, and simulations, but nothing in the pack documents KYC for consumers or KYB for businesses, associated data requirements, review states, or re-verification flows. Missing for 10: KYC/KYB documentation, identity verification data requirements, review/approval states, and re-verification workflow evidence.
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 to MarqetaThe only relevant evidence is a bare marketing bullet naming 'PCI widgets' with no elaboration on how they reduce PCI scope, SAQ D applicability, or ephemeral-key reveal mechanics. Missing for 10: documentation of the hosted PAN/CVV reveal component's implementation, explicit PCI SAQ D scope-reduction claims, and independent/hands-on confirmation that integrators avoid full PCI scope.
- [claimed-docs] “PCI widgets”
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 to MarqetaMarqeta docs confirm a dedicated dispute-case API (disputes-mastercard.md) for creating cases with network/type-specific details, and a general webhooks system exists for API event notifications, plus transaction retrieval endpoints. However, the evidence pack never documents evidence-submission endpoints, provisional credit handling, or dispute-specific status webhooks through resolution. Missing for 10: evidence submission workflow, provisional credit issuance/reversal mechanics, dispute-status webhook events, and multi-network (Visa) reason code coverage beyond Mastercard.
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
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 Adyen IssuingMarqeta docs show velocity/authorization spend controls (docs-5, docs-6), transaction retrieval (docs-7), webhooks for event notifications (docs-9), and a disputes API for handling compromised-card claims (docs-8) — these provide some fraud-adjacent tooling. However, there is no evidence of network fraud scores or Marqeta's own fraud-risk models surfaced at authorization time, no dedicated suspicious-activity/fraud alerting feature, and no explicit card-block-and-reissue workflow described. Missing for 10: fraud score/model surfaced at auth, suspicious-activity alerting, explicit block-and-reissue tooling for compromised cards.
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
Adyen Issuing lets ops build transaction rules and relayed authorization logic to approve/decline in real time, and provides card suspend/close controls plus a Raise Disputes API for cardholders to report fraud or lost cards — covering blocking and dispute workflows. However there is no evidence of network fraud scores or Adyen's own risk models surfaced at auth time, no mention of suspicious-activity alerting, and no explicit card-reissue tooling (only activate/suspend/close). missing for 10: fraud-score/model signals at authorization, proactive suspicious-activity alerts, dedicated reissue flow for compromised cards.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
Ledger settlement — stories about ledger settlement in this arenaLedger settlement
Stories about ledger settlement in this arena
Balances
finance leadSee money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny
weight 3 · round to MarqetaMarqeta provides transaction retrieval endpoints (docs-7), dispute case creation (docs-8), webhooks for real-time event notification (docs-9), and JIT funding approval flows tied to authorizations (docs-4), which together give partial visibility into authorization-to-clearing flows. However, there is no evidence of a dedicated settlement reporting module, penny-accurate reconciliation reports, or a finance-lead-facing balance/ledger dashboard. Missing for 10: settlement reporting/reconciliation documentation, account/card balance reporting UI, ledger reconciliation guarantees, and independent verification of accuracy.
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
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 drawnMarqetanone0/10Evidence covers transactions API, disputes, webhooks, and sandbox simulations, but nothing addresses settlement/reconciliation files, interchange/fee reporting, or network adjustment reporting APIs that a finance stack could consume. No mention of settlement or reconciliation artifacts anywhere in the docs pack.
Adyen Issuingnone0/10The evidence pack covers card issuance, authorization webhooks, disputes, and balance accounts, but contains no mention of daily settlement files, report APIs, or interchange/fee/network adjustment reconciliation artifacts. No documentation references machine-readable reconciliation exports for finance systems.
Settlement events
developerPost-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts
weight 2 · round to MarqetaMarqeta documents webhooks for API events generally and has explicit endpoints/objects for transactions and disputes (chargebacks), plus transaction retrieval by card/merchant/account holder, suggesting stable identifiers exist across the transaction lifecycle. However, evidence does not explicitly confirm that clearings, refunds, reversals, and chargebacks each fire dedicated webhook events with stable transaction IDs tying back to the original auth — the webhook doc is generic and disputes are described as case creation rather than webhook-driven updates. Missing for 10: explicit webhook event types/payloads for clearings, refunds, reversals, and chargebacks, and confirmation of stable transaction ID linkage across these events.
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “The sandbox environments provide a set of endpoints that let you simulate various types of card network transactions, such as authorizations…”
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 drawnMarqeta is API-first: docs show broad Core API coverage (cards, users, controls, transactions, disputes, webhooks, simulations) suggesting most operations available programmatically, and dashboards reference features like 'PCI widgets' and 'dynamic spend controls' that map to documented API endpoints. However, there's no explicit mapping or claim confirming full UI-API parity, and openapi/spec discovery probes failed (404s), making it hard to verify completeness. Missing for 10: an explicit parity statement or comprehensive OpenAPI spec confirming every UI action has an API equivalent, and independent confirmation of no UI-only features.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “Dynamic spend controls”
- [claimed-docs] “Issue virtual cards”
- [claimed-docs] “PCI widgets”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.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 drawnMarqetanone0/10Marqeta is a card-issuing API platform; there's no evidence of any bulk data export/portability feature in open formats, and probes for llms.txt, docs.md, and openapi specs all returned 404. The evidence only covers API endpoints for retrieving transactions individually, not a data export/leave capability.
- [probe] “PROBE llms.txt: HTTP 404 at https://www.marqeta.com/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://www.marqeta.com/docs.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.marqeta.com/openapi.json, https://www.marqeta.com/swagger.json, https://www.marqeta.com/…”
- [claimed-docs] “You can also retrieve transactions associated with specific cards, merchants, and account holders using the endpoints described here.”
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 drawnMarqetanone0/10No evidence in the pack mentions data residency, regional storage options, or geographic data controls for Marqeta's platform or API; the docs focus on card issuance, controls, and MCP server features. Missing for 10: any mention of data region selection, residency guarantees, or storage location configuration.
ai-native userControl data retention and deletion
weight 2 · round drawnMarqetanone0/10No evidence pack items address data retention policies, deletion controls, or privacy/data lifecycle management for AI agent interactions or API data; documentation covers card issuance, controls, transactions, disputes, and MCP server capabilities but nothing on retention/deletion.
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.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnMarqetanone0/10No evidence pack content addresses telemetry, usage tracking, or opt-out/privacy controls for AI-native usage; Marqeta's docs focus on card issuance, controls, and its MCP server but say nothing about data collection opt-out.
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 drawnMarqetanone0/10The evidence pack shows generic 'card product' creation, sandbox simulation, and general statements about 'creating new payment products' but never names or documents specific program types (debit, prepaid, commercial credit, consumer credit) that Marqeta supports. Without explicit documentation distinguishing these card/program types, there's no evidence the platform is positioned beyond a generic card-issuing API.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
- [claimed-docs] “Use open APIs to create new payment products or streamline supplier and workforce payments.”
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 drawnJIT funding is clearly documented — the merchant's own system approves/denies funding requests per authorization (marqeta-docs-4) — but the evidence pack contains no explicit documentation of a prefunded-balance funding option or any comparison of cash-flow tradeoffs between the two models. Missing for 10: explicit prefunded balance funding docs, side-by-side cash-flow tradeoff guidance, finance-lead-oriented configuration guidance for choosing between models.
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
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 drawnDocs show Marqeta's Core API letting a founder create card products, users, cards, spend/velocity controls, disputes, and webhooks via a sandbox quick-start (marqeta-docs-1,5,6,8,9,14), implying program management is handled by the platform. However, there is no explicit mention of BIN sponsorship or network membership arrangements, and no documented signup-to-first-live-card timeline metric anywhere in the pack. Missing for 10: explicit BIN sponsorship/bank-partner language, network membership details, and a concrete time-to-live-card benchmark.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Create a new dispute case by specifying the type and including the type-specific details object.”
- [claimed-docs] “Webhooks are notifications about API events, sent as they occur.”
- [claimed-docs] “Use this tutorial to learn how to: Access the sandbox. Create the objects you use in sandbox transactions: a card product, a user, and a car…”
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 MarqetaMarqeta's velocity controls docs explicitly describe platform-enforced amount and count limits per user/card over configurable time windows, with multiple controls stacking (user cannot exceed any defined limit), plus authorization controls for merchant restrictions — all enforced server-side rather than in client code. missing for 10: no independent/hands-on corroboration of exact daily/monthly/all-time window options or precise velocity rule syntax beyond doc summaries.
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
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 MarqetaMarqeta's authorization-controls docs explicitly support limiting transactions to a single merchant or group of merchants (single-merchant lock), and merchant restrictions are called out as a spend-control feature alongside velocity limits; these controls apply at authorization time per the Core API design. Missing for 10: explicit documentation of MCC allowlist vs blocklist semantics and independent/hands-on confirmation beyond first-party docs.
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
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 MarqetaMarqeta's Core API documents virtual card issuance, merchant-restriction controls, velocity/spend-limit controls, and JIT funding that lets the issuer approve/deny each transaction against custom rules — together these let a developer create a card scoped to one merchant and exact amount, and JIT funding means an unused/leaked number can be denied. Missing for 10: explicit 'single-use card' terminology/flag in docs and independent/hands-on confirmation that a card auto-invalidates after one authorization.
- [claimed-docs] “Creates a card. Create the user and card product before you create the card.”
- [claimed-docs] “Your system receives funding requests and approves or denies them using your own business rules.”
- [claimed-docs] “Limits how much and how frequently a user can spend funds. If multiple velocity controls apply to the same user, the user cannot exceed any …”
- [claimed-docs] “Limit where a user can make transactions to a single merchant or group of merchants.”
- [claimed-docs] “Virtual card issuance: Create instant-issue virtual cards that are ready for immediate use.”
- [claimed-docs] “Spend controls: Set customizable velocity limits, spending caps, and merchant restrictions.”
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 IssuingMarqetanone0/10The evidence pack lists card, transaction, dispute, and control APIs but never mentions PIN set/reset endpoints or 3DS enrollment flows; the only tangential hint is a vague 'PCI widgets' bullet with no detail on PIN or 3DS functionality. Missing for 10: PIN set/reset API documentation, 3DS enrollment endpoint or workflow description, any explicit mention of cardholder credential self-service via API.
- [claimed-docs] “PCI widgets”
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 drawnMarqetanone0/10The evidence pack covers card creation, velocity/authorization controls, transactions, disputes, webhooks, and simulations, but nowhere mentions network tokens, token-to-wallet/merchant association, token visibility, or independent token revocation separate from the PAN — this is a distinct tokenization capability not evidenced here.
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 drawnMarqetanone0/10No evidence in the pack addresses push provisioning into Apple Pay/Google Pay, wallet entitlements processes, in-wallet card art, or manual provisioning fallback; the docs cover card creation, velocity controls, transactions, disputes, webhooks, and simulations but never wallet tokenization.
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableMarqetan/aMarqeta is a card-issuing/payments API platform, not an AI agent or assistant application that hosts/consumes external tools. Its only MCP-related capability is the reverse: exposing its own Core API as an MCP server for other agents to call (marqeta-docs-11, marqeta-probe-4), not accepting MCP servers as plug-ins itself. This axis (product acting as MCP client/host) is a category error for this type of product.
- [claimed-docs] “Use the Marqeta MCP Server with your own AI agents to query data from a designated set of Marqeta's Core API endpoints.”
- [probe] “official MCP server documented at https://www.marqeta.com/docs/developer-guides/agentic-ai-mcp-server”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableMarqetan/aMarqeta is a card issuing/payments API platform, not a product with a built-in AI assistant UI; it exposes an MCP server for external agents to consume, but that is agents connecting to it, not an internal assistant delegating tasks within Marqeta itself.
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableMarqetan/aMarqeta is a card-issuing/payments API platform, not a workflow/job orchestration tool; scheduling recurring jobs or workflows is outside its product category (wrong axis).
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableMarqetanone0/10Marqeta is a card-issuing API platform; there is no evidence of any versioning, review, or rollback mechanism for automations/configurations (e.g., no audit trail, no version history UI, no rollback API). This is a plausible axis for an automation-capable platform, but nothing in the evidence pack supports it.
ai-native userRead the product's source under an open license
weight 2 · not comparableMarqetan/aMarqeta is a closed commercial card-issuing platform/API service, not open-source software; source code availability under an open license is not a relevant axis for this kind of product.
ai-native userSelf-host the core product
weight 3 · not comparableMarqetan/aMarqeta is a card-issuing/payments SaaS platform with proprietary financial infrastructure; self-hosting is a category error for this kind of regulated, hosted payments processor, not an applicable openness axis.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableMarqetan/aMarqeta is a card-issuing/payments API platform, not a consumer-facing AI model or data-processing service where 'training data opt-out' is a meaningful control; this privacy-posture axis doesn't apply to its product category.