Highnote vs Adyen Issuing
Highnote wins · 23–4 (15 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 HighnoteDirect 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.”
A direct probe confirms Adyen hosts a working llms.txt (HTTP 200) with real descriptive content pointing to its Issuing and other docs, and individual doc pages are available in markdown form (e.g. relayed-authorisation.md, raise-disputes.md), showing agent-friendly documentation structure. Missing for 10: a full docs-root markdown index (docs/.md returned 404) and an OpenAPI/machine-readable spec endpoint (all candidates 404), so agent tooling coverage is incomplete.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [probe] “PROBE docs-md: HTTP 404 at https://docs.adyen.com/issuing/.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to HighnoteHighnote 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, …”
Adyen Issuing is API/webhook-driven (creating payment instruments, relayed authorization webhooks, transaction rules via API calls), which inherently supports headless/programmatic use outside a UI. However, there is no explicit documentation of CI pipelines, SDKs, or automated testing workflows beyond a generic error-simulation endpoint, and the OpenAPI spec discovery probe returned 404s, limiting confidence in API-first automation packaging. Missing for 10: explicit CI/CD integration guides, official SDKs/automation examples, and a discoverable OpenAPI spec.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnHighnotenone0/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 drawnHighnotenone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userDrive the product through a documented public API
weight 3 · round to HighnoteHighnote 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…”
Multiple documented REST-style API endpoints (paymentInstruments, balanceAccounts, authorization webhooks, disputes API) confirm Adyen Issuing is API-driven and well documented, with llms.txt indicating AI-friendly doc structure. However, no discoverable OpenAPI/Swagger spec was found (all candidate paths 404'd), which weakens machine-readability for AI-native tooling. missing for 10: publicly discoverable OpenAPI/Swagger spec, explicit SDK/agent-friendly API reference, independent corroboration of API usability by third parties.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnHighnotenone0/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 HighnoteHighnote 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…”
Adyen Issuingnone0/10The evidence pack covers Adyen Issuing's API capabilities (cards, authorization, disputes, webhooks) but contains no mention of official client SDKs in any language, nor any SDK repository links; probes for OpenAPI specs also failed (404). Missing for 10: any reference to official SDKs, language coverage, or SDK documentation/repos.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
ai-native userSubscribe to events via webhooks
weight 2 · round to HighnoteHighnote 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.”
Adyen Issuing supports webhooks for relayed authorization events with strict reply-time requirements, configured via Customer Area, indicating webhook-based event subscription exists. However, there's no evidence of a general-purpose webhook subscription API/config for arbitrary event types beyond authorization, nor documentation of a standard/self-service webhook management endpoint typical of agentic integration. Missing for 10: broader webhook event catalog (non-authorization events), programmatic webhook subscription/management API, and independent corroboration of webhook reliability.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round drawnHighnotenone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Adyen Issuingnone0/10No evidence of AI-generated insights, analytics, or suggestions surfaced from cardholder/transaction data; all evidence covers card issuing mechanics, authorization rules, and dispute management. Missing for 10: any mention of AI/ML-based insight generation, natural-language querying of data, or suggestion features.
ai-native userSet up automations that run autonomously in the background
weight 2 · round to HighnoteHighnote'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”
Adyen Issuing supports background automation via transaction rules that automatically approve/decline authorizations without manual intervention, and relayed-authorization webhooks that must be answered programmatically within 2000ms, both of which run autonomously once configured. However, there's no evidence of AI-native automation tooling, scheduling, or agent-style orchestration beyond simple rule-based logic. Missing for 10: AI-specific automation/agent framework, richer workflow/orchestration docs, and independent corroboration of rules running reliably in production.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
ai-native userOperate the product with natural-language commands
weight 2 · round drawnHighnotenone0/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 HighnoteHighnote 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…”
Adyen Issuingnone0/10No evidence of an interactive API reference with runnable examples; the probe explicitly shows OpenAPI spec files return 404 at all candidate paths, and no docs mention a try-it-now console or embedded runnable code samples.
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round drawnHighnotenone0/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.”
Adyen Issuingnone0/10The evidence pack contains no documentation link to an OpenAPI/Swagger spec for Adyen Issuing, and explicit probes for common OpenAPI paths (openapi.json, swagger.json, etc.) all returned 404, indicating no discoverable machine-readable spec.
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to HighnoteHighnote 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.”
There is only indirect evidence: docs mention forcing verification-check failures to test error handling flows, implying some testing capability, but no explicit documentation of a distinct sandbox/test environment, test API keys, or assurance that test activity never touches production data. missing for 10: explicit sandbox environment description, test-mode credentials, isolation guarantees from production, independent confirmation of sandbox parity.
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnHighnotenone0/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…”
Adyen Issuingnone0/10No evidence pack item addresses API versioning or a documented deprecation policy for Adyen Issuing APIs; docs cover product features, webhooks, and disputes but not version lifecycle/deprecation commitments. OpenAPI spec probes also 404'd, providing no supporting evidence of versioning structure.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
Auth decisioning — stories about auth decisioning in this arenaAuth decisioning
Stories about auth decisioning in this arena
Auth context
developerEvery authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals
weight 2 · round to HighnoteDocs 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…”
Adyen Issuingnone0/10The evidence confirms Adyen Issuing sends relayed authorization webhooks for approve/decline decisions, but nothing in the pack documents specific decision-grade fields like merchant name/MCC, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth signals. missing for 10: merchant name/MCC field documentation, enhanced merchant data schema, wallet/entry-mode indicators, partial-approval and incremental-auth support evidence.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Auth stream
developerApprove or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control
weight 3 · round to Adyen IssuingHighnote'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.”
Adyen documents relayed authorization webhooks sent to the developer's own servers with an explicit 2000ms reply budget to approve/decline, plus transaction rules as an automatic fallback/complement to real-time decisioning. Missing for 10: explicit documentation of what happens on timeout (default accept/decline behavior) and independent/hands-on corroboration beyond Adyen's own docs.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Simulation
developerSimulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes
weight 2 · round to HighnoteHighnote 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…”
Docs confirm sandbox-testable authorization webhooks (relayed authorization) and a dedicated way to force verification-check failures for testing error handling, which supports testing decline/approval logic pre-production. However, there's no evidence of simulating the full lifecycle (clearings, reversals, refunds) in sandbox specifically for auth-decisioning testing. missing for 10: explicit sandbox simulation of clearings, reversals, and refunds; end-to-end lifecycle test guide; independent/hands-on confirmation of sandbox fidelity.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To test your error handling flow, you can force a scenario where one or more verification checks fail.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to HighnoteHighnote'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 drawnHighnote 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.”
Adyen Issuing supports rule-based automation via transaction rules that automatically approve/decline authorizations and relayed authorization webhooks that let servers respond within 2000ms based on custom logic, which qualifies as event-triggered automation. However, this is transaction/authorization-scoped rather than a general-purpose 'define rules for any event' engine, and there's no evidence of a broader rules/workflow builder covering arbitrary events beyond card authorizations and disputes. Missing for 10: evidence of a general event-driven rules engine spanning all Issuing events (not just authorizations), and any AI-native tooling or examples for constructing such rules programmatically.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Card lifecycle — stories about card lifecycle in this arenaCard lifecycle
Stories about card lifecycle in this arena
Lifecycle states
developerThe full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
weight 2 · round to Adyen IssuingDocs confirm 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.”
Docs confirm activate, suspend (pause), and permanently close via API (docs-10), plus balance/account management (docs-11, docs-14), giving core lifecycle coverage. However, evidence does not explicitly show 'unpause' as distinct from activate, nor a documented lost/stolen reporting endpoint or a reissue-with-replacement-linked-to-original flow — missing for 10: explicit unpause/reactivate API call, lost-or-stolen reporting endpoint, and reissue/replacement-linkage API documentation.
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Physical cards
ops userOrder personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
weight 2 · round drawnDocs 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.”
Docs confirm Adyen Issuing lets you create fully customizable physical (and virtual) cards via API without a direct manufacturer relationship, but the evidence pack has no mention of bulk ordering, shipping method selection, or shipment tracking capabilities. missing for 10: bulk card order API, shipping method configuration, shipment tracking documentation/evidence.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
Virtual cards
developerCreate a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cycle
weight 3 · round to HighnoteDocs 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…”
Docs confirm Adyen Issuing lets you create fully customizable virtual and physical cards via the platform (adyen-issuing-docs-1) and manage their lifecycle (activate/suspend/close) via API (adyen-issuing-docs-10), implying some programmatic card creation, but nothing in the evidence confirms that PAN/CVV/expiry are returned synchronously in the same API call, nor is there any mention of a self-serve sandbox-to-production path without a sales/onboarding process. missing for 10: explicit API response schema showing PAN/CVV/expiry returned instantly, evidence of self-serve account activation from sandbox to live without a sales cycle.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
Issuing agent access — stories about issuing agent access in this arenaIssuing agent access
Stories about issuing agent access in this arena
Agent cards
ai-native userGive an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name
weight 3 · round to HighnoteHighnote 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.”
Adyen Issuingnone0/10Adyen Issuing docs show generic virtual card creation, transaction rules, and authorization controls, but nothing in the evidence pack mentions AI agents, agentic purchasing, or a named 'agent card' use case — the specific vendor-documented AI-agent framing required by the story is absent. missing for 10: any mention of AI agents, agent-scoped cards, or documentation naming this use case by name.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
Agent operations
ai-native userAn agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials
weight 2 · round drawnHighnote'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…”
Adyen Issuing's API supports core card-program actions an agent would need—creating cards, activating/suspending/closing them, updating balance account linkage, and defining transaction rules for spend control (docs-1, docs-3, docs-10, docs-11)—but there is no mention of an MCP surface, no explicit scoped API-credential/permission model, and no clear API endpoint documentation for reading balances/transaction history (only a Customer Area UI view is cited, docs-13). missing for 10: MCP server/tool surface, scoped API-key/credential scoping documentation, explicit balance/transaction-read API endpoints.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
- [claimed-docs] “Viewing card payments in the Customer Area”
Issuing compliance — stories about issuing compliance in this arenaIssuing compliance
Stories about issuing compliance in this arena
Kyc
ops userCardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows
weight 2 · round to HighnoteDocs 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…”
Adyen Issuingnone0/10The evidence pack only mentions generic 'verification checks' in a testing context (adyen-issuing-docs-12) with no documented KYC/KYB data requirements, review states, or re-verification flows for cardholders or businesses. No citations describe onboarding verification processes, only card lifecycle, authorization, and dispute handling.
Pci scope
developerShow cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D
weight 2 · round to HighnoteHighnote 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 Adyen IssuingHighnote 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.”
Adyen documents a Raise Disputes API letting cardholders initiate disputes/fraud reports, but evidence submission is only via a pilot manual zip-upload through the Customer Area rather than a full programmatic evidence API, and there's no documentation of network reason codes, provisional credit handling, or dispute-specific status webhooks through resolution. missing for 10: network reason code mapping, provisional credit issuance/tracking, dispute status webhooks/resolution lifecycle, non-pilot programmatic evidence submission.
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
Fraud monitoring
ops userThe platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cards
weight 2 · round drawnHighnote 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…”
Adyen Issuing lets ops build transaction rules and relayed authorization logic to approve/decline in real time, and provides card suspend/close controls plus a Raise Disputes API for cardholders to report fraud or lost cards — covering blocking and dispute workflows. However there is no evidence of network fraud scores or Adyen's own risk models surfaced at auth time, no mention of suspicious-activity alerting, and no explicit card-reissue tooling (only activate/suspend/close). missing for 10: fraud-score/model signals at authorization, proactive suspicious-activity alerts, dedicated reissue flow for compromised cards.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
Ledger settlement — stories about ledger settlement in this arenaLedger settlement
Stories about ledger settlement in this arena
Balances
finance leadSee money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny
weight 3 · round to HighnoteDocs 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…”
Docs show balance accounts/payment instruments architecture, authorization webhooks, and a Customer Area view of card payments, which supports basic balance and transaction visibility. However there is no evidence of a transaction ledger explicitly tying each authorization to its clearing event, nor of settlement/reconciliation reporting that ties to the penny. missing for 10: settlement report documentation, authorization-to-clearing ledger detail, reconciliation accuracy claims or tooling.
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “Viewing card payments in the Customer Area”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Recon reports
finance leadI get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically
weight 2 · round to HighnoteHighnote 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”
Adyen Issuingnone0/10The evidence pack covers card issuance, authorization webhooks, disputes, and balance accounts, but contains no mention of daily settlement files, report APIs, or interchange/fee/network adjustment reconciliation artifacts. No documentation references machine-readable reconciliation exports for finance systems.
Settlement events
developerPost-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts
weight 2 · round to HighnoteHighnote'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”
Evidence confirms authorization webhooks (relayed auth) and a dispute/chargeback API, but nothing in the pack documents webhooks for clearings, refunds, or reversals, nor stable transaction identifiers tying post-auth events back to the original authorization for ledger reconciliation. missing for 10: clearing/refund/reversal webhook events, explicit stable transaction ID linkage across auth→clearing→refund, independent corroboration of ledger accuracy.
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnHighnote 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…”
Docs show extensive API coverage (card creation, authorization rules, balance management, card lifecycle, disputes) mirroring Customer Area capabilities, and Adyen exposes APIs as the primary interface. However, some features like uploading dispute zip files and viewing card payments are explicitly Customer Area-only (pilot feature), and no discoverable OpenAPI spec was found via probes, undercutting full API-parity claims. missing for 10: evidence of API equivalents for Customer-Area-only dispute upload and payment viewing features, a public OpenAPI/machine-readable spec confirming full API surface, independent confirmation of full UI-API parity.
- [claimed-docs] “Provide a UI for your cardholders to ask for their money back and to report fraudulent transactions and lost cards using the Raise disputes …”
- [claimed-docs] “Package dispute details and supporting information into a zip file and upload them through the Customer Area (pilot feature).”
- [claimed-docs] “Viewing card payments in the Customer Area”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
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 HighnoteHighnote'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…”
Adyen Issuingnone0/10The evidence only shows generic card creation (virtual/physical, Visa/Mastercard) and balance-pooling/per-card balance options, but never distinguishes or confirms support for debit, prepaid, commercial credit, and consumer credit program types. Missing for 10: explicit documentation of credit line/revolving credit program support, commercial vs consumer credit distinctions, and debit vs prepaid program configuration options.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Funding models
finance leadChoose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented
weight 2 · round drawnHighnote 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…”
Docs confirm relayed authorization (JIT-style, real-time approve/decline within 2000ms) and pooled vs per-card balance funding options, showing both funding models exist. However, there is no explicit finance-lead-oriented documentation contrasting prefunded vs JIT cash-flow tradeoffs. missing for 10: explicit cash-flow tradeoff documentation, guidance on choosing between prefunded and JIT funding, finance-focused framing rather than developer/webhook mechanics.
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “To configure relayed authorisation webhooks: 1. Log in to your Customer Area. 2. Go to Financial products > Relayed authorisation.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
Program launch
founderLaunch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented
weight 3 · round to HighnoteDocs 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.”
Docs show Adyen issues Visa/Mastercard cards and manages authorization, transaction rules, and card lifecycle, implying Adyen handles network membership so founders don't need their own bank charter — but there is no explicit statement about BIN sponsorship, no discussion of becoming/not becoming a bank, and no documented timeline from signup to first live card. missing for 10: explicit BIN sponsorship/network membership language, articulation that founders avoid bank licensing, and a documented signup-to-live-card timeline.
- [claimed-docs] “Create fully customizable virtual and physical cards from Mastercard and Visa.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “A 1-N relationship with one accountHolder with multiple balanceAccounts and paymentInstruments.”
Spend controls — stories about spend controls in this arenaSpend controls
Stories about spend controls in this arena
Limits
ops userSet spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code
weight 3 · round to HighnoteDocs 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.”
Adyen Issuing docs reference configurable 'transaction rules to automatically approve or decline authorizations' (docs-3) and relayed authorization webhooks giving full custom control (docs-2, docs-5, docs-6), implying some platform-side rule enforcement exists, but the evidence never specifies per-card/per-cardholder amount caps over daily/monthly/all-time windows or transaction-count velocity rules as platform-native controls. Missing for 10: explicit documentation of spend-limit configuration fields (daily/monthly/all-time caps), velocity/transaction-count rule specifics, and confirmation these are enforced natively rather than via custom relayed-authorization logic.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Merchant controls
ops userRestrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
weight 2 · round to HighnoteHighnote'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.”
Adyen Issuing supports configurable 'transaction rules' to automatically approve or decline authorizations and relayed authorization webhooks allowing custom logic at auth time, which could implement MCC or merchant restrictions, but the evidence never explicitly describes MCC allow/blocklists or single-merchant locking as a documented feature. missing for 10: explicit documentation of MCC-based allow/block rules, single-merchant lock configuration, and confirmation these are evaluated at authorization time.
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
Scoped cards
developerIssue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
weight 2 · round to HighnoteHighnote 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.”
Adyen Issuing supports transaction rules and real-time relayed authorization webhooks that let a developer approve/decline based on merchant, amount, or other criteria, and cards can be activated/suspended/closed, giving the building blocks for tight scoping. However, there is no explicit documented 'single-use card' primitive or per-card merchant-lock/exact-amount enforcement — that logic must be built entirely by the developer via custom rules/webhook logic rather than a first-class feature. Missing for 10: native single-use card issuance, built-in per-merchant locking, built-in exact-amount matching, independent confirmation these controls work as designed.
- [claimed-docs] “Receive authorization requests on your own servers so you can approve or decline any authorization.”
- [claimed-docs] “Create transaction rules to automatically approve or decline authorizations.”
- [claimed-docs] “With each relayed authorisation webhook we send, you have up to 2000 milliseconds to reply with an approval or a refusal.”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “Use a single pool of funds for all card payments or maintain balances per card.”
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization
Stories about wallets tokenization in this arena
Credentials
developerCardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets
weight 2 · round to Adyen IssuingHighnotenone0/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.
Docs confirm 3DS enrollment via API (OTP and out-of-band authentication) which addresses regional 3DS requirements without support tickets, and card lifecycle actions (activate/suspend/close, balance account updates) are API-driven. However, there is no evidence of PIN set/reset flows being exposed through the API — missing for 10: PIN set API, PIN reset API, any documentation of PIN management endpoints.
- [claimed-docs] “There are two ways to enroll your Adyen-issued cards in 3D Secure: One-time password authentication ... Out-of-band authentication”
- [claimed-docs] “Activating a card to enable payment processing. Suspending a card to temporarily stop payment processing. Permanently closing a card.”
- [claimed-docs] “To update the balance account ID, make a /paymentInstruments/{id} request and send the new balanceAccountId.”
Tokenization
developerNetwork tokens are first-class — I can see and manage the tokens created for a card, know which wallet or merchant holds them, and revoke them independently of the PAN
weight 2 · round drawnHighnotenone0/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”
Adyen Issuingnone0/10The evidence pack covers card creation, authorization handling, transaction rules, disputes, 3DS enrollment, and card lifecycle management, but contains no mention of network tokens, tokenization, wallet/merchant token visibility, or token-specific revocation independent of the PAN.
Wallet provisioning
developerCards land in Apple Pay and Google Pay — push provisioning from my app with the entitlements process documented, plus in-wallet card art and manual provisioning as a fallback
weight 2 · round drawnHighnotenone0/10Evidence covers card issuance, spend controls, ledger, disputes, and SDKs, but nowhere mentions Apple Pay/Google Pay push provisioning, entitlements process, in-wallet card art, or manual provisioning fallback for digital wallets.
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableHighnoten/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 comparableHighnoten/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 comparableHighnoten/aHighnote is a card issuance/payment infrastructure platform, not a workflow/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 comparableHighnoten/aHighnote is a card issuing/payments infrastructure platform, not an automation/workflow tool with versionable automations to review or roll back; this axis is a category error for its product type.
ai-native userExport all of my data in open formats and leave
weight 3 · not comparableHighnoten/aHighnote is a card issuance/payments platform-as-a-service, not a data/knowledge tool where a user accumulates personal data that would need bulk export in open formats; the 'export data and leave' story is a category mismatch (wrong axis) for this kind of product.
Adyen Issuingnone0/10No evidence of any data export/portability feature or open-format bulk export capability; documentation covers card issuing, authorization, disputes, and management APIs but nothing about exporting all account/transaction data or facilitating account closure with data portability.
ai-native userRead the product's source under an open license
weight 2 · not comparableHighnoten/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 comparableHighnoten/aHighnote is a regulated card-issuing/payments-as-a-service platform requiring banking partnerships, compliance, and licensed infrastructure — self-hosting is not a coherent capability for this category of product.
ai-native userChoose where my data is stored (region/residency)
weight 2 · not comparableHighnoten/aHighnote is a card issuance/payments platform, not a data storage or AI infrastructure product; data residency/region selection is not a relevant axis for this category based on the evidence provided.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableHighnoten/aHighnote is a card issuance/payment platform, not an AI model or data-processing service; AI training data usage is entirely outside its product category.
ai-native userControl data retention and deletion
weight 2 · not comparableHighnoten/aHighnote is a card issuing/payments platform, not an AI data/model product; data retention and deletion controls in the privacy sense (e.g., user data, conversation logs) are not a relevant axis for this kind of product.
Adyen Issuingnone0/10The evidence pack covers card issuing, authorization, disputes, and management features but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management for AI-native users. This is an applicable axis for a payments platform handling sensitive cardholder data, but no evidence supports it.
ai-native userOpt out of telemetry and usage tracking
weight 2 · not comparableHighnoten/aHighnote is a card issuance/payments platform, not an AI tool or developer service with telemetry collected from AI-native users; the evidence pack contains no mention of telemetry/usage tracking at all. This axis is a category mismatch for this type of product.