Rank #3 of 5 in Card Issuing Platforms
Access
Install
npm install @highnoteplatform/card-viewerTry itExperimental
See what an agent can do with Highnote before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si -X POST https://api.us.test.highnote.com/graphql -H 'Content-Type: application/json' -d '{"query":"{ ping }"}' # keyless → 401recorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Auth decisioning — stories about auth decisioning in this arenaAuth decisioningevidence →
Stories about auth decisioning in this arena
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Card lifecycle — stories about card lifecycle in this arenaCard lifecycleevidence →
Stories about card lifecycle in this arena
Issuing agent access — stories about issuing agent access in this arenaIssuing agent accessevidence →
Stories about issuing agent access in this arena
Issuing compliance — stories about issuing compliance in this arenaIssuing complianceevidence →
Stories about issuing compliance in this arena
Issuing disputes — stories about issuing disputes in this arenaIssuing disputesevidence →
Stories about issuing disputes in this arena
Ledger settlement — stories about ledger settlement in this arenaLedger settlementevidence →
Stories about ledger settlement in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
n/a
Program management — stories about program management in this arenaProgram managementevidence →
Stories about program management in this arena
Spend controls — stories about spend controls in this arenaSpend controlsevidence →
Stories about spend controls in this arena
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenizationevidence →
Stories about wallets tokenization in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Highnote stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Scoped API keys · MCP server · Machine-readable spec · Versioning policy · Official CLI
Subscribe to events via webhooks
✓8/10
Build against official SDKs
~6/10
Issue scoped/least-privilege API credentials for an agent
—–
Connect an agent via an official MCP server
—0/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
✓8/10
Explore an interactive API reference with runnable examples
~5/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
✓9/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
n/an/a
Operate the product with natural-language commands
—0/10
Plug MCP servers into this product so it can use their tools
n/an/a
Get AI-generated insights and suggestions from my data inside the product
—–
Set up automations that run autonomously in the background
~6/10
Auth decisioning — stories about auth decisioning in this arenaAuth decisioning
Stories about auth decisioning in this arena
Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals
~3/10
Approve or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control
~6/10
Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes
~6/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Card lifecycle — stories about card lifecycle in this arenaCard lifecycle
Stories about card lifecycle in this arena
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
~3/10
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
~3/10
Create a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cycle
~5/10
Issuing agent access — stories about issuing agent access in this arenaIssuing agent access
Stories about issuing agent access in this arena
Give an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name
✓8/10
An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials
~5/10
Issuing compliance — stories about issuing compliance in this arenaIssuing compliance
Stories about issuing compliance in this arena
Cardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows
~6/10
Show cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D
~6/10
Issuing disputes — stories about issuing disputes in this arenaIssuing disputes
Stories about issuing disputes in this arena
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution
~3/10
The platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cards
~4/10
Ledger settlement — stories about ledger settlement in this arenaLedger settlement
Stories about ledger settlement in this arena
See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny
~6/10
I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically
~4/10
Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts
~6/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Program management — stories about program management in this arenaProgram management
Stories about program management in this arena
The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail
~3/10
Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented
~5/10
Launch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented
~5/10
Spend controls — stories about spend controls in this arenaSpend controls
Stories about spend controls in this arena
Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code
✓8/10
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
~7/10
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
✓8/10
Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization
Stories about wallets tokenization in this arena
Cardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets
—–
Network tokens are first-class — I can see and manage the tokens created for a card, know which wallet or merchant holds them, and revoke them independently of the PAN
—0/10
Cards land in Apple Pay and Google Pay — push provisioning from my app with the entitlements process documented, plus in-wallet card art and manual provisioning as a fallback
—–
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Cclaimed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Cclaimed | |
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Tprobed | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | full | 8/10 | Cclaimed | |
Give an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name C Agent cards | ai-native user | Issuing agent access — stories about issuing agent access in this arenaIssuing agent access | 3 | full | 8/10 | Cclaimed | |
Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code C Limits | ops user | Spend controls — stories about spend controls in this arenaSpend controls | 3 | full | 8/10 | Cclaimed | |
Approve or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control C Auth stream | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 3 | partial | 6/10 | Cclaimed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 6/10 | Cclaimed | |
See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny C Balances | finance lead | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 3 | partial | 6/10 | Cclaimed | |
Create a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cycle C Virtual cards | developer | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 3 | partial | 5/10 | Cclaimed | |
Launch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented C Program launch | founder | Program management — stories about program management in this arenaProgram management | 3 | partial | 5/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used C Scoped cards | developer | Spend controls — stories about spend controls in this arenaSpend controls | 2 | full | 8/10 | Cclaimed | |
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time C Merchant controls | ops user | Spend controls — stories about spend controls in this arenaSpend controls | 2 | partial | 7/10 | Cclaimed | |
Cardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows C Kyc | ops user | Issuing compliance — stories about issuing compliance in this arenaIssuing compliance | 2 | partial | 6/10 | Cclaimed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 6/10 | Tprobed | |
Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts C Settlement events | developer | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 2 | partial | 6/10 | Cclaimed | |
Show cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D C Pci scope | developer | Issuing compliance — stories about issuing compliance in this arenaIssuing compliance | 2 | partial | 6/10 | Cclaimed | |
Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes C Simulation | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 2 | partial | 6/10 | Cclaimed | |
An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials C Agent operations | ai-native user | Issuing agent access — stories about issuing agent access in this arenaIssuing agent access | 2 | partial | 5/10 | Tprobed | |
Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented C Funding models | finance lead | Program management — stories about program management in this arenaProgram management | 2 | partial | 5/10 | Cclaimed | |
I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically C Recon reports | finance lead | Ledger settlement — stories about ledger settlement in this arenaLedger settlement | 2 | partial | 4/10 | Cclaimed | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 4/10 | Cclaimed | |
The platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cards C Fraud monitoring | ops user | Issuing disputes — stories about issuing disputes in this arenaIssuing disputes | 2 | partial | 4/10 | Cclaimed | |
Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals C Auth context | developer | Auth decisioning — stories about auth decisioning in this arenaAuth decisioning | 2 | partial | 3/10 | Cclaimed | |
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution C Dispute filing | ops user | Issuing disputes — stories about issuing disputes in this arenaIssuing disputes | 2 | partial | 3/10 | Cclaimed | |
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself C Physical cards | ops user | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 2 | partial | 3/10 | Cclaimed | |
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close C Lifecycle states | developer | Card lifecycle — stories about card lifecycle in this arenaCard lifecycle | 2 | partial | 3/10 | Cclaimed | |
The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail C Card types | founder | Program management — stories about program management in this arenaProgram management | 2 | partial | 3/10 | Cclaimed | |
Network tokens are first-class — I can see and manage the tokens created for a card, know which wallet or merchant holds them, and revoke them independently of the PAN C Tokenization | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | 0/10 | ||
Cardholder credentials are manageable through the API — PIN set and reset flows, 3DS enrollment for online use where the region requires it — without support tickets C Credentials | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | untested | none yet | |
Cards land in Apple Pay and Google Pay — push provisioning from my app with the entitlements process documented, plus in-wallet card art and manual provisioning as a fallback C Wallet provisioning | developer | Wallets tokenization — stories about wallets tokenization in this arenaWallets tokenization | 2 | none | untested | none yet | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | untested | none yet | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | n/a | untested | none yet | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | n/a | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 35 stories with headroom
What would move Highnote’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productConnect an agent via an official MCP server
nonemoves agent-readyimpact 45
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.
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
nonemoves Built-in AIimpact 30
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".
Agenticness — how well agents can access and operate the productOperate the product with natural-language commands
nonemoves Built-in AIimpact 30
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.
Agenticness — how well agents can access and operate the productUse an official CLI
nonemoves agent-readyimpact 30
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".
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
Missing: 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.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
Missing: a published OpenAPI/GraphQL schema file, a documented download/export endpoint, any mention of schema introspection support.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
nonemoves API qualityimpact 30
Missing: versioning scheme documentation, deprecation/sunset policy, changelog or migration guides.
Wallets tokenization — stories about wallets tokenization in this arenaCards land in Apple Pay and Google Pay — push provisioning from my app with the entitlements process documented, plus in-wallet card art and manual provisioning as a fallback
nonemoves PA Scoreimpact 20
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.
Showing the top 8 of 35 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map6 surfaces · 32 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs30 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Build against official SDKs
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Explore an interactive API reference with runnable examples
- Test against a sandbox environment without touching production data
- Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signals
- Approve or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control
- Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes
- Define rules that trigger actions automatically on events
- The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
- Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myself
- Create a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cycle
- Give an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name
- An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials
- Cardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flows
- Show cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D
- File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolution
- The platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cards
- See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny
- I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically
- Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts
- Do everything through the API that I can do in the UI
- The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail
- Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented
- Launch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented
- Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code
- Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
- Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
Solutions docs16 stories
- Point an agent at llms.txt or agent-oriented docs
- Drive the product through a documented public API
- Set up automations that run autonomously in the background
- Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipes
- Perform bulk operations across many items at once
- Define rules that trigger actions automatically on events
- The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently close
- Give an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by name
- An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials
- See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the penny
- I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automatically
- Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never drifts
- Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented
- Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my code
- Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization time
- Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's used
docs.highnote.com9 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Build against official SDKs
- Subscribe to events via webhooks
- Explore an interactive API reference with runnable examples
- Test against a sandbox environment without touching production data
- Approve or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I control
- Show cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ D
- Do everything through the API that I can do in the UI
OpenAPI spec5 stories
- Drive the product through a documented public API
- Build against official SDKs
- Explore an interactive API reference with runnable examples
- An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentials
- Do everything through the API that I can do in the UI
llms.txt3 stories
Pricing docs3 stories
- The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid rail
- Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documented
- Launch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documented
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si -X POST https://api.us.test.highnote.com/graphql -H 'Content-Type: application/json' -d '{"query":"{ ping }"}' # keyless → 401reproduced$ curl -si -X POST https://api.us.test.highnote.com/graphql -H 'Content-Type: application/json' -d '{"query":"{ ping }"}' # [redacted]less → 401
HTTP/2 401
access-control-allow-origin: *
$curl -sL https://docs.highnote.com/llms.txt | head -3reproduced$ curl -sL https://docs.highnote.com/llms.txt | head -3 # Highnote Documentation > Highnote is a card issuance, payment processing, and money movement platform-as-a-service. Build card programs with APIs for issuing virtual, physical, and [redacted]ized payment cards, processing acquiring transactions, and moving funds. This index lists all public documentation pages.
$curl -s https://highnote.com/openapi.json | head -c 150reproduced$ curl -s https://highnote.com/openapi.json | head -c 150
{
"openapi": "3.1.0",
"info": {
"title": "Highnote API",
"version": "2026-09-03",
"summary": "HTTP transport for the Highnote GraphQL
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
3 of 21 testable claims verified · 0 contradicted → integrity 14/100
28 distinct capability claims found in Highnote’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
3
Verified
18
Unverified
0
Contradicted
11
Undersold
Verified (4)
“Official Node.js SDK wraps the API in typed, resource-oriented methods”
“GraphQL API available for building integrations”
Drive the product through a documented public APIfullproof ↗
“Interactive code explorer for exploring the API”
Explore an interactive API reference with runnable examplespartialproof ↗
“PCI-compliant SDKs provided for development”
Unverified (24)
“Create virtual, physical, and tokenized payment cards”
Create a virtual card through the API in one call — PAN, CVV, and expiry available programmatically the moment it's issued — and go from sandbox to a live card without a sales cyclepartialproof ↗
“Create virtual, physical, and tokenized payment cards”
Order personalized physical cards through the API — custom card art, bulk orders, shipping methods and tracking — without managing a card manufacturer relationship myselfpartialproof ↗
“Configure spend rules and velocity controls on authorizations”
Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my codefullproof ↗
“Track balances and money movement via an integrated ledger”
See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the pennypartialproof ↗
“Approve or decline transactions in real time via collaborative authorization”
Approve or decline each authorization in real time — a webhook or auth-stream endpoint my code answers inside the network's time budget, with a documented timeout fallback I controlpartialproof ↗
“Automate authorization logic based on merchant category, dollar amount, and count”
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization timepartialproof ↗
“Create velocity controls enforcing spending limits like weekly caps”
Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my codefullproof ↗
“In-house Disputes Team handles dispute and chargeback processes”
File and track disputes on card transactions programmatically — network reason codes, evidence submission, provisional credit handling, and status webhooks through resolutionpartialproof ↗
“Test environment replicates live functionality for simulating transactions and compliance scenarios”
Test against a sandbox environment without touching production datafullproof ↗
“Test environment replicates live functionality for simulating transactions and compliance scenarios”
Simulate the whole transaction lifecycle in the sandbox — authorizations, clearings, reversals, refunds, and declines — so my auth logic is tested before a real card ever swipespartialproof ↗
“Configure which events are delivered to each webhook”
“Rotate the signing key used to verify webhook payloads”
“Embed sensitive card data in your UI without inheriting PCI scope”
Show cardholders their own PAN and CVV without inheriting PCI scope — hosted components or ephemeral-key reveal flows the vendor documents as keeping me out of SAQ Dpartialproof ↗
“Collect identity verification documents during manual review of card applications”
Cardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flowspartialproof ↗
“Issue scoped cards per agent, workflow, or vendor via API that auto-close when done”
Give an agent its own card — issue a scoped virtual card to an AI agent with merchant locks, amount caps, and expiry so autonomous purchases stay inside policy, a use the vendor documents by namefullproof ↗
“Set velocity limits, MCC restrictions, and per-transaction caps enforced at authorization”
Set spend limits per card and per cardholder — amount caps over daily, monthly, or all-time windows, and transaction-count velocity rules — enforced by the platform, not my codefullproof ↗
“Set velocity limits, MCC restrictions, and per-transaction caps enforced at authorization”
Restrict where a card works — merchant category (MCC) allowlists and blocklists, and single-merchant locks — applied at authorization timepartialproof ↗
“Every transaction posts to a unified ledger the moment it occurs”
See money move in real time — account and card balances, a transaction ledger that ties every authorization to its clearing, and settlement reporting that reconciles to the pennypartialproof ↗
“Full payment lifecycle (authorize, capture, refund) available via API”
Post-auth events are as programmatic as auth — clearings, refunds, reversals, and chargebacks arrive as webhooks with stable transaction identifiers, so my own ledger never driftspartialproof ↗
“Set spend rules once at the program level to apply uniformly across all cards”
Define rules that trigger actions automatically on eventspartialproof ↗
“In-house teams manage KYC/KYB regulatory compliance”
Cardholder verification is built into issuance — KYC for consumers and KYB for businesses run through the platform with documented data requirements, review states, and re-verification flowspartialproof ↗
“In-house teams handle transaction monitoring, daily reconciliation, and settlement”
I get machine-readable reconciliation artifacts — daily settlement files or report APIs covering interchange, fees, and network adjustments — that my finance stack can consume automaticallypartialproof ↗
“Launch or migrate a card program with speed and flexibility”
Launch a card program without becoming a bank — BIN sponsorship, network membership, and program management are the platform's problem, and the time from signup to first live card is documentedpartialproof ↗
“Connect external bank accounts via Plaid for funding”
Choose how transactions are funded — prefunded balances or just-in-time funding where my system approves and funds each authorization — with the cash-flow tradeoffs documentedpartialproof ↗
Undersold (11)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationpartialproof ↗
Set up automations that run autonomously in the backgroundpartialproof ↗
Every authorization event carries decision-grade context — merchant name and MCC, enhanced merchant data, wallet and entry-mode details, partial-approval and incremental-auth signalspartialproof ↗
Perform bulk operations across many items at oncepartialproof ↗
The full card lifecycle is API-driven — activate, pause, unpause, report lost or stolen, reissue with a replacement linked to the original, and permanently closepartialproof ↗
An agent can operate my card program — read balances and transactions, create and update cards, and adjust spend controls through the API or an MCP surface with scoped credentialspartialproof ↗
The platform fights fraud on my issued cards — network fraud scores or its own models surfaced at auth time, suspicious-activity alerts, and tooling to block and reissue compromised cardspartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
The platform supports the card types my product needs — debit, prepaid, commercial credit, and consumer credit programs — not just one prepaid railpartialproof ↗
Issue single-use and tightly scoped cards — one purchase, one merchant, an exact amount — so a leaked number is worthless the moment it's usedfullproof ↗
Claims outside our story set (3)
Real capability claims found in Highnote’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Issue a financial account once an account holder's application is approved”
source ↗“Add internal notes to a financial account for servicing purposes”
source ↗“Accept payment card details in a configured checkout experience”
source ↗
Business model
Partial transparency: acquiring published at 2.85% + $0.25 pay-as-you-go, but issuing is Custom/contact-sales on both tiers — per-card and interchange economics negotiated per program.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
