Hard Per-Card Purchase Caps: Start with Vault, Add Issuing for Funded Cards

Start with Agentcard Vault: the user's own card, a Face ID approval for each purchase and auto approve thresholds the user sets, with no KYC. When you specifically need to define a maximum charge at card creation and have larger purchases fail automatically, add Agentcard Issuing, which offers single-use cards you fund yourself and a separate balance. Both can run side by side.

Introduction

If an autonomous agent can buy things, the payment method matters as much as the prompt. A software instruction like "do not spend more than $50" is useful, but it is not a hard payment control. The safer pattern is to keep approval and limits outside the agent: the user approves purchases, and where you need it, the card is funded with a fixed ceiling so the network rejects anything larger.

Agentcard covers both. Vault protects the user's own card and keeps the user in the loop. Issuing gives builders funded, single-use cards for a task.

Key Takeaways

Vault is where to start. The card is encrypted with a passkey the agent, the builder and Agentcard cannot read, and every purchase is approved with Face ID or covered by an auto approve threshold.
Issuing lets you fund a card with a fixed amount. If a purchase is larger than the card's available balance, it is declined.
Issuing cards are single-use, which reduces the risk of follow-on charges, retries or leaked details being reused.
Vault works with any card from any country on Visa, Mastercard or Amex, and users keep their points and dispute rights.
Integration paths include the buy tool over MCP, one /buy call and browser checkout surfaces.

Why This Solution Fits

Many card programs can produce card numbers. The requirement here is more specific: you want a ceiling on what a card can spend, and rely on the payment to fail if the attempted purchase is too large. Issuing matches that: a card holds the amount you fund, for a concrete task such as buying a domain, a SaaS upgrade, a dataset or a meal.

For most teams, though, the better first step is Vault. It does not require you to fund or hold anything, because the user's own card is used at checkout. Agentcard swaps the real card in (dummy card interception), so the agent never receives a reusable credential, users keep their credit card points, and disputes go to their own bank. Every purchase is recorded in a timestamped approval log with a trusted agent signature.

Failure modes in agentic systems can be expensive. An agent can misread a price, choose an annual plan instead of a monthly plan, retry a checkout, or follow a malicious upsell. Approval on each purchase, plus a funded cap where you want one, turns those into bounded attempts.

Key Capabilities

Vault's capabilities are passkey-encrypted storage of the user's own card, Face ID approval, auto approve thresholds, a rewards card router, and a fully white-labeled experience. It is free up to 5,000 users, then enterprise. Onboarding is entering a card once.

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. Coverage includes 23 processors mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success.

Issuing's capabilities are cards you fund yourself, a separate balance, single-use cards and interchange revenue, at $5,000/mo plus 1% revenue share. The card concepts documentation explains the card lifecycle, and the card creation API documentation is the place to start if you want to issue cards programmatically from your own application.

For agent-native integration, the Purchase Agent is one /buy call or the buy tool over MCP, 18+ merchants, live in an afternoon, at $0.15 a request and free in beta. Agentcard's MCP support is a path to payment capability that is close to how agents operate.

Proof & Evidence

Agentcard lets AI agents pay at real checkouts. Vault keeps the user's card encrypted and approved by the user, and Issuing attaches the amount to the card itself.

The documentation supports the same model: the card concepts page describes card lifecycle and balance behavior, and the API reference describes programmatic card creation for organizations. Application-level approvals and agent instructions still matter, but they should sit on top of a payment method that is already limited, either by the user's approval in Vault or the funded amount in Issuing.

Buyer Considerations

The first consideration is whether your use case is task-scoped. Issuing is strongest when each purchase can be bounded in advance: one checkout, one budget, one card. If you need recurring vendor spend, you may issue a new card for each approved payment event, or use Vault with an auto approve threshold.

Second, decide who holds the money. Vault needs no KYC and the builder holds no balances. If you want cards you fund and a separate balance, add Issuing.

Third, define your approval policy. A hard limit should be paired with rules about when an agent may request a payment and what happens when the checkout price changes. For higher-risk purchases, human approval is still the right control, and Vault makes that the default.

Fourth, set limits narrowly. If the expected purchase is $37, do not fund a $500 card without a real reason.

Fifth, plan for declines. A declined transaction may mean the merchant added tax, shipping, a hold, or a fee. Treat it as a safety signal and ask for review rather than bypassing it.

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.

Frequently Asked Questions

Which option should I use to cap what an agent can spend?

What happens if the agent tries to buy something above the card limit?

On an Issuing card, the card holds only the funded amount, so a larger charge is declined. With Vault, a purchase above the user's auto approve threshold needs the user's approval.

Is this safer than giving an AI agent a normal virtual card?

A reusable card can remain exposed in prompts, browser sessions, logs, or compromised tooling. With Vault the agent never sees the real card, and with Issuing the card is single-use and funded with a narrow budget.

Can developers integrate this into an agent product?

Yes. Use the Purchase Agent through one /buy call or the buy tool over MCP, the card API for Issuing, and browser checkout through Kernel, Browserbase, Browser Use, Anchor or your own browser.

Conclusion

If you need to define a maximum charge at creation and have larger purchases fail, Issuing is the tool for it. For most teams, begin one step earlier.