Marqeta vs Highnote
Marqeta
Marqeta, Inc.
Highnote wins · 10–14 (18 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 HighnoteMarqeta'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”
Direct probe confirms a live llms.txt at docs.highnote.com/llms.txt returning HTTP 200 with structured documentation content, and Highnote also publishes an agent-oriented markdown doc (agentic-commerce.md) explicitly designed for agent consumption. Missing for 10: no independent third-party report of an agent successfully using llms.txt to complete a task.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to HighnoteMarqeta'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…”
Highnote is an API/GraphQL-first platform with a Node.js SDK, webhooks, and a full-featured Test environment that mirrors Live functionality, all of which support running interactions programmatically without a UI (e.g., in CI or automated pipelines). However, there is no explicit documentation of a CLI, CI pipeline integration, or headless automation guidance beyond the general API/SDK access. Missing for 10: explicit CI/CD integration guides, a documented CLI or headless mode, and independent confirmation of automated pipeline usage.
- [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
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”
Highnotenone0/10Highnote is a card-issuance/payments platform, not an agent itself, so the MCP-server axis applies, but no evidence in the pack mentions an MCP server, MCP protocol, or agent-connection endpoint of any kind — only GraphQL API, SDKs, and webhooks are documented.
- [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
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 drawnMarqeta 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/…”
Highnote exposes a documented GraphQL API (with interactive code explorer), an official Node.js SDK wrapping it, webhooks, and a test environment mirroring live functionality, all of which let an AI-native user drive the product programmatically end-to-end including agentic card issuance workflows. missing for 10: a public OpenAPI/swagger spec (probe found 404s on standard OpenAPI paths) and independent third-party corroboration of API usability beyond vendor docs.
- [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
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”
Highnotenone0/10Highnote's evidence covers issuing scoped payment cards per agent with spend/velocity controls, but this is a financial-transaction spend-control mechanism, not API credential scoping (e.g., API keys/tokens with least-privilege permissions for programmatic access). There is no mention of scoped API keys, OAuth tokens, or role-based API credentials for agents to call Highnote's own API. missing for 10: evidence of scoped/least-privilege API credential or token issuance for agents accessing the Highnote API itself, permission/role management for API keys, documentation of API-level access control distinct from card spend controls.
ai-native userBuild against official SDKs
weight 2 · round to HighnoteMarqetanone0/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…”
Highnote documents an official Node.js SDK (currently in beta) plus PCI-compliant client SDKs for embedding sensitive card data and checkout flows, indicating a real official-SDK path beyond raw GraphQL. However, the core API remains GraphQL-first and the flagship SDK is explicitly beta, with no evidence of SDKs in other major languages, no independent/community corroboration of SDK quality, and OpenAPI spec probes returned 404s. missing for 10: multi-language SDK coverage, GA (non-beta) status, independent developer corroboration, and a public OpenAPI/type-generation artifact.
- [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
- [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
- [claimed-docs] “Accept payment card details in a configured checkout experience”
- [claimed-docs] “Collect identity verification documents from account holders when a card product application enters manual review”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnMarqeta'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.”
Highnote docs explicitly describe configurable webhook notification targets, choosing which events are delivered to each webhook, and signing key rotation for verifying payloads, plus general mention of 'real-time webhooks' as a core dev feature. This directly matches the story of subscribing to events via webhooks. Missing for 10: no independent/hands-on corroboration of webhook reliability or a full event-type catalog, and no explicit mention of AI-agent-specific webhook use cases.
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
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.”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to HighnoteMarqeta 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”
Highnote's agentic-commerce docs describe automations that run without human intervention — per-agent card issuance that auto-closes when a workflow ends, spend rules and velocity controls evaluated automatically at authorization, and webhooks for event-driven notifications — which functions as background autonomous automation for payment operations. However this is scoped narrowly to card/spend automation rather than a general-purpose automation/scheduling engine for AI agents, and there's no evidence of a broader trigger/scheduler system or independent corroboration of these claims. Missing for 10: general-purpose scheduled/triggered automation beyond payments, independent/hands-on validation of autonomous behavior.
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
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”
Highnotenone0/10Highnote's evidence describes a GraphQL API, SDKs, and dashboard for card issuance/payments, with no mention of a natural-language command interface, chatbot, or conversational control layer for operating the platform. While the docs discuss enabling AI agents to *use* cards programmatically, there is no evidence that a human or agent can *operate Highnote itself* via natural-language commands.
- [claimed-docs] “the official `@highnote-oss/nodejs-sdk` (currently in beta) wraps the Highnote API in typed, resource-oriented methods — no GraphQL required…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.highnote.com/llms.txt # Highnote Documentation > Highnote is a card issuance, payment processing, …”
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/…”
Highnote docs mention an "interactive code explorer" as part of building with the GraphQL API, and testing environment lets you simulate real-time transactions, suggesting some runnable/interactive documentation exists. However, there's no direct evidence of a live, embedded interactive API reference (e.g., no OpenAPI spec found, probes for openapi.json all 404), and no independent confirmation of runnable examples in the docs. Missing for 10: concrete demonstration or screenshot of the interactive code explorer, confirmation that examples can be executed directly from docs, and independent/hands-on corroboration.
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
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.
Highnotenone0/10Highnote's API is GraphQL-based, and explicit probes for standard OpenAPI/swagger spec paths all returned 404, with no evidence of any downloadable machine-readable spec (OpenAPI, GraphQL SDL, or introspection export) offered elsewhere. missing for 10: a published OpenAPI/GraphQL schema file, a documented download/export endpoint, any mention of schema introspection support.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round drawnMarqeta 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.”
Highnote explicitly documents a Test environment that replicates full Live functionality, allowing simulation of real-time transactions and compliance scenarios without touching production/live data, and this is directly tied to API development workflows relevant to agentic/AI-native usage. Missing for 10: independent/hands-on corroboration of the sandbox's fidelity and details on how test data is isolated or reset.
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
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.
Highnotenone0/10No evidence pack item mentions API versioning scheme, version headers, or any documented deprecation policy; even the OpenAPI spec probe returned 404s. missing for 10: versioning scheme documentation, deprecation/sunset policy, changelog or migration guides.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
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 …”
Docs confirm authorization-time data such as MCC-based spend rules and real-time collaborative-authorization decisioning, implying some transaction context is passed to business logic, but there is no evidence of enhanced merchant data, wallet/entry-mode details, partial-approval, or incremental-auth signals being exposed. missing for 10: merchant name/enhanced merchant data fields, wallet and entry-mode details, partial-approval signals, incremental-auth signals.
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
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 HighnoteMarqeta'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.”
Highnote's Collaborative Authorization feature explicitly lets developers approve/decline transactions in real time via their own business logic, and webhooks/notification targets are documented with signing-key rotation for verification. However, the evidence pack lacks specifics on the exact time budget the network/webhook enforces, or a documented timeout fallback behavior developers can configure if their endpoint doesn't respond in time. missing for 10: documented response time budget/SLA for the collaborative authorization webhook, explicit fallback/timeout behavior (e.g. default approve/decline on timeout) that developers can configure, and independent/hands-on confirmation of real-time latency behavior.
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
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.”
Highnote documents a full-featured Test environment that 'replicates the full functionality of the Live environment' and lets developers 'simulate real-time transactions and compliance scenarios' [highnote-docs-11], plus API support for the full authorization→capture→refund lifecycle [highnote-docs-20] and real-time approve/decline logic via collaborative authorization [highnote-docs-7]. However, the pack never explicitly confirms simulation of clearings or reversals specifically, or a documented list of simulated transaction states/test cards for each lifecycle stage. Missing for 10: explicit documentation of clearing/reversal simulation, test-card/scenario catalog enumerating each transaction state, and independent developer confirmation of sandbox fidelity.
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
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 to HighnoteMarqetanone0/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.”
Highnote's docs show program-level rule application across all cards (docs-21) and per-agent card issuance/closure (docs-17), which imply some scale-level automation, but there is no explicit documentation of bulk/batch API operations (e.g., batch mutations, bulk export, multi-item update endpoints) that would let an AI-native user act on many items in one call. Missing for 10: explicit bulk/batch API endpoints or mutations, batch processing docs, and evidence of pagination/bulk query support for acting on many records at once.
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
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.”
Highnote supports rule-based automated actions on events via spend rules, velocity controls, and collaborative authorization that automatically permit/restrict transactions based on business logic, plus webhooks that deliver configurable events to trigger downstream actions. However, these are financial/authorization-specific rules (MCC, amount, velocity) rather than a general-purpose event-condition-action automation engine, and there's no evidence of user-defined arbitrary triggers/actions spanning non-payment events. Missing for 10: a general rules engine beyond payment authorization scenarios, evidence of custom trigger definitions outside spend/velocity/collaborative-auth constructs, and independent confirmation of automation reliability at scale.
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
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 drawnEvidence 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 cards can be created and 'managed' via API (highnote-docs-1) and that agentic-use cards 'close automatically' via API (highnote-docs-17), implying some lifecycle control, but there is no explicit documentation of activate, pause/unpause, report-lost-or-stolen, or reissue-with-linked-replacement mutations. missing for 10: explicit API mutations/docs for pause, unpause, lost/stolen reporting, and reissue linked to original card, and confirmation these are exposed as first-class API operations.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
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 HighnoteMarqetanone0/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 Highnote supports issuing physical (not just virtual) cards via API alongside virtual/tokenized cards, but no evidence details custom card art, bulk ordering, shipping method selection, or shipment tracking capabilities. missing for 10: custom card art/design upload, bulk order API, shipping method selection, tracking integration, evidence of not needing a separate card manufacturer relationship.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
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 virtual card issuance via GraphQL API and a full-featured test/sandbox environment (highnote-docs-4, highnote-docs-11), plus PCI-compliant SDKs for embedding sensitive card data (highnote-docs-14). However, issuance requires an account holder with an approved application first (highnote-docs-4), implying a multi-step onboarding rather than a single API call, and there is no evidence of self-serve sandbox-to-live activation without a compliance/sales process (KYC/KYB is handled by an in-house team per highnote-docs-23). Missing for 10: explicit single-call PAN/CVV/expiry issuance example, and documented self-serve path from sandbox to live production without manual review/sales engagement.
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
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 drawnMarqeta 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”
Highnote explicitly documents issuing per-agent virtual cards with merchant category restrictions, velocity limits, and per-transaction caps enforced at authorization, plus auto-closing cards when a workflow ends, directly naming the agentic-commerce use case. Missing for 10: no explicit mention of a hard expiry field/date on agent cards (only workflow-end auto-closure) and no independent/hands-on corroboration of the feature working in production.
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
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”
Highnote's API/GraphQL surface clearly supports agent-driven card issuance, spend controls (velocity, MCC, per-transaction caps), balance/transaction ledger visibility, and even an agentic-commerce solution page describing per-agent card issuance and program-level rule enforcement. However, there is no evidence of an MCP server or MCP-scoped credential surface, and no explicit documentation of scoped API credentials/permissions specifically for agent use (e.g., agent-specific API keys with restricted scopes) — the OpenAPI spec itself is not discoverable (404s), suggesting limited machine-readable API surface for agent tooling. missing for 10: an official MCP server/integration, documented scoped-credential mechanism for agents, and a discoverable OpenAPI/schema for programmatic tool generation.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
Issuing compliance — stories about issuing compliance in this arenaIssuing compliance
Stories about issuing compliance in this arena
Kyc
ops userCardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows
weight 2 · round to HighnoteMarqetanone0/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.
Docs confirm in-house KYC/KYB compliance handling, account holder application approval flow, manual review state with identity document collection, and internal notes for servicing — covering the core of the story. However, there's no documented breakdown of specific data requirements per verification type, no explicit re-verification/periodic refresh flow, and review-state transitions beyond 'manual review' aren't detailed. Missing for 10: documented data requirements per KYC/KYB type, explicit re-verification/refresh flows, and full review-state lifecycle documentation.
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
- [claimed-docs] “Collect identity verification documents from account holders when a card product application enters manual review”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
- [claimed-docs] “you can use the following mutation to allow your agents to add notes to a financial account. Adding notes is useful for various internal ser…”
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 HighnoteThe 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”
Highnote documents SDKs specifically designed to embed sensitive card data (PAN/CVV) in a developer's UI while keeping raw PCI data out of their systems ("Embed sensitive card data in your UI and avoid PCI data from being compromised"), and its docs site markets "PCI-compliant SDKs" as a core offering. However, the evidence lacks explicit detail on ephemeral-key reveal mechanics, SAQ D scope reduction claims, or independent/hands-on confirmation that this actually keeps a developer out of SAQ D. Missing for 10: explicit SAQ-level scope claims, technical detail on the reveal flow (ephemeral keys, hosted iframe/component architecture), and third-party/compliance corroboration.
- [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
- [claimed-docs] “Accept payment card details in a configured checkout experience”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
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.”
Highnote documents a dedicated Disputes Team and processes for dispute/chargeback handling, and separately offers generic webhook notifications, but the evidence never confirms programmatic dispute filing via API, network reason codes, evidence submission endpoints, provisional credit handling, or dispute-specific status webhooks through resolution. Missing for 10: reason code taxonomy, evidence-submission API, provisional credit mechanics, dispute status webhook events, and any confirmation that filing/tracking is API-driven rather than handled manually by Highnote's in-house team.
- [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
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 HighnoteMarqeta 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.”
Highnote provides real-time authorization controls (collaborative authorization, spend rules, velocity controls) that could incorporate custom fraud logic, plus a Disputes Team for chargebacks and account notes for servicing, but evidence never mentions network fraud scores, in-house fraud models surfaced at auth, dedicated suspicious-activity alerts, or explicit card block/reissue tooling for compromised cards. Missing for 10: fraud-score/model evidence at authorization, suspicious-activity alerting, and documented card block-and-reissue workflow.
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
- [claimed-docs] “you can use the following mutation to allow your agents to add notes to a financial account. Adding notes is useful for various internal ser…”
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 HighnoteMarqeta 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 describe an integrated ledger that tracks balances and posts every transaction in real time (not batched), and the platform's in-house team handles daily reconciliation and settlement, which aligns with the finance-lead need for real-time money movement visibility. However, there is no explicit documentation of settlement reports reconciling to the penny, no detail on how authorizations tie to clearing entries in the ledger, and no independent/hands-on corroboration of reconciliation accuracy. Missing for 10: explicit settlement reporting docs/screenshots, authorization-to-clearing ledger linkage detail, and third-party verification of reconciliation accuracy.
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
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 to HighnoteMarqetanone0/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.
Highnote documents an integrated, transaction-level ledger and states its in-house teams handle 'daily reconciliation, settlement' plus real-time webhooks for events, suggesting some machine-consumable data exists. However, there is no explicit documentation of settlement files or report APIs that itemize interchange, fees, or network adjustments for finance-stack consumption. Missing for 10: dedicated reconciliation/settlement report API or file export, interchange/fee/network-adjustment breakdown fields, and confirmation the ledger data is structured for automated finance-system ingestion.
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
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 drawnMarqeta 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…”
Highnote's docs confirm a configurable webhook/events system (highnote-docs-12,13), a unified transaction-level ledger (highnote-docs-3,19), programmatic refund/capture across the payment lifecycle (highnote-docs-20), and a dedicated disputes/chargeback process (highnote-docs-10), which together support post-auth events flowing to a developer's own ledger. However, the evidence never explicitly enumerates clearing/reversal/chargeback as distinct webhook event types or confirms stable transaction identifiers tying these events together across the lifecycle. Missing for 10: explicit webhook event-type list showing clearings/reversals/chargebacks, and documentation of a stable transaction ID field used consistently across auth→settlement→dispute events.
- [claimed-docs] “You can configure specific events to be delivered to each webhook”
- [claimed-docs] “The signing key used to verify payloads is modifiable using the `rotateNotificationTargetSigningKey` mutation.”
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Every agentic transaction posts to a unified ledger the moment it occurs. Finance sees every dollar at the transaction level, not in an end-…”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
- [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
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/…”
Highnote is documented as an API-first platform (GraphQL API, typed SDKs, webhooks) with broad coverage of issuing, spend controls, ledger, disputes, and account management all exposed via API, and the Test environment is said to 'replicate the full functionality' of Live. However, there is no explicit statement that the dashboard/UI has 100% parity with the API (no confirmation that every dashboard action, e.g. dispute case management or manual reviews, is scriptable via API), and no OpenAPI/Swagger spec was discoverable via probe. Missing for 10: an explicit UI/API parity statement or documentation section, and a discoverable machine-readable API spec confirming full surface coverage.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
- [claimed-docs] “The Highnote Test environment (or dashboard) replicates the full functionality of the Live environment, and lets you simulate real-time tran…”
- [claimed-docs] “Build faster with GraphQL API, interactive code explorer, PCI-compliant SDKs, and real-time web hooks designed for modern development.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.highnote.com/openapi.json, https://docs.highnote.com/swagger.json, https://docs.highnot…”
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 to HighnoteMarqetanone0/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.”
Highnote's docs describe a general card-issuing platform (virtual/physical/tokenized cards, financial accounts, customizable card programs) and mention 'launch or migrate your card program,' implying support for multiple program types, but the evidence never explicitly names debit, prepaid, commercial credit, or consumer credit program types. Missing for 10: explicit documentation or product pages listing debit, prepaid, commercial credit, and consumer credit as distinct supported program types, and independent confirmation of multi-rail support.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
- [claimed-docs] “Launch or migrate your card program with speed and flexibility.”
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
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.”
Highnote documents collaborative authorization (real-time approve/decline of authorizations, i.e. JIT-style funding control) and an integrated ledger for tracking balances, plus prefunded-style financial accounts and Plaid-connected external bank accounts, implying both prefunded and JIT funding models exist. However, there is no explicit documentation contrasting 'prefunded balance' vs 'just-in-time funding' as named funding models, nor any discussion of the cash-flow tradeoffs between them. Missing for 10: explicit naming/documentation of prefunded vs JIT funding modes as a configurable choice, and any cash-flow tradeoff analysis or guidance comparing the two.
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Track money movement and balances with the integrated ledger.”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
- [claimed-docs] “Externally connected bank accounts via Plaid”
- [claimed-docs] “Authorize funds before an agent commits, capture only what is needed, and refund programmatically. The full payment lifecycle is available v…”
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 HighnoteDocs 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 Highnote absorbs core program-management burdens (in-house KYC/KYB compliance, transaction monitoring, reconciliation, settlement, disputes team) so a founder doesn't need banking infrastructure themselves, and marketing claims 'launch or migrate your card program with speed and flexibility.' However, there is no explicit mention of BIN sponsorship or card network membership being handled by Highnote, and no documented signup-to-first-live-card timeline or benchmark. Missing for 10: explicit BIN sponsor/network membership details, a concrete documented time-to-launch metric or case study.
- [claimed-docs] “Our in-house compliance and operations teams manage Know Your Customer (KYC) and Know Your Business (KYB) regulatory compliance, transaction…”
- [claimed-docs] “Highnote's in-house **Disputes Team** helps subscribers with the following dispute and chargeback-related processes”
- [claimed-docs] “Launch or migrate your card program with speed and flexibility.”
- [claimed-docs] “Once you have an account holder with an approved application, you can issue a financial account.”
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 drawnMarqeta'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.”
Docs explicitly describe spend rules (MCC, dollar amount, authorization count) and velocity controls (e.g., weekly spending limit example) that are configured and enforced platform-side at authorization time, plus per-card, per-account, and program-level scoping (docs-8, docs-9, docs-18, docs-21). This directly matches per-card/cardholder amount caps and transaction-count velocity rules enforced by Highnote rather than custom code. missing for 10: explicit documentation of all-time (lifetime) window caps distinct from daily/monthly/weekly, and independent/hands-on confirmation beyond vendor docs.
- [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
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 …”
Highnote's Spend Rules explicitly support MCC-based logic evaluated at authorization time, and rules can be scoped per card, account, or program (including single-card/single-merchant-like restriction via card-level rules). However, the evidence does not explicitly confirm an MCC allowlist/blocklist distinction or a dedicated 'single-merchant lock' feature—only general merchant category restriction and per-transaction/velocity caps. Missing for 10: explicit documentation of MCC allowlist vs blocklist configuration and a named single-merchant lock capability.
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
- [claimed-docs] “Collaborative authorization lets you approve or decline transactions in real time based on your business logic.”
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 drawnMarqeta'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.”
Highnote docs explicitly support issuing virtual cards with spend rules configurable by MCC, dollar amount, and authorization count, plus velocity controls (e.g., weekly $1,000 limits) and per-workflow cards that auto-close when a task ends — directly matching one-purchase/one-merchant/exact-amount scoping. Collaborative authorization further allows real-time accept/decline logic enforced before funds move. missing for 10: no explicit documentation of a strict 'single-use, exact amount, auto-expire after one transaction' card type or independent/hands-on confirmation that a single-use card is truly unusable after one authorization.
- [claimed-docs] “Control and optimize authorizations with spend rules and velocity controls.”
- [claimed-docs] “Spend rules let you automate logic on authorizations that permit or restrict transactions. You can configure that logic on merchant category…”
- [claimed-docs] “This creates a velocity control that enforces a weekly spending limit of $1,000.”
- [claimed-docs] “Issue cards per agent, workflow, or vendor via API. Each card closes automatically when the workflow ends. No manual provisioning.”
- [claimed-docs] “Set velocity limits, merchant category restrictions, and per-transaction caps at the card, account, or program level. Every rule is evaluate…”
- [claimed-docs] “Set rules once at the program level and they apply uniformly across every card. One policy layer, enforced at scale.”
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 drawnMarqetanone0/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”
Highnotenone0/10No evidence in the pack describes PIN set/reset APIs or 3DS enrollment flows; the closest items (SDKs for embedding sensitive card data, checkout details collection) do not mention PIN management or 3DS enrollment specifically. This is a fair axis for a card issuing platform, but the capability is unevidenced.
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.
Highnotenone0/10The evidence pack covers card issuing, spend controls, ledger, disputes, webhooks, and agentic card provisioning, but there is no mention of network tokens, tokenized digital cards' token-level management, wallet/merchant token association, or ability to revoke a token independently of the PAN. missing for 10: network token visibility/management APIs, wallet/merchant identification for tokens, token-level revocation separate from card cancellation.
- [claimed-docs] “Create and manage customizable payment cards, including virtual, physical, and tokenized digital cards.”
- [claimed-docs] “Embed sensitive card data in your UI and avoid PCI data from being compromised”
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”
Highnoten/aHighnote is a card issuance/payments platform, not an AI agent product; the story asks whether the product (as an agent) can plug in MCP servers to use their tools, which is a category mismatch for a payments PaaS. No evidence suggests Highnote acts as an MCP client consuming external tool servers.
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.
Highnoten/aHighnote is a card issuing/payments infrastructure platform for building agentic commerce solutions (e.g., issuing cards to AI agents), not a product with a built-in AI assistant that a user delegates tasks to. This story asks about an in-product AI assistant persona, which is a category error for a payments API/platform.
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 userExport all of my data in open formats and leave
weight 3 · not comparableMarqetanone0/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.”
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.
Highnoten/aHighnote is a closed proprietary fintech platform-as-a-service (card issuance, payment processing) with an SDK named '@highnote-oss/nodejs-sdk' but no evidence of the core product/source being open-licensed; this is a category error for a hosted financial API platform, not a source-available software 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 userChoose where my data is stored (region/residency)
weight 2 · not comparableMarqetanone0/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 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.
ai-native userControl data retention and deletion
weight 2 · not comparableMarqetanone0/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.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableMarqetanone0/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.