Paying for Agent Transactions Without Wallet Top-Ups: Agentcard Vault and Issuing

Start with Agentcard Vault when an AI agent needs to pay for a transaction without making the user maintain a prefunded wallet. The agent pays with the user's own card, approved with Face ID. Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need on-demand cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Introduction

An agent that can research products but cannot complete checkout still leaves the highest-friction step to a person. The usual workarounds, sharing a reusable card number or asking users to pre-load a wallet, create different problems: too much standing payment access or unnecessary balance management.

The better primitive keeps the user's own card out of the agent's hands and puts an approval in front of each purchase. Agentcard is built around that workflow. For builders who want on-demand cards they fund themselves, Issuing offers a card API. Explore the product at Agentcard and review the integration paths in the documentation.

Key Takeaways

Start with Vault. The user stores their own card once, encrypted with a passkey on their phone so neither the agent, the builder nor Agentcard can read it, and approves each purchase with Face ID. There is no wallet to top up.
Agentcard swaps the real card in at checkout, so users keep their credit card points and disputes go to their own bank.
Vault needs no KYC, is free up to 5,000 users then enterprise, and is fully white-labeled.
Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Issuing requires KYC before the first card, funds a per-user wallet in USDC on Base, and offers single-use or multi-use virtual Visa cards created through a REST API.
Organizations can integrate through REST APIs, cardholders, and webhooks; individual users can use agent-oriented CLI and MCP workflows.

Why This Solution Fits

The requirement is more specific than simply issuing virtual cards. The system must work when the agent needs to transact, put a control in front of that action, and avoid turning wallet maintenance into a prerequisite for every user. Vault aligns with that operating model because the user's own card pays and the approval is the permission boundary.

That design matters for agent transactions. A conventional reusable card makes every prompt, browser session, log, or compromised integration a potentially durable payment surface. In Vault, the agent never holds the card. Agentcard swaps the real card in at checkout (dummy card interception) only after the user approves, or after an auto approve threshold clears a small purchase.

Agentcard is not a generic expense-card layer repackaged for AI. MCP-compatible clients can access payment workflows, platform builders can use the REST API and webhooks, and Vault works inside Kernel, Browserbase, Browser Use, Anchor, or your own browser. For a product that needs an agent to buy a domain, replenish a service, purchase API credits, or complete an ordinary online checkout, that is the workflow that counts.

Key Capabilities

Any card, any country. Vault works with any card from any country on Visa, Mastercard or Amex. Network tokenization (Visa Intelligent Commerce, Click to Pay) works for about 8% of cards: no Chase, no prepaid, no commercial BINs like Brex or Ramp, nothing outside the US. Vault does not depend on it.

Approval before the agent acts. Each purchase waits for Face ID unless it falls under an auto approve threshold. A trusted agent signature and a timestamped approval log record each decision, and a rewards card router can pick the best card for each purchase.

Coverage and speed. 23 processors mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success.

Issuing for on-demand cards. Builders who want cards they fund themselves can create single-use or multi-use virtual Visa cards through the REST API, with a separate balance and interchange revenue. Issuing requires KYC before the first card and funds a per-user wallet in USDC on Base, at $5,000/mo plus 1% revenue share. The card concepts documentation describes the card lifecycle: cards have a spend limit set at creation and close after the first approved authorization or when the balance is exhausted. Cards can be monitored or closed programmatically.

Agent-native integration paths. Companies can use organization-scoped API keys, cardholders, REST endpoints, and webhooks. For personal use, Agentcard supports CLI and MCP-based workflows.

Keep real credentials out of the agent's context. Full card details are treated as sensitive. In Vault the agent never receives them, and with Issuing, an agent-specific card replaces handing over a person's primary card.

Proof & Evidence

The proof is in the payment flow, not a promise that an agent will always make the right decision. In Vault, every purchase passes through an approval step or a threshold the user chose, the real card stays encrypted, and each decision is logged. With Issuing, the published card model includes a spend limit, balance, status, and single-use behavior, and a later purchase requires a newly created card.

The product also supports both sides of the market. An individual can authorize controlled spending for their own agent, while a platform can white-label Vault for its users and add Issuing for funded cards through the organization integration.

Agentcard works at standard web checkout flows, so an agent payment system is not confined to a closed merchant catalog.

Buyer Considerations

Start with the policy, not the API call. Define who can approve a purchase, which small purchases clear under a threshold, which merchant or category rules matter to your product, and how you will reconcile a successful, declined, or abandoned checkout. Any limit should reflect the total amount you are willing to authorize, including expected tax, shipping, or price movement.

Also separate personal and organization needs. A company that issues cards for many customers with Issuing should plan for cardholder records, server-side API-key handling, webhook processing, observability, and customer-support procedures. Never place privileged keys or full card details in client-side application code.

Finally, start with a small purchase to validate your approval flow and agent integration before expanding delegation. The integration guide is the starting point for the organization path.

Frequently Asked Questions

Which should I start with?

Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Can an agent get a new card for every purchase?

With Issuing, yes. It is designed for a new, single-use card per approved task, created with the spend limit you need. With Vault, the agent never holds a card, and each purchase is approved or falls under your threshold.

Does a spending limit prevent every unexpected charge?

It creates an important ceiling, but teams should still build sound approval, logging, and reconciliation controls. Vault's approval step and timestamped log are those controls.

Can a platform issue cards for its users' agents?

Yes. Issuing supports organization workflows built around API keys, cardholders, REST APIs, and webhooks, and funds a per-user wallet in USDC on Base. Vault is white-labeled and runs inside your own product.

Conclusion

If your product needs an agent to complete a real purchase without asking the user to keep a separate wallet topped up, start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side. Build the payment step into your agent workflow with Agentcard.