[ { "productId": "adyen-issuing", "storyId": "agent-issued-cards", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen 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.", "evidenceIds": [ "adyen-issuing-docs-1", "adyen-issuing-docs-3" ] }, { "productId": "adyen-issuing", "storyId": "agent-manages-program", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-1", "adyen-issuing-docs-3", "adyen-issuing-docs-10", "adyen-issuing-docs-11", "adyen-issuing-docs-13" ] }, { "productId": "adyen-issuing", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "adyen-issuing-probe-1", "adyen-issuing-docs-5", "adyen-issuing-docs-7", "adyen-issuing-probe-2", "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-3", "adyen-issuing-docs-5", "adyen-issuing-docs-2" ] }, { "productId": "adyen-issuing", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a card issuing/payments infrastructure API product, not an agent-hosting product with a built-in AI assistant persona; this axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-2", "adyen-issuing-docs-3", "adyen-issuing-docs-5", "adyen-issuing-docs-11", "adyen-issuing-docs-12", "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a card-issuing platform, not an AI agent or assistant; there is no evidence it acts as an MCP client that plugs in external tool servers, and this role-based capability is out of scope for this product category.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The 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.)", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of natural-language command interfaces, chatbots, or AI-native controls; the documentation describes REST APIs, webhooks, and Customer Area UI configuration only. Missing for 10: any NL interface, conversational agent, or AI-native command capability.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official CLI for Adyen Issuing; documentation only covers APIs, webhooks, and Customer Area UI configuration.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-2", "adyen-issuing-docs-7", "adyen-issuing-docs-11", "adyen-issuing-docs-14", "adyen-issuing-probe-1", "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The 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.)", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-5", "adyen-issuing-docs-6", "adyen-issuing-docs-2" ] }, { "productId": "adyen-issuing", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [ "adyen-issuing-probe-3", "adyen-issuing-probe-2" ] }, { "productId": "adyen-issuing", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "adyen-issuing-probe-3", "adyen-issuing-probe-2" ] }, { "productId": "adyen-issuing", "storyId": "api-sandbox", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-12" ] }, { "productId": "adyen-issuing", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [ "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "auth-context-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "adyen-issuing-docs-2", "adyen-issuing-docs-5" ] }, { "productId": "adyen-issuing", "storyId": "auth-simulation-testing", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-5", "adyen-issuing-docs-12", "adyen-issuing-docs-2", "adyen-issuing-docs-3" ] }, { "productId": "adyen-issuing", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers per-card operations (create, activate, suspend, close, update balance account) and API-driven management, but nothing describes bulk/batch endpoints or multi-item operations performed in a single call for AI-native automation.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-3", "adyen-issuing-docs-5", "adyen-issuing-docs-6", "adyen-issuing-docs-2" ] }, { "productId": "adyen-issuing", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a card-issuing API platform, not a workflow/job orchestration or automation-scheduling tool; scheduling recurring jobs/workflows is outside its product category and is a wrong axis for this type of product.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a card-issuing payments API/platform, not an automation/workflow builder; versioning, reviewing, and rolling back 'automations' is not a concept this product exposes (transaction rules are configuration, not versioned automations with rollback).", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "balance-ledger-visibility", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-4", "adyen-issuing-docs-13", "adyen-issuing-docs-14", "adyen-issuing-docs-2" ] }, { "productId": "adyen-issuing", "storyId": "card-state-management", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-10", "adyen-issuing-docs-11", "adyen-issuing-docs-14" ] }, { "productId": "adyen-issuing", "storyId": "cardholder-kyc", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "clearing-settlement-events", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-5", "adyen-issuing-docs-7", "adyen-issuing-docs-8" ] }, { "productId": "adyen-issuing", "storyId": "credit-debit-prepaid-range", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "adyen-issuing-docs-1", "adyen-issuing-docs-4", "adyen-issuing-docs-14" ] }, { "productId": "adyen-issuing", "storyId": "digital-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers card issuance, authorization, disputes, 3D Secure, and card management, but contains no mention of Apple Pay/Google Pay push provisioning, entitlements process, in-wallet card art, or manual provisioning fallback.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "dispute-filing-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-7", "adyen-issuing-docs-8" ] }, { "productId": "adyen-issuing", "storyId": "funding-model-flexibility", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-4", "adyen-issuing-docs-5", "adyen-issuing-docs-6", "adyen-issuing-docs-2" ] }, { "productId": "adyen-issuing", "storyId": "issuing-fraud-controls", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-3", "adyen-issuing-docs-5", "adyen-issuing-docs-7", "adyen-issuing-docs-10" ] }, { "productId": "adyen-issuing", "storyId": "merchant-category-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-3", "adyen-issuing-docs-2", "adyen-issuing-docs-5" ] }, { "productId": "adyen-issuing", "storyId": "network-tokenization-visibility", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-7", "adyen-issuing-docs-8", "adyen-issuing-docs-13", "adyen-issuing-docs-6", "adyen-issuing-probe-3" ] }, { "productId": "adyen-issuing", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a proprietary financial/payments API service, not open-source software; there is no notion of an open-licensed source code base to read, so this axis is a category error for this product.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a regulated card-issuing SaaS/BaaS platform relying on Adyen's banking licenses and infrastructure; self-hosting the core product is a category error for this kind of service, not a missing feature.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "pci-scope-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card issuing, authorization, disputes, and 3DS, but contains no mention of PAN/CVV reveal mechanisms, hosted components for displaying card data, ephemeral-key flows, or any explicit PCI SAQ D scope reduction guidance for cardholder data display.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "physical-card-fulfillment", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-1" ] }, { "productId": "adyen-issuing", "storyId": "pin-3ds-management", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-9", "adyen-issuing-docs-10", "adyen-issuing-docs-11" ] }, { "productId": "adyen-issuing", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, regional data storage, or choice of processing region for Adyen Issuing; all citations relate to card issuance, authorization, and dispute features.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen Issuing is a card-issuing/payments platform, not an AI model or AI product with training-data practices; the axis of preventing personal data use for AI model training does not apply to this category of product.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers card issuing, authorization, disputes, and 3D Secure features but contains no mention of telemetry, usage tracking, analytics collection, or opt-out settings of any kind.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "program-launch-speed", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-1", "adyen-issuing-docs-10", "adyen-issuing-docs-14" ] }, { "productId": "adyen-issuing", "storyId": "realtime-auth-decisioning", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-2", "adyen-issuing-docs-5", "adyen-issuing-docs-6", "adyen-issuing-docs-3" ] }, { "productId": "adyen-issuing", "storyId": "reconciliation-reporting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [] }, { "productId": "adyen-issuing", "storyId": "single-use-scoped-cards", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-2", "adyen-issuing-docs-3", "adyen-issuing-docs-5", "adyen-issuing-docs-10", "adyen-issuing-docs-4" ] }, { "productId": "adyen-issuing", "storyId": "spend-limits-velocity", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-3", "adyen-issuing-docs-2", "adyen-issuing-docs-5" ] }, { "productId": "adyen-issuing", "storyId": "virtual-card-creation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "adyen-issuing-docs-1", "adyen-issuing-docs-10" ] }, { "productId": "highnote", "storyId": "agent-issued-cards", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-docs-17", "highnote-docs-18", "highnote-docs-21", "highnote-docs-8", "highnote-docs-9" ] }, { "productId": "highnote", "storyId": "agent-manages-program", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-2", "highnote-docs-3", "highnote-docs-17", "highnote-docs-18", "highnote-docs-19", "highnote-docs-21", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-probe-1", "highnote-docs-17" ] }, { "productId": "highnote", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The 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.)", "evidenceIds": [] }, { "productId": "highnote", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-17", "highnote-docs-18", "highnote-docs-20", "highnote-docs-21", "highnote-docs-8", "highnote-docs-9", "highnote-docs-12" ] }, { "productId": "highnote", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-6", "highnote-docs-11", "highnote-docs-12", "highnote-docs-22", "highnote-probe-1" ] }, { "productId": "highnote", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [ "highnote-docs-6", "highnote-docs-22", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Highnote'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.", "evidenceIds": [ "highnote-docs-6", "highnote-docs-22", "highnote-probe-1" ] }, { "productId": "highnote", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The 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.)", "evidenceIds": [] }, { "productId": "highnote", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-docs-6", "highnote-docs-11", "highnote-docs-12", "highnote-docs-17", "highnote-docs-20", "highnote-docs-22", "highnote-probe-1", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Highnote'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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-6", "highnote-docs-14", "highnote-docs-15", "highnote-docs-16", "highnote-docs-22", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-docs-12", "highnote-docs-13", "highnote-docs-22" ] }, { "productId": "highnote", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-22", "highnote-docs-11", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Highnote'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.", "evidenceIds": [ "highnote-probe-2", "highnote-docs-22" ] }, { "productId": "highnote", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-docs-11", "highnote-docs-22" ] }, { "productId": "highnote", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [ "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "auth-context-enrichment", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-7", "highnote-docs-8" ] }, { "productId": "highnote", "storyId": "auth-simulation-testing", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-11", "highnote-docs-20", "highnote-docs-7", "highnote-docs-8" ] }, { "productId": "highnote", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-21", "highnote-docs-17", "highnote-docs-18" ] }, { "productId": "highnote", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-7", "highnote-docs-8", "highnote-docs-9", "highnote-docs-12", "highnote-docs-18", "highnote-docs-21" ] }, { "productId": "highnote", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote is a card issuance/payment infrastructure platform, not a workflow/orchestration tool; scheduling recurring jobs or workflows is outside its product category (wrong axis).", "evidenceIds": [] }, { "productId": "highnote", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "balance-ledger-visibility", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-3", "highnote-docs-19", "highnote-docs-23", "highnote-docs-20" ] }, { "productId": "highnote", "storyId": "card-state-management", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-4", "highnote-docs-17" ] }, { "productId": "highnote", "storyId": "cardholder-kyc", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-23", "highnote-docs-16", "highnote-docs-4", "highnote-docs-5" ] }, { "productId": "highnote", "storyId": "clearing-settlement-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-12", "highnote-docs-13", "highnote-docs-3", "highnote-docs-19", "highnote-docs-20", "highnote-docs-10" ] }, { "productId": "highnote", "storyId": "credit-debit-prepaid-range", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-4", "highnote-docs-24", "highnote-docs-23" ] }, { "productId": "highnote", "storyId": "digital-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "dispute-filing-api", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-10", "highnote-docs-12", "highnote-docs-13" ] }, { "productId": "highnote", "storyId": "funding-model-flexibility", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-7", "highnote-docs-3", "highnote-docs-4", "highnote-docs-25", "highnote-docs-20" ] }, { "productId": "highnote", "storyId": "issuing-fraud-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-7", "highnote-docs-8", "highnote-docs-9", "highnote-docs-10", "highnote-docs-5" ] }, { "productId": "highnote", "storyId": "merchant-category-controls", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-8", "highnote-docs-18", "highnote-docs-21", "highnote-docs-7" ] }, { "productId": "highnote", "storyId": "network-tokenization-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-14" ] }, { "productId": "highnote", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-2", "highnote-docs-3", "highnote-docs-7", "highnote-docs-8", "highnote-docs-9", "highnote-docs-10", "highnote-docs-11", "highnote-docs-22", "highnote-probe-2" ] }, { "productId": "highnote", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "pci-scope-management", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-14", "highnote-docs-15", "highnote-docs-22" ] }, { "productId": "highnote", "storyId": "physical-card-fulfillment", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-1", "highnote-docs-4" ] }, { "productId": "highnote", "storyId": "pin-3ds-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote is a card issuance/payment platform, not an AI model or data-processing service; AI training data usage is entirely outside its product category.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Highnote 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.", "evidenceIds": [] }, { "productId": "highnote", "storyId": "program-launch-speed", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-23", "highnote-docs-10", "highnote-docs-24", "highnote-docs-4" ] }, { "productId": "highnote", "storyId": "realtime-auth-decisioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-7", "highnote-docs-12", "highnote-docs-13", "highnote-docs-22" ] }, { "productId": "highnote", "storyId": "reconciliation-reporting", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "highnote-docs-3", "highnote-docs-19", "highnote-docs-23", "highnote-docs-12" ] }, { "productId": "highnote", "storyId": "single-use-scoped-cards", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "highnote-docs-2", "highnote-docs-8", "highnote-docs-9", "highnote-docs-17", "highnote-docs-18", "highnote-docs-21" ] }, { "productId": "highnote", "storyId": "spend-limits-velocity", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.\n\nmissing for 10: explicit documentation of all-time (lifetime) window caps distinct from daily/monthly/weekly, and independent/hands-on confirmation beyond vendor docs.", "evidenceIds": [ "highnote-docs-2", "highnote-docs-7", "highnote-docs-8", "highnote-docs-9", "highnote-docs-18", "highnote-docs-21" ] }, { "productId": "highnote", "storyId": "virtual-card-creation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "highnote-docs-4", "highnote-docs-11", "highnote-docs-14", "highnote-docs-23" ] }, { "productId": "lithic", "storyId": "agent-issued-cards", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Lithic explicitly targets this use case: a dedicated 'agentic commerce' solutions page and blog post walk through creating a virtual card for an AI agent, assigning authorization rules that cap merchant categories, transaction limits and velocity, and testing that agent's purchases stay within policy — with card/account-level rule scoping and spend limits documented as first-class primitives. Missing for 10: explicit documentation of expiry as an agent-specific control (only general card creation docs cover expiry), and independent/third-party hands-on validation beyond the vendor's own demo blog post.", "evidenceIds": [ "lithic-docs-11", "lithic-docs-12", "lithic-docs-3", "lithic-docs-13", "lithic-docs-9" ] }, { "productId": "lithic", "storyId": "agent-manages-program", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic's REST API clearly supports reading transactions, creating/updating cards, and configuring spend/authorization controls (lithic-docs-3, lithic-docs-9, lithic-docs-13), and Lithic ships an official MCP server (lithic-probe-3) that a blog post shows being used to create a card, configure authorization rules, and run test transactions (lithic-docs-11), going beyond mere doc lookup described in lithic-docs-1. However, the official MCP docs frame the server primarily as a docs/code-generation aid rather than a first-class operational surface, and there is no explicit description of scoped-credential issuance for agent use via MCP or API keys. Missing for 10: explicit scoped-credential/API-key model for agent access, first-party documentation confirming MCP as a full operational (not just dev-assist) surface, independent corroboration of agentic use beyond one blog example.", "evidenceIds": [ "lithic-docs-1", "lithic-docs-3", "lithic-docs-9", "lithic-docs-13", "lithic-docs-11", "lithic-probe-3" ] }, { "productId": "lithic", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Lithic hosts a working llms.txt confirmed by direct probe (HTTP 200) with structured developer docs, plus a dedicated MCP server that lets agents search docs, inspect schemas, and execute API requests. Missing for 10: independent/third-party confirmation of agents actually consuming llms.txt in practice, and no broader agent-oriented docs index beyond the single llms.txt file.", "evidenceIds": [ "lithic-probe-1", "lithic-docs-1", "lithic-probe-3" ] }, { "productId": "lithic", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Lithic's evidence covers an MCP server for developers to query docs/API and 'agentic commerce' messaging about autonomous issuing/payments, but there is no evidence of the product itself surfacing AI-generated insights or suggestions from a user's own transaction/account data inside a Lithic dashboard or interface.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic's Authorization Rules v2, ASA webhooks, and Events API let developers configure rules and endpoints that autonomously evaluate and act on transactions in real time without human intervention (lithic-docs-2,3,4,6), and Lithic explicitly markets 'autonomous issuing, payments, and controls for AI-powered workflows' with an MCP server that can configure and test such rules (lithic-docs-11,12). However, this is transaction-rule automation rather than a general-purpose scheduler/agent framework for arbitrary background tasks, and there's no dedicated docs on setting up recurring/cron-style AI agent jobs beyond the payments rules domain. Missing for 10: evidence of a general task-scheduling/automation framework beyond payment authorization rules, and independent/hands-on confirmation that these automations run reliably unattended.", "evidenceIds": [ "lithic-docs-2", "lithic-docs-3", "lithic-docs-4", "lithic-docs-6", "lithic-docs-11", "lithic-docs-12" ] }, { "productId": "lithic", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Lithic's evidence describes an MCP server that lets external AI assistants (in the user's editor) connect to Lithic's API/docs, not a built-in assistant embedded inside Lithic's own product/dashboard for delegating tasks. No evidence of an in-product AI assistant feature exists in the pack.", "evidenceIds": [ "lithic-docs-1", "lithic-probe-3", "lithic-docs-11" ] }, { "productId": "lithic", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Lithic is a REST API platform with a sandbox environment for simulating transactions (lithic-docs-5) and versioned API headers (lithic-docs-7), which implies it can be scripted/automated in CI pipelines since it's inherently API-driven rather than GUI-driven. However, there is no explicit documentation of CI/CD integration, headless test runners, or automation-specific tooling/SDKs for pipeline use. missing for 10: explicit CI/CD examples, dedicated automation SDK/CLI, documented headless test workflows, independent confirmation of CI usage.", "evidenceIds": [ "lithic-docs-5", "lithic-docs-7", "lithic-probe-1" ] }, { "productId": "lithic", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a card-issuing/payments API platform, not an AI agent or assistant that itself acts as an MCP client consuming external tool servers. The evidence shows Lithic publishes an MCP *server* so other AI assistants can use Lithic's tools — the reverse direction from this story, which asks whether users can plug MCP servers into Lithic. This client-side axis is a category error for this product type.", "evidenceIds": [ "lithic-docs-1", "lithic-probe-3" ] }, { "productId": "lithic", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Lithic is not itself an agent but a payments API platform, so publishing an official MCP server is a fair axis; docs and a probe confirm an official MCP server exists that lets AI assistants search docs, inspect schemas, and execute live API calls, with a blog walkthrough of agentic use (creating cards, configuring rules, running test transactions). Missing for 10: independent/third-party hands-on confirmation beyond vendor docs and blog.", "evidenceIds": [ "lithic-docs-1", "lithic-probe-3", "lithic-docs-11" ] }, { "productId": "lithic", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Lithic ships an official MCP server that lets an AI assistant search docs, inspect schemas, generate integration code, and execute live API requests in natural language, and a dedicated blog post walks through using it to create cards, set authorization rules, and run test transactions conversationally. Missing for 10: independent/hands-on third-party corroboration of the MCP workflow and broader coverage of natural-language commands outside the MCP/IDE context.", "evidenceIds": [ "lithic-docs-1", "lithic-docs-11", "lithic-probe-3", "lithic-docs-12" ] }, { "productId": "lithic", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an official Lithic CLI; the product offers an MCP server and REST API but nothing about a dedicated CLI tool for AI-native workflows.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Lithic exposes an extensive documented REST API covering cards, disputes, webhooks, KYC, spend limits, and versioning headers, plus reference pages for direct endpoint invocation, showing a fully documented public API surface an AI-native user could drive programmatically. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe returned 404s on standard paths) and independent third-party corroboration of API usability.", "evidenceIds": [ "lithic-docs-2", "lithic-docs-6", "lithic-docs-7", "lithic-docs-9", "lithic-docs-10", "lithic-docs-13", "lithic-probe-1", "lithic-probe-2" ] }, { "productId": "lithic", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic doesn't document scoped API keys/OAuth tokens per se, but it does support issuing virtual cards with tightly scoped authorization rules (merchant category, spend limits, velocity, entity-level rules) explicitly for AI agent use cases, as shown in the agentic payments blog and MCP server docs. This effectively delivers least-privilege 'credentials' (cards) for agents, though not classic API-key scoping. Missing for 10: explicit API key/token permission scoping mechanism, documentation of restricting an agent's API access (vs. card spend controls), independent verification of this workflow.", "evidenceIds": [ "lithic-docs-3", "lithic-docs-4", "lithic-docs-9", "lithic-docs-11", "lithic-docs-12", "lithic-docs-13" ] }, { "productId": "lithic", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Lithic's API documentation, MCP server, and various API features (auth rules, disputes, webhooks, etc.), but contains no mention of official SDKs (e.g., Python, Node, Java client libraries) that developers could build against. Absence of evidence for this applicable capability means it cannot be credited.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Lithic's Events API explicitly supports registering/managing webhook URLs, subscription secrets, replaying messages, and searching past events, and ASA webhooks deliver real-time transaction events via HTTP POST — directly enabling event subscription for agentic workflows. Missing for 10: independent/hands-on corroboration of webhook reliability and no direct mention of AI-agent-specific webhook consumption patterns.", "evidenceIds": [ "lithic-docs-6", "lithic-docs-2" ] }, { "productId": "lithic", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows a docs.lithic.com/reference section exists (e.g. postcards reference) but nothing describes runnable/interactive examples (a 'try it' console) and the OpenAPI spec probe returned 404s across all candidate paths, suggesting no exposed interactive spec. The MCP integration lets an AI assistant execute live requests from an editor, but that's a separate agent-tooling feature, not an interactive API reference page.", "evidenceIds": [ "lithic-docs-9", "lithic-probe-2" ] }, { "productId": "lithic", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "A probe explicitly checked standard OpenAPI spec locations (openapi.json, swagger.json, etc.) and all returned 404, and no documentation citation offers a downloadable machine-readable API spec; only an llms.txt (a documentation index, not an API schema) was found.", "evidenceIds": [ "lithic-probe-2", "lithic-probe-1" ] }, { "productId": "lithic", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Lithic explicitly documents a sandbox environment with endpoints to simulate transaction events (merchant acquirer simulation) separate from production, and a blog post walks through creating test accounts/cards and running transactions against rules in this sandbox — directly matching the AI-native testing story. missing for 10: independent/hands-on confirmation beyond vendor docs and blog, and no explicit statement on data isolation guarantees.", "evidenceIds": [ "lithic-docs-5", "lithic-docs-11" ] }, { "productId": "lithic", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Lithic documents versioned APIs via an `api-version` header (lithic-docs-7), confirming versioning support, but there is no evidence of a documented deprecation policy, sunset timelines, or changelog process for older API versions. missing for 10: documented deprecation/sunset policy, version lifecycle timelines, changelog or migration guidance for AI agents consuming the API.", "evidenceIds": [ "lithic-docs-7" ] }, { "productId": "lithic", "storyId": "auth-context-enrichment", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence covers ASA transaction metadata generically, authorization rules, and spend limits, but no citation specifically confirms merchant name/MCC, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth fields in authorization events.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "auth-simulation-testing", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a sandbox with endpoints to simulate merchant-acquirer transaction events (lithic-docs-5), and a blog walkthrough shows simulating authorizations against rules in a test environment (lithic-docs-11). However, there's no explicit documentation confirming simulation of the full lifecycle — clearings, reversals, refunds, and declines specifically — only general 'transaction events' language. missing for 10: explicit sandbox endpoints/examples for clearings, reversals, refunds, and declines individually; independent developer corroboration of full lifecycle simulation.", "evidenceIds": [ "lithic-docs-5", "lithic-docs-11" ] }, { "productId": "lithic", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of batch/bulk endpoints (e.g., bulk card creation, bulk transaction listing, or batch job APIs) in the documentation pack; only single-resource operations (create card, single ASA request, single rule) are described. Axis applies since a payments API could plausibly offer bulk operations, but nothing in the evidence supports it.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "automation-rules-engine", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Lithic's Authorization Rules v2 let users define conditional rules (velocity, merchant category, spend limits) at program/account/card level that automatically trigger approve/decline actions on transaction events, with shadow-mode testing and backtesting, plus webhooks/events API for reacting to other events. missing for 10: no evidence of broader arbitrary event-to-action rule engine beyond authorization/spend/webhook events, and no independent/hands-on confirmation of rule reliability at scale.", "evidenceIds": [ "lithic-docs-3", "lithic-docs-4", "lithic-docs-13", "lithic-docs-6", "lithic-docs-2" ] }, { "productId": "lithic", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a card issuing/payments API platform, not a workflow/job-scheduling or automation orchestration product; scheduling recurring jobs/workflows is outside its product category (wrong axis) rather than a missing feature.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There's a shadow-mode/backtesting feature for authorization rules, but no evidence of general versioning, review workflows, or rollback capability for automations/agent actions across Lithic's platform. Missing for 10: version history for automations, review/approval workflow, rollback mechanism beyond authorization-rule drafts.", "evidenceIds": [ "lithic-docs-4" ] }, { "productId": "lithic", "storyId": "balance-ledger-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers authorization rules, disputes, ASA, sandbox simulation, and webhooks, but contains no documentation of real-time balance views, a transaction ledger linking authorizations to clearing, or settlement reporting that reconciles to the penny — all of which are core to this finance-lead story for a card-issuing platform. Missing for 10: balance/ledger API docs, authorization-to-clearing linkage evidence, settlement/reconciliation reporting documentation.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "card-state-management", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence confirms API-driven card creation (virtual/physical) and spend/authorization controls, but there is no documentation covering activate, pause/unpause, lost-or-stolen reporting, reissue-with-linked-replacement, or permanent closure endpoints. missing for 10: pause/unpause endpoint docs, lost/stolen reporting, reissue linking to original card, permanent closure endpoint, independent confirmation of these lifecycle actions.", "evidenceIds": [ "lithic-docs-9", "lithic-docs-13", "lithic-docs-3" ] }, { "productId": "lithic", "storyId": "cardholder-kyc", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence confirms Lithic has a KYC process for individual account holders (and a bypass option, KYC_BYO) but provides no detail on data requirements, review states, or re-verification flows, and no mention of KYB for business entities at all. missing for 10: KYB business verification documentation, explicit data requirement fields, review-state lifecycle, re-verification/periodic review flows, independent corroboration.", "evidenceIds": [ "lithic-docs-8" ] }, { "productId": "lithic", "storyId": "clearing-settlement-events", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Lithic's Events API supports webhook registration, replay, and searching past events (lithic-docs-6), and the Disputes API mentions chargeback/representment handling (lithic-docs-10), suggesting some post-auth events reach developers programmatically. However, there is no explicit documentation confirming that clearings, refunds, and reversals are delivered as webhooks with stable transaction identifiers guaranteeing ledger consistency. Missing for 10: explicit event types for clearings/refunds/reversals, confirmation of stable transaction IDs across auth-to-settlement lifecycle, and independent/hands-on verification that ledger drift is prevented.", "evidenceIds": [ "lithic-docs-6", "lithic-docs-10" ] }, { "productId": "lithic", "storyId": "credit-debit-prepaid-range", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers authorization rules, KYC, disputes, sandbox testing, and MCP tooling, but contains no mention of distinct program types (debit, prepaid, commercial credit, consumer credit) or how Lithic supports each — missing for 10: any documentation of program-type variety, funding models (prepaid vs charge vs credit), or commercial vs consumer credit support.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "digital-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses Apple Pay/Google Pay push provisioning, entitlements process, in-wallet card art, or manual provisioning fallback; evidence covers unrelated topics like authorization rules, disputes, webhooks, and MCP integration.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "dispute-filing-api", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Lithic documents a Disputes API that handles network filing for chargebacks and representment responses, and a general Events/Webhooks API for status notifications, but the evidence pack lacks any documentation of specific network reason codes, evidence submission workflows, or provisional credit handling tied to disputes. missing for 10: reason code taxonomy, evidence submission endpoint details, provisional credit mechanics, dispute-specific webhook event examples.", "evidenceIds": [ "lithic-docs-10", "lithic-docs-6" ] }, { "productId": "lithic", "storyId": "funding-model-flexibility", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Lithic's Auth Stream Access (ASA) documents a just-in-time model where the finance lead's system receives an HTTP POST per authorization and returns an approval decision, which is direct evidence of JIT funding control. However, there is no evidence in the pack describing a prefunded-balance funding option or any documentation comparing cash-flow tradeoffs between the two models. Missing for 10: explicit prefunded balance funding mechanism, comparative cash-flow guidance/documentation, and finance-lead-facing tradeoff analysis.", "evidenceIds": [ "lithic-docs-2", "lithic-docs-13" ] }, { "productId": "lithic", "storyId": "issuing-fraud-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Lithic exposes strong authorization control infrastructure — configurable Authorization Rules at program/account/card level, shadow-mode/backtesting, real-time ASA hooks for custom decisioning, spend/velocity limits, and a disputes/chargeback API — which ops teams can use to build fraud logic and respond to compromise. However, there's no evidence of network fraud scores or Lithic's own ML fraud models surfaced at auth time, no dedicated suspicious-activity alerting, and no explicit block/reissue workflow documented in the pack. Missing for 10: documented fraud-score/model signal at authorization, proactive suspicious-activity alerts, and explicit card block-and-reissue tooling.", "evidenceIds": [ "lithic-docs-2", "lithic-docs-3", "lithic-docs-4", "lithic-docs-13", "lithic-docs-10", "lithic-docs-9" ] }, { "productId": "lithic", "storyId": "merchant-category-controls", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic's Authorization Rules v2 explicitly support controlling merchant categories (MCC) and can be applied at program/account/card level, with shadow-mode testing before enforcement (lithic-docs-3, lithic-docs-4, lithic-docs-11). However, the evidence never explicitly describes an MCC allowlist/blocklist distinction or a single-merchant lock feature. missing for 10: explicit allowlist vs blocklist configuration semantics, single-merchant lock capability, and independent confirmation these apply strictly at authorization time.", "evidenceIds": [ "lithic-docs-3", "lithic-docs-4", "lithic-docs-11", "lithic-docs-13" ] }, { "productId": "lithic", "storyId": "network-tokenization-visibility", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention network tokens, tokenization, wallet association, or token-specific revocation independent of the PAN; coverage is limited to cards, rules, disputes, and webhooks.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic's docs show a very extensive, API-first surface (cards, KYC, authorization rules with shadow-mode/backtesting, disputes, webhooks, spend limits, sandbox simulation) suggesting the API is the primary interface for core issuing operations, and an official MCP server lets AI agents call this API directly from an editor. However, there is no explicit documentation confirming 1:1 parity between the Lithic Dashboard UI and the API (e.g., admin/reporting features unique to the dashboard), and no OpenAPI spec was discoverable via probe. Missing for 10: explicit UI-vs-API parity statement, confirmation that all dashboard-only features (reporting, team management, etc.) are also API-exposed, and independent verification of parity.", "evidenceIds": [ "lithic-docs-3", "lithic-docs-4", "lithic-docs-8", "lithic-docs-9", "lithic-docs-6", "lithic-docs-5", "lithic-probe-3", "lithic-probe-2" ] }, { "productId": "lithic", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Lithic is a card-issuing/payments API platform that stores account, transaction, and card data, so a data-export/portability axis is plausible to ask, but nothing in the evidence pack shows any bulk export tool, open-format data dump, or account-closure data portability feature — only API endpoints for operational use (webhooks, disputes, rules, sandbox).", "evidenceIds": [] }, { "productId": "lithic", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a closed proprietary fintech/card-issuing API platform, not an open-source project; there's no indication its source code is published under any license. Source availability is not a fair axis for this kind of commercial financial API product.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a hosted card-issuing/payments API/SaaS platform, not open-source infrastructure meant to be self-hosted; self-hosting is a category error for this type of product.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "pci-scope-management", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions PAN/CVV reveal, hosted card components, ephemeral keys, or PCI SAQ D scope reduction; the pack covers card creation, ASA, rules, disputes, webhooks, and MCP tooling but nothing about cardholder-facing secure data display.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "physical-card-fulfillment", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm the core capability — creating physical cards via the API with `shipping_address` and `product_id` (card design) parameters — meaning ops doesn't need a separate manufacturer relationship. However, there is no evidence of bulk ordering, choice of shipping methods, or shipment tracking, which are explicit parts of the story. Missing for 10: bulk-order endpoints/docs, shipping method options, tracking/status endpoints for shipped cards.", "evidenceIds": [ "lithic-docs-9" ] }, { "productId": "lithic", "storyId": "pin-3ds-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card creation, spend limits, rules, disputes, webhooks, and simulation, but nowhere mentions PIN set/reset endpoints or 3DS enrollment/authentication flows for cardholders. Since Lithic is a card issuing API, this axis clearly applies, but no documentation or endpoint evidence supports it.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, region selection, or storage location controls for Lithic; all citations concern API functionality, cards, rules, and MCP integration, not data residency choices.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a card issuing/payments API platform, not an AI model provider or data-processing service where 'AI training data usage' opt-outs would apply; this privacy axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data retention policies, deletion of stored data/cardholder data, or AI-native controls over data lifecycle; the pack covers API mechanics, MCP integration, and card/authorization features but nothing about data retention/deletion controls.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Lithic is a card issuing/payments API platform, not an AI assistant or telemetry-collecting client tool; opting out of telemetry/usage tracking is not a relevant axis for this kind of product's evidence pack, which focuses on payment infrastructure APIs.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "program-launch-speed", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence shows Lithic handles several program-management functions (KYC bypass, authorization rules at program/account/card levels, disputes/chargeback filing, spend limits) that reduce the founder's compliance burden, but there is no explicit mention of BIN sponsorship or bank/network membership being abstracted away, and no documented timeline from signup to first live card. Missing for 10: explicit BIN sponsorship/network membership claims, a documented onboarding timeline, and independent confirmation of speed-to-launch.", "evidenceIds": [ "lithic-docs-3", "lithic-docs-8", "lithic-docs-10", "lithic-docs-13", "lithic-comm-2" ] }, { "productId": "lithic", "storyId": "realtime-auth-decisioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Lithic's Auth Stream Access (ASA) is documented as an HTTP POST-based real-time endpoint that must respond with an approval/decline decision during authorization [lithic-docs-2], directly matching the core of this story. However, the evidence pack does not document the specific time budget (latency window) or a configurable timeout fallback policy the developer controls, which the story explicitly requires. Missing for 10: documented response-time budget/SLA, explicit timeout fallback configuration options, and independent/hands-on confirmation of real-time behavior.", "evidenceIds": [ "lithic-docs-2" ] }, { "productId": "lithic", "storyId": "reconciliation-reporting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of settlement/reconciliation files, interchange/fee reporting APIs, or finance-stack-consumable reports in the provided documentation set; the pack covers auth rules, disputes, KYC, cards, webhooks, and MCP tooling but nothing on settlement reconciliation artifacts. This is a reasonable axis for a card-issuing platform, so absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "lithic", "storyId": "single-use-scoped-cards", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show card creation (virtual/physical) plus authorization rules and spend limits that can be scoped to card level, merchant category, and velocity/amount, which supports tight per-card restrictions (lithic-docs-9, lithic-docs-3, lithic-docs-13, lithic-docs-11). However, no explicit documentation of a 'single-use' card type or automatic one-time-use invalidation is present, only generic spend/authorization controls. Missing for 10: explicit single-use card mechanism, explicit exact-amount lock enforcement, and independent/hands-on confirmation that a leaked card number becomes unusable after one transaction.", "evidenceIds": [ "lithic-docs-9", "lithic-docs-3", "lithic-docs-13", "lithic-docs-11" ] }, { "productId": "lithic", "storyId": "spend-limits-velocity", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Lithic docs show spend limits at account/card level with daily/monthly/all-time windows (lithic-docs-13), plus Authorization Rules v2 enforcing velocity and transaction-count rules at program/account/card levels, entirely server-side (lithic-docs-3, lithic-docs-11). Blog and docs confirm platform-enforced velocity/limit checks during authorization, not client code. Missing for 10: no independent/hands-on third-party confirmation of exact windowing behavior beyond vendor docs.", "evidenceIds": [ "lithic-docs-13", "lithic-docs-3", "lithic-docs-11", "lithic-docs-4" ] }, { "productId": "lithic", "storyId": "virtual-card-creation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm a single API call (POST /cards) creates virtual cards and a sandbox environment exists for testing, supporting the core create-in-one-call claim, but no evidence explicitly confirms PAN/CVV/expiry are returned in the creation response or that moving from sandbox to live production requires no sales process. missing for 10: explicit documentation of PAN/CVV/expiry fields in the card creation response, and evidence of self-serve production activation without a sales cycle.", "evidenceIds": [ "lithic-docs-9", "lithic-docs-5" ] }, { "productId": "marqeta", "storyId": "agent-issued-cards", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13", "marqeta-docs-5", "marqeta-docs-6", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agent-manages-program", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13", "marqeta-docs-1", "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-7", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-2", "marqeta-probe-1", "marqeta-probe-2" ] }, { "productId": "marqeta", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13" ] }, { "productId": "marqeta", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-9", "marqeta-docs-4", "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-2", "marqeta-docs-10", "marqeta-docs-14" ] }, { "productId": "marqeta", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-12", "marqeta-docs-13", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-2", "marqeta-docs-3", "marqeta-docs-11" ] }, { "productId": "marqeta", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-2", "marqeta-docs-3", "marqeta-docs-7", "marqeta-docs-9", "marqeta-docs-10", "marqeta-docs-14", "marqeta-probe-3" ] }, { "productId": "marqeta", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-11", "marqeta-docs-13", "marqeta-probe-4" ] }, { "productId": "marqeta", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "marqeta-probe-1", "marqeta-probe-2", "marqeta-probe-3", "marqeta-docs-2", "marqeta-docs-14" ] }, { "productId": "marqeta", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-9" ] }, { "productId": "marqeta", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-2", "marqeta-docs-3", "marqeta-docs-10", "marqeta-docs-14", "marqeta-probe-3" ] }, { "productId": "marqeta", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct 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.", "evidenceIds": [ "marqeta-probe-3", "marqeta-probe-1", "marqeta-probe-2" ] }, { "productId": "marqeta", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-2", "marqeta-docs-10", "marqeta-docs-14", "marqeta-docs-11" ] }, { "productId": "marqeta", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "marqeta-probe-3", "marqeta-probe-1", "marqeta-probe-2" ] }, { "productId": "marqeta", "storyId": "auth-context-enrichment", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Evidence 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.", "evidenceIds": [ "marqeta-docs-7", "marqeta-docs-6", "marqeta-docs-5" ] }, { "productId": "marqeta", "storyId": "auth-simulation-testing", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs 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.", "evidenceIds": [ "marqeta-docs-10", "marqeta-docs-14", "marqeta-docs-7", "marqeta-docs-8", "marqeta-docs-2" ] }, { "productId": "marqeta", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-11", "marqeta-docs-12" ] }, { "productId": "marqeta", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-4", "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-9" ] }, { "productId": "marqeta", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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).", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "balance-ledger-visibility", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-4", "marqeta-docs-7", "marqeta-docs-8", "marqeta-docs-9" ] }, { "productId": "marqeta", "storyId": "card-state-management", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-10", "marqeta-docs-14" ] }, { "productId": "marqeta", "storyId": "cardholder-kyc", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "clearing-settlement-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-9", "marqeta-docs-7", "marqeta-docs-8", "marqeta-docs-10" ] }, { "productId": "marqeta", "storyId": "credit-debit-prepaid-range", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-14", "marqeta-docs-18" ] }, { "productId": "marqeta", "storyId": "digital-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "dispute-filing-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-8", "marqeta-docs-9", "marqeta-docs-7" ] }, { "productId": "marqeta", "storyId": "funding-model-flexibility", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "JIT 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.", "evidenceIds": [ "marqeta-docs-4" ] }, { "productId": "marqeta", "storyId": "issuing-fraud-controls", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-7", "marqeta-docs-8", "marqeta-docs-9" ] }, { "productId": "marqeta", "storyId": "merchant-category-controls", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-6", "marqeta-docs-13", "marqeta-docs-5" ] }, { "productId": "marqeta", "storyId": "network-tokenization-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-7", "marqeta-docs-8", "marqeta-docs-9", "marqeta-docs-15", "marqeta-docs-16", "marqeta-docs-17", "marqeta-probe-3" ] }, { "productId": "marqeta", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Marqeta 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.", "evidenceIds": [ "marqeta-probe-1", "marqeta-probe-2", "marqeta-probe-3", "marqeta-docs-7" ] }, { "productId": "marqeta", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "pci-scope-management", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The 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.", "evidenceIds": [ "marqeta-docs-17" ] }, { "productId": "marqeta", "storyId": "physical-card-fulfillment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-12", "marqeta-docs-14" ] }, { "productId": "marqeta", "storyId": "pin-3ds-management", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The 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.", "evidenceIds": [ "marqeta-docs-17" ] }, { "productId": "marqeta", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Marqeta 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "program-launch-speed", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-8", "marqeta-docs-9", "marqeta-docs-14" ] }, { "productId": "marqeta", "storyId": "realtime-auth-decisioning", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-4", "marqeta-docs-9" ] }, { "productId": "marqeta", "storyId": "reconciliation-reporting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence 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.", "evidenceIds": [] }, { "productId": "marqeta", "storyId": "single-use-scoped-cards", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-4", "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-12", "marqeta-docs-13" ] }, { "productId": "marqeta", "storyId": "spend-limits-velocity", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Marqeta'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.", "evidenceIds": [ "marqeta-docs-5", "marqeta-docs-6", "marqeta-docs-13" ] }, { "productId": "marqeta", "storyId": "virtual-card-creation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs 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.", "evidenceIds": [ "marqeta-docs-1", "marqeta-docs-2", "marqeta-docs-12", "marqeta-docs-14", "marqeta-docs-16" ] }, { "productId": "stripe-issuing", "storyId": "agent-issued-cards", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe documents a dedicated agents.md page describing virtual cards scoped to a single task/session that auto-invalidate after use, combined with spending controls (merchant category/ID/country locks, per-authorization/monthly amount caps) and real-time authorization webhooks, directly matching the story's named use case. missing for 10: independent/hands-on third-party corroboration of the agent-specific card flow (only vendor docs cited), and no explicit example of setting card expiry alongside merchant locks in a single documented workflow.", "evidenceIds": [ "stripe-issuing-docs-12", "stripe-issuing-docs-13", "stripe-issuing-docs-5", "stripe-issuing-docs-4", "stripe-issuing-docs-1" ] }, { "productId": "stripe-issuing", "storyId": "agent-manages-program", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Issuing offers full API coverage for card/cardholder creation, spend controls, and an agents-specific doc describing task-scoped single-use virtual cards with ML risk scoring, plus a documented official MCP server. However, the evidence doesn't show the MCP server exposing Issuing-specific tools (balances, transactions, card/spend-control management) or confirm scoped/limited credentials for agent use via MCP rather than just full API keys. missing for 10: evidence of MCP server exposing Issuing read/write tools (balances, transactions, card updates, spend control adjustments), and evidence of scoped/restricted API keys for agent use.", "evidenceIds": [ "stripe-issuing-docs-12", "stripe-issuing-docs-13", "stripe-issuing-docs-5", "stripe-issuing-docs-16", "stripe-issuing-probe-4" ] }, { "productId": "stripe-issuing", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's docs.stripe.com/llms.txt returns HTTP 200 and .md variants of docs pages (e.g., issuing.md, mcp.md) are directly accessible, confirming agent-oriented documentation formats exist and are served for Issuing docs. There's also an official MCP server for AI agents to interact with the Stripe API. missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully for Issuing-specific tasks, and no explicit Issuing-specific llms.txt (only the site-wide one).", "evidenceIds": [ "stripe-issuing-probe-1", "stripe-issuing-probe-2", "stripe-issuing-docs-16", "stripe-issuing-probe-4" ] }, { "productId": "stripe-issuing", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs mention machine-learning-generated risk scores (fraud, dispute risk, card testing) surfaced on every authorization, which is a narrow form of AI-generated insight from transaction data, but there's no evidence of broader in-product AI insights/suggestions (e.g., spend analytics, natural-language querying, dashboard copilot) beyond this fraud-risk scoring. Missing for 10: evidence of general AI-generated insights/suggestions across spending data, dashboard-level AI summaries, or proactive recommendations beyond fraud risk scoring.", "evidenceIds": [ "stripe-issuing-docs-13" ] }, { "productId": "stripe-issuing", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe Issuing exposes real-time authorization webhooks, spending controls, and agent-specific virtual cards that auto-invalidate after a task/session (docs-4, docs-5, docs-12, docs-13), enabling autonomous, unattended card issuance and approval flows. It also ships an official MCP server so AI agents can drive the Issuing API programmatically (docs-16, probe-4), supporting background automation setups. Missing for 10: independent/hands-on evidence of a fully autonomous end-to-end automation running in production, and more detail on scheduling/orchestration beyond webhook-triggered decisions.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-docs-12", "stripe-issuing-docs-13", "stripe-issuing-docs-16", "stripe-issuing-probe-4" ] }, { "productId": "stripe-issuing", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a card-issuing API/platform, not an AI agent product with a built-in assistant UI to delegate tasks to; it does offer an MCP server for external agents to call it, but that's a different axis (agent enablement, not an in-product assistant). No evidence of a built-in AI assistant that users delegate tasks to within Stripe Issuing itself.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Issuing exposes a complete REST API for creating cards/cardholders, real-time authorization webhooks, and a documented test-simulation mode for pre-production automation, plus an official CLI (stripe-cli) — all consistent with headless/CI operation. Community evidence confirms real-world usage of the API for automated QA workflows. missing for 10: explicit CI/pipeline integration guides or SDK examples showing scripted deployment in CI systems.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-docs-4", "stripe-issuing-docs-10", "stripe-issuing-probe-5", "stripe-issuing-comm-1" ] }, { "productId": "stripe-issuing", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a card-issuing API/platform, not an agent runtime or assistant that itself consumes external MCP servers as a client; the evidence instead shows Stripe exposing its own MCP server so that AI agents can call Issuing's tools, which is the reverse (server) role and a separate story.", "evidenceIds": [ "stripe-issuing-docs-16", "stripe-issuing-probe-4" ] }, { "productId": "stripe-issuing", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe documents an official MCP server that lets AI agents interact with the Stripe API (which includes Issuing endpoints) and search its knowledge base, confirmed by both docs and a probe hit at docs.stripe.com/mcp. However, the evidence doesn't detail Issuing-specific MCP tools or independent hands-on confirmation of agent usage with Issuing specifically. Missing for 10: explicit list of Issuing-specific MCP tool calls, independent/community verification of agent integration.", "evidenceIds": [ "stripe-issuing-docs-16", "stripe-issuing-probe-4" ] }, { "productId": "stripe-issuing", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe documents an official MCP server that lets AI agents interact with the Stripe API (including Issuing) via natural-language-driven tool calls, and separately markets Issuing itself for agentic/AI-driven card issuance. However there's no hands-on evidence of natural-language command execution specifically against Issuing endpoints, and the CLI (a non-NL surface) is the only other control surface mentioned. Missing for 10: independent/hands-on proof of NL commands operating Issuing resources, documentation of MCP tool coverage for Issuing-specific actions.", "evidenceIds": [ "stripe-issuing-docs-16", "stripe-issuing-probe-4", "stripe-issuing-docs-12", "stripe-issuing-docs-13" ] }, { "productId": "stripe-issuing", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe documents an official CLI (stripe-issuing-probe-5) as part of the broader Stripe platform, which would apply to Issuing API usage, but the evidence pack contains no Issuing-specific CLI commands, examples, or independent hands-on confirmation of CLI use for Issuing workflows. missing for 10: Issuing-specific CLI command examples, hands-on/community confirmation of using the CLI for Issuing tasks, documentation tying the CLI explicitly to agentic/AI-native workflows.", "evidenceIds": [ "stripe-issuing-probe-5" ] }, { "productId": "stripe-issuing", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Issuing exposes a comprehensive, well-documented REST API covering cards, cardholders, webhooks, disputes, spending controls, and funding, plus an official CLI and MCP server for programmatic/agentic access, corroborated by a live probe of docs and community reports of API-driven automation. missing for 10: a directly reachable machine-readable OpenAPI spec (probe returned 404 on standard paths).", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-docs-4", "stripe-issuing-docs-11", "stripe-issuing-probe-1", "stripe-issuing-probe-2", "stripe-issuing-probe-3", "stripe-issuing-probe-4", "stripe-issuing-probe-5", "stripe-issuing-comm-1" ] }, { "productId": "stripe-issuing", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Issuing has a dedicated agents doc describing issuing virtual cards scoped to a single task/session that auto-invalidate after use, plus fine-grained spending controls (merchant category, country, amount limits) and real-time authorization webhooks that let an issuer approve/decline per-transaction — together these constitute least-privilege, scoped credential issuance for agentic use. missing for 10: independent/hands-on third-party validation of the agent-scoping feature specifically (only vendor docs), and no evidence of programmatic revocation/audit-trail APIs tailored to agent credential lifecycle beyond card invalidation.", "evidenceIds": [ "stripe-issuing-docs-12", "stripe-issuing-docs-13", "stripe-issuing-docs-5", "stripe-issuing-docs-4", "stripe-issuing-docs-3" ] }, { "productId": "stripe-issuing", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's docs reference the Issuing API and general Stripe SDK/CLI/MCP infrastructure, implying official SDKs exist for building Issuing integrations, but the evidence pack contains no direct mention of language-specific SDK libraries (e.g., stripe-node, stripe-python) or their coverage of Issuing endpoints specifically. missing for 10: explicit documentation of official SDK libraries and language coverage for Issuing, code samples showing SDK usage for Issuing objects, independent developer corroboration of SDK quality for Issuing specifically.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-probe-2", "stripe-issuing-probe-5", "stripe-issuing-comm-1" ] }, { "productId": "stripe-issuing", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm Issuing supports a synchronous webhook for real-time authorization decisions, showing webhook-based event delivery exists, but the pack contains no evidence of broader webhook event subscription (e.g., issuing_card.*, issuing_dispute.* events, webhook endpoint management API) that a general 'subscribe to events' story implies. Missing for 10: documentation of the full Issuing webhook event catalog, webhook endpoint setup/management API, and any AI-native tooling (e.g. MCP) for consuming these events.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-5" ] }, { "productId": "stripe-issuing", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The evidence pack shows Stripe publishes detailed API reference pages for Issuing endpoints (cards, cardholders, etc.) and markdown-accessible docs, but nothing explicitly confirms an interactive, runnable-example experience (e.g., live code sandboxes or in-browser request execution) — the OpenAPI spec probe even returned 404s. Missing for 10: explicit documentation or demonstration of runnable/interactive code snippets, live API console, or sandboxed example execution within the reference pages.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-probe-2", "stripe-issuing-probe-3" ] }, { "productId": "stripe-issuing", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows explicit probing for OpenAPI/Swagger spec endpoints on docs.stripe.com all returned 404, and no other citation confirms a downloadable OpenAPI or equivalent machine-readable spec; only markdown docs and llms.txt are shown to work.", "evidenceIds": [ "stripe-issuing-probe-3", "stripe-issuing-probe-1", "stripe-issuing-probe-2" ] }, { "productId": "stripe-issuing", "storyId": "api-sandbox", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly mention simulating test purchases before going live, and community evidence shows a user relying on the API for QA/test automation, supporting a sandbox-style workflow. However, there's no detailed documentation of Stripe's standard test-mode/live-mode key separation or confirmation that all Issuing features (card issuance, authorizations) work identically in test mode without any production side-effects. missing for 10: explicit test-mode vs live-mode API key documentation, hands-on confirmation of full feature parity in test mode, independent verification of sandbox fidelity.", "evidenceIds": [ "stripe-issuing-docs-10", "stripe-issuing-comm-1" ] }, { "productId": "stripe-issuing", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Issuing features (cards, cardholders, controls, agents, MCP) but contains no documentation of API versioning scheme or a deprecation policy. Missing for 10: any docs page or changelog describing dated API versions, backward-compatibility guarantees, or deprecation timelines.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "auth-context-enrichment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers real-time authorization webhooks, spending controls (merchant category, MID), risk scores, and wallet support, but there is no evidence that Stripe surfaces MCC codes, enhanced merchant data, wallet/entry-mode details, or partial-approval/incremental-auth signals within the authorization payload itself. Missing for 10: explicit documentation of MCC field, enhanced merchant metadata, wallet/entry-mode indicators, and partial-approval/incremental-auth signal support in the authorization object.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-docs-13", "stripe-issuing-docs-6" ] }, { "productId": "stripe-issuing", "storyId": "auth-simulation-testing", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm a sandbox/test mode exists (\"Simulate test purchases before going live\") and separately describe real-time authorization webhooks and spending-control declines, which together imply some lifecycle testing capability. However, no evidence explicitly documents simulating clearings, reversals, or refunds in the test environment, only authorizations/purchases and controls-based declines. Missing for 10: explicit documentation/tooling for simulating clearing, reversal, and refund events in sandbox, and any independent/hands-on confirmation that the full lifecycle can be tested end-to-end.", "evidenceIds": [ "stripe-issuing-docs-10", "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-probe-2" ] }, { "productId": "stripe-issuing", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Stripe Issuing's documented API only shows single-resource create endpoints for cards and cardholders, with no evidence of batch/bulk endpoints or documented patterns for issuing or managing many cards/cardholders in one call. While an API-driven product could plausibly support bulk automation, the evidence pack contains nothing about batch operations, bulk imports, or multi-item API calls.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Issuing supports rule-like automation via spending controls (block by MCC, country, merchant ID, card presence, spending limits) and synchronous webhooks that programmatically approve/decline authorizations in real time, which is a form of event-triggered automated action. However, this is scoped narrowly to authorization events rather than a general-purpose rule engine for arbitrary triggers/actions across the product. Missing for 10: evidence of a broader declarative rules/automation framework beyond authorization controls, and independent/hands-on validation of custom rule logic in production.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-docs-13" ] }, { "productId": "stripe-issuing", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card creation, spending controls, disputes, and real-time authorization webhooks, but nothing describes a scheduling or recurring-job/workflow automation feature (e.g., cron-like triggers, scheduled disbursements, or workflow orchestration) for AI-native users.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a card-issuing API, not an automation/workflow-building tool; versioning, reviewing, and rolling back 'automations' is not a concept this product category addresses (it has no automation/workflow builder to version or roll back).", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "balance-ledger-visibility", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs show real-time authorization webhooks, funding balance/bank details, and dispute handling, implying underlying ledger and clearing mechanics, but there is no explicit documentation of a transaction ledger that ties authorizations to clearing or of settlement reporting that reconciles to the penny. Missing for 10: dedicated ledger/transaction API description, settlement reporting/reconciliation tools, and evidence of penny-accurate reconciliation.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-9", "stripe-issuing-docs-11" ] }, { "productId": "stripe-issuing", "storyId": "card-state-management", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm card creation, cardholder creation, and replacement of lost/stolen/expired/damaged cards via API (docs-1, docs-3, docs-7), which covers reissue-with-replacement-link and lost/stolen reporting in spirit, but the evidence pack never explicitly documents API calls for activating, pausing/unpausing a card's status, or permanently closing a card. missing for 10: explicit API docs for activate/pause/unpause status transitions, explicit 'permanently close' endpoint, and confirmation that the replacement card is API-linked to the original card object.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-docs-7" ] }, { "productId": "stripe-issuing", "storyId": "cardholder-kyc", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card creation, cardholder objects, spending controls, disputes, and agent-scoped virtual cards, but contains no documentation of KYC/KYB data requirements, cardholder verification review states, or re-verification workflows. Cardholder identity verification is a plausible and expected axis for a card-issuing platform, so absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "stripe-issuing-docs-3" ] }, { "productId": "stripe-issuing", "storyId": "clearing-settlement-events", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs mention a synchronous webhook for real-time authorization decisions and a separate API/dashboard flow for disputes, implying some post-auth event handling, but the pack never documents webhook events for clearings, refunds, or reversals, nor stable transaction identifiers for ledger reconciliation. Missing for 10: explicit webhook events for captures/refunds/reversals, documentation of a Transaction object with stable IDs, and confirmation that disputes/chargebacks are delivered via webhook rather than only dashboard/API polling.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-11" ] }, { "productId": "stripe-issuing", "storyId": "credit-debit-prepaid-range", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers card creation, controls, funding, and network partnerships but never specifies which underlying program types (debit, prepaid, commercial credit, consumer credit) Stripe Issuing supports — the only hint is a truncated snippet ('Commercial iss...') that provides no substantive detail. Missing for 10: explicit documentation distinguishing prepaid vs. debit vs. commercial credit vs. consumer credit program support, eligibility/underwriting differences, or customer examples confirming multiple program types in production.", "evidenceIds": [ "stripe-issuing-probe-2" ] }, { "productId": "stripe-issuing", "storyId": "digital-wallet-provisioning", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs confirm cards can be added to Apple Pay, Google Pay, and Samsung Pay and that physical card art/customization and replacement (manual provisioning fallback) exist, but there is no documentation of the push provisioning API/SDK flow, entitlements process, or in-app provisioning implementation details a developer would need. missing for 10: push provisioning API/SDK documentation, entitlements process details, in-wallet card art specification, independent/hands-on confirmation of the provisioning flow.", "evidenceIds": [ "stripe-issuing-docs-6", "stripe-issuing-docs-7", "stripe-issuing-docs-8" ] }, { "productId": "stripe-issuing", "storyId": "dispute-filing-api", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe confirms an API + Dashboard flow to submit and monitor Issuing disputes through resolution, but the evidence pack gives no detail on network reason codes, evidence submission fields, provisional credit handling, or dispute-specific status webhooks. Missing for 10: reason-code taxonomy documentation, evidence-submission API specifics, provisional credit mechanics, and dispute webhook event examples.", "evidenceIds": [ "stripe-issuing-docs-11" ] }, { "productId": "stripe-issuing", "storyId": "funding-model-flexibility", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe Issuing documents a balance-based (prefunded) funding model where finance pushes funds from an external bank account (stripe-issuing-docs-9), and separately documents real-time authorization webhooks that let a system approve/decline each authorization synchronously, which is the core of just-in-time funding control (stripe-issuing-docs-4). However, the evidence never explicitly frames these as two alternative 'prefunded vs JIT' funding models nor discusses the cash-flow tradeoffs between them. Missing for 10: explicit documentation contrasting prefunded balance funding vs JIT funding as named options, and cash-flow tradeoff guidance for finance leads.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-9" ] }, { "productId": "stripe-issuing", "storyId": "issuing-fraud-controls", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show real-time authorization webhooks for approve/decline, ML-generated risk scores (fraud risk, merchant dispute risk, card testing detection) surfaced at authorization, spending controls to block merchant categories/countries, and replacement-card issuance for lost/stolen/damaged cards, plus a dispute workflow. However, there is no explicit documentation of a dedicated suspicious-activity alerting/notification system for ops, nor clear card-level 'freeze/block' tooling distinct from spending controls. missing for 10: explicit suspicious-activity alert mechanism, explicit card status/block (vs. reissue) API evidence, independent/hands-on corroboration of fraud-score accuracy.", "evidenceIds": [ "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-docs-7", "stripe-issuing-docs-11", "stripe-issuing-docs-13" ] }, { "productId": "stripe-issuing", "storyId": "merchant-category-controls", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm spending controls can block by merchant category (MCC) and merchant IDs (single-merchant lock) applied via authorization-time controls, and real-time webhook authorization confirms enforcement at auth time. However, the evidence does not explicitly confirm an 'allowlist' mode (only 'block' is described) nor detail how single-merchant locking works beyond blocking by merchant ID, leaving allowlist behavior unproven. missing for 10: explicit allowlist (allow-only) MCC configuration, explicit documentation of single-merchant lock as a distinct feature, independent/hands-on verification of authorization-time enforcement.", "evidenceIds": [ "stripe-issuing-docs-5", "stripe-issuing-docs-4" ] }, { "productId": "stripe-issuing", "storyId": "network-tokenization-visibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows that cards can be added to digital wallets (Apple Pay/Google Pay/Samsung Pay) but nothing about a distinct network-token object, listing which wallet/merchant holds a token, or revoking a token independently of the underlying PAN. Missing for 10: token object/API reference, wallet/merchant attribution per token, token-level revocation endpoint or dashboard control.", "evidenceIds": [ "stripe-issuing-docs-6" ] }, { "productId": "stripe-issuing", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe Issuing is API-first: cards, cardholders, spending controls, disputes, funding, and even agent-specific ephemeral virtual cards are all documented as API operations, and community evidence confirms teams building entirely on the API. However, some dashboard-only conveniences (physical card design/appearance configuration, guided dispute UX, some Connect platform setup flows) are described primarily through the Dashboard with API as a secondary/parallel path, and there's no independent audit confirming 1:1 parity between UI and API surface area. missing for 10: independent verification of full UI/API parity, explicit API equivalents for all dashboard-guided workflows (e.g., card design/appearance, guided dispute UI), and a published OpenAPI spec (probe found only 404s).", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-docs-4", "stripe-issuing-docs-5", "stripe-issuing-docs-9", "stripe-issuing-docs-11", "stripe-issuing-docs-12", "stripe-issuing-docs-15", "stripe-issuing-comm-1", "stripe-issuing-probe-3" ] }, { "productId": "stripe-issuing", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a data export/portability feature or open-format export mechanism for Stripe Issuing account data; the API allows retrieving records via API calls but there's no documented bulk export tool or open-format data portability guarantee for users to 'take their data and leave'.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a closed proprietary SaaS/API product for card issuing, not open-source software; there is no source code to read under any license. This axis applies to open-source projects, not to a commercial financial API service — category error.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a regulated financial/card-issuing SaaS platform tied to banking partners and card networks; self-hosting the core product is a category error, not an applicable capability.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "pci-scope-management", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers card creation, controls, disputes, funding, and agent-scoped virtual cards, but contains no mention of PAN/CVV reveal UI, hosted Elements components, or ephemeral key issuance for reducing PCI SAQ D scope. Missing for 10: documentation of hosted card reveal components (e.g., Stripe Elements 'Issuing Elements'), ephemeral key generation for PAN/CVV display, and explicit PCI SAQ A/D scope-reduction claims.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "physical-card-fulfillment", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm API-driven physical card issuance with custom card art/logo (docs-1, docs-2, docs-8) and Stripe handles printing/shipping without an ops-managed manufacturer relationship, plus replacement cards for lost/damaged/stolen (docs-7). However, there is no explicit evidence of bulk ordering workflows, choice of shipping methods, or shipment tracking details in the API. Missing for 10: bulk order API/batch issuance evidence, shipping method selection, and tracking number/status documentation.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-2", "stripe-issuing-docs-8", "stripe-issuing-docs-7" ] }, { "productId": "stripe-issuing", "storyId": "pin-3ds-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card/cardholder creation, spending controls, wallets, disputes, and replacement cards, but contains no mention of PIN set/reset APIs or 3DS enrollment flows, which are a plausible and expected capability for a card-issuing API. Absence of evidence for this applicable axis means it cannot be credited.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency or region selection for Stripe Issuing data; nothing discusses where card/cardholder data is stored or regional data controls.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a card-issuing/payments API product, not an AI model or AI training data pipeline; controlling whether user data trains AI models is a category error for this axis.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card issuance, spending controls, disputes, and agent-scoped virtual cards, but contains no mention of data retention policies, data deletion APIs, or privacy controls for cardholder/transaction data. Card auto-invalidation (docs-12) is about card lifecycle, not data retention/deletion of stored information, so it doesn't satisfy this axis.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Issuing is a card-issuing API/platform, not an AI agent or developer tool with client-side telemetry to opt out of; telemetry opt-out is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "program-launch-speed", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show Stripe handles cardholder/card creation, network partnerships (Mastercard/Visa), controls, funding, and disputes — all evidence that program management, network membership, and card issuance mechanics are Stripe's responsibility, not the founder's. However, there is no explicit documentation of BIN sponsorship terminology or a stated timeline from signup to first live card. Missing for 10: explicit 'no bank charter/BIN sponsorship' framing, and a documented signup-to-first-live-card timeframe or onboarding SLA.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-3", "stripe-issuing-docs-14", "stripe-issuing-docs-9", "stripe-issuing-docs-11", "stripe-issuing-probe-2" ] }, { "productId": "stripe-issuing", "storyId": "realtime-auth-decisioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Issuing explicitly documents a synchronous webhook for real-time authorization approve/decline decisions, matching the core of the story. However, the evidence pack does not show documentation of the exact timeout window or how developers can configure/control the fallback (approve/decline) behavior when their endpoint doesn't respond in time. Missing for 10: explicit timeout budget details, developer-configurable fallback decision, and independent/hands-on confirmation of real-time latency behavior.", "evidenceIds": [ "stripe-issuing-docs-4" ] }, { "productId": "stripe-issuing", "storyId": "reconciliation-reporting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers card creation, controls, disputes, funding, and agent-specific virtual cards, but contains no mention of settlement files, interchange/fee reporting, or reconciliation report APIs that a finance stack could consume. Missing for 10: any documentation of daily settlement/report files, interchange or fee breakdowns, or reconciliation API endpoints.", "evidenceIds": [] }, { "productId": "stripe-issuing", "storyId": "single-use-scoped-cards", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Issuing supports single-use virtual cards scoped to a task/session that auto-invalidate after use, plus per-authorization spending controls (exact amount, merchant category, merchant ID, single presence) to tightly scope a card to one purchase/merchant. missing for 10: no independent/hands-on corroboration of single-use card behavior beyond docs, and no explicit example combining exact-amount + single-merchant lock in one workflow.", "evidenceIds": [ "stripe-issuing-docs-5", "stripe-issuing-docs-12", "stripe-issuing-docs-4" ] }, { "productId": "stripe-issuing", "storyId": "spend-limits-velocity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm platform-enforced spending controls (merchant category/country/MID/card-presence blocks) and spending limits, but only mention 'per authorization or per month' intervals — no explicit mention of daily or all-time windows, transaction-count velocity rules, or per-cardholder (vs per-card) limit distinctions. Real-time authorization webhook (docs-4) supports enforcement flow but isn't itself the velocity/amount-cap mechanism. missing for 10: daily/all-time window support, transaction-count velocity rules, explicit per-cardholder vs per-card scoping detail.", "evidenceIds": [ "stripe-issuing-docs-5", "stripe-issuing-docs-4", "stripe-issuing-probe-2" ] }, { "productId": "stripe-issuing", "storyId": "virtual-card-creation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm a single API call creates an Issuing Card object and that sandbox-mode purchase simulation exists before going live, supporting the core lifecycle claim. However, the evidence pack never explicitly confirms that PAN, CVV, and expiry are returned/retrievable programmatically at issuance, nor does it document that moving from test to live mode requires no approval or sales process (Issuing often needs business verification). missing for 10: explicit API field/endpoint returning PAN+CVV+expiry, documentation of frictionless sandbox-to-live activation without account review.", "evidenceIds": [ "stripe-issuing-docs-1", "stripe-issuing-docs-10", "stripe-issuing-probe-2" ] } ]