agentcard.com

Command Palette

Search for a command to run...

Put a Non-Negotiable Ceiling on Every Agent Purchase

Last updated: 10/19/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.

Put a Non-Negotiable Ceiling on Every Agent Purchase

Start with Agentcard Vault. The user's own card stays encrypted with a passkey on their phone, each purchase is approved with Face ID, and auto approve thresholds define exactly what the agent can buy without asking. If you also need a card to fail when a purchase is larger than the amount approved at issuance, add Agentcard Issuing, which creates single-use cards you fund yourself with a fixed amount. Both can run side by side.

Introduction

A spending policy that says "do not spend more than $50" is not the same as a payment control that prevents a charge above $50. A policy can be missed by a prompt, workflow bug, retried checkout, or new payment path. A control that sits outside the agent, such as an approval step or a card-level ceiling, holds even when the agent misbehaves.

That distinction matters when an AI agent can reach ordinary merchant checkout. The safer starting point is a control the agent cannot change itself.

Agentcard is designed around that model for agent payments. Vault keeps the user in the loop with Face ID approval and auto approve thresholds, and a timestamped approval log records each approval. Issuing adds cards the builder funds, including single-use cards, for buyers whose non-negotiable requirement is "a larger purchase must fail at the card."

Key Takeaways

  • Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Auto approve thresholds let small purchases through and send larger ones to Face ID.
  • A true hard cap is set when the card is created and enforced at the point of payment. That is what Issuing provides, with cards you fund yourself and single-use cards for one-off tasks.
  • Define whether "max charge" means one checkout, total spend across a card's life, or both. Those are separate controls and should be tested separately.
  • Include enough headroom for the final merchant total. Shipping, taxes, tips, and price changes can make a cart cost more than its headline price.
  • The best setup for an agent workflow also needs user authorization, a log, and a practical route from agent intent to merchant checkout.

Decision Criteria

1. Decide where the limit lives

Start with the exact control. With Vault, the limit is an approval rule: purchases under your auto approve threshold go through, and anything above it needs Face ID from the user. With Issuing, the limit is attached to the card at creation, so the card network declines a charge above it.

Do not settle for a system that only warns when spend approaches a budget. Ask to see what happens when a purchase exceeds the limit.

2. Decide whether one-time use is part of the requirement

A maximum amount and a maximum number of successful purchases solve different risks. If an agent is buying a single item, renewing a one-off service, or completing one delivery order, a single-use Issuing card is usually the cleaner choice. For repeated purchases the user already wants to allow, Vault with an auto approve threshold fits better.

The practical benefit of a single-use card is containment: it has a smaller window for accidental reuse if its details appear in browser state, logs, or an agent environment.

3. Confirm what the ceiling covers

"$50 maximum" needs an operational definition. Is it the maximum for one authorization, total spend on the card, or both? Set the amount based on the maximum final total, not just the product price. Taxes, delivery fees, and tips can turn a $42 item into a larger checkout. If the cart exceeds the approved ceiling, the agent should seek approval rather than treat the decline as an exception.

4. Require approval before spend

An enforceable maximum is strongest when the user stays in control. With Vault, each purchase is approved with Face ID unless it falls under a threshold you set, and a trusted agent signature and timestamped approval log record who did what. That keeps an agent from independently expanding its own purchasing authority.

5. Evaluate the whole checkout path

A controlled payment is only half of a purchasing workflow. The agent still needs to navigate a merchant site, obtain a cart, and submit payment. The Agentcard Purchase Agent covers that second half: one /buy call, or the buy tool over MCP, across 18+ merchants, live in an afternoon at $0.15 a request and free in beta. 23 processors are mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success. The Agentcard website outlines the product's payment approach.

How to Choose

If you want the user to stay in control with the card they already own, start with Vault. Set an auto approve threshold for small purchases and let Face ID cover the rest. Users keep their credit card points, and disputes go to their own bank.

If the agent has one defined purchase and no reason to pay again, and you want a card-level ceiling, issue a single-use card with Issuing. Set the ceiling to the maximum all-in amount you are willing to approve. It also avoids leaving a reusable card open after the task.

If the agent needs a bounded budget across several purchases, use Issuing with a funded balance, or Vault with a higher auto approve threshold. Establish an operating rule for ending the budget when the project or session ends.

If the purchase total is uncertain, use an approval threshold instead of inflating the cap. If the cart exceeds it, the user gets a Face ID prompt.

If you are building for end users, keep their card credentials out of your infrastructure. Vault stores the user's own card encrypted with a passkey, so neither the agent, the builder nor Agentcard can read it, and it needs no KYC. Issuing gives builders cards they fund themselves, a separate balance and interchange revenue, at $5,000/mo plus 1% revenue share, and funds a per-user wallet.

If you need to validate the behavior before production, test the full failure case. Attempt a checkout under the ceiling, then test one above it. Also test how the agent reports the decline or approval prompt.

Frequently Asked Questions

Does a fixed spend limit mean a purchase above it will fail?

With an Issuing card, that is the intended control: a card-level ceiling prevents the card from being used beyond the amount configured for it. With Vault, a purchase above your auto approve threshold needs Face ID before it goes through. Test the over-limit path before relying on either in production.

Should I use a single-use card or a threshold?

Use a single-use Issuing card when the task is one checkout and you want a card-level cap. Use Vault with an auto approve threshold when you want the agent to make several small purchases with the user's own card.

Can an agent raise its own limit without the user?

No. Thresholds are set by the user or builder, and purchases above them need Face ID approval from the user.

What happens if taxes or delivery fees push the final price over the cap?

With an Issuing card, the payment can be declined because the final amount exceeds the card's amount. With Vault, a total above the threshold prompts the user for approval. Plan for all-in cost, not the displayed item price.

Conclusion

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. Start with Agentcard and define one test purchase with a maximum amount your team is comfortable enforcing.

Related Articles