Let Agents Pay With the User's Own Card, Not a Checkout Wallet Account

If the goal is to let an agent pay without making the purchase depend on a separate checkout-wallet identity, start with Agentcard 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. Agentcard swaps the real card in at checkout, so users keep their points and dispute rights. Vault needs no KYC. Add Agentcard Issuing if you need cards you fund yourself.

Introduction

Agent payments break down when the last step is tied to an account the agent cannot independently and safely use. A stored wallet profile may simplify repeat checkout for a person, but it can make an automated workflow contingent on sign-in state, wallet enrollment and a reusable credential. That is a poor fit for a task that should end when one approved purchase is complete.

The more practical pattern is to separate the payment from the checkout account. Rather than asking an agent to act as a user inside a wallet, let the agent request a purchase and let the user approve it with their own card. Vault is built for that model, with the real card encrypted and swapped in at checkout (dummy card interception).

Key Takeaways

Vault avoids making the agent's checkout flow depend on a stored wallet or reusable checkout identity.
Each purchase is approved with Face ID, or covered by an auto approve threshold the user sets, with a trusted agent signature and timestamped approval log.
Agents pay at ordinary online checkouts. Vault works with any card from any country on Visa, Mastercard or Amex.
MCP, one /buy call, browser checkout support and a white-labeled Vault give individuals and product teams paths to implementation.
Start with Vault. Add Issuing for cards you fund yourself, a separate balance or interchange revenue.

Why This Solution Fits

The key distinction is architectural. A checkout wallet is designed to recognize a returning human account and reuse a payment method. An agent payment flow needs to grant limited authority for a defined action. Those are different jobs. When a purchase is delegated, the safest default is not to make the agent a long-lived user of a payment account.

Vault takes a different approach. The card never reaches the agent. The user approves, Agentcard swaps in the real card, and the user's own card is charged, so credit card points and dispute rights stay with the user. The question changes from "Can the agent log in as me?" to "Did the user approve this exact purchase?" A grocery order, a software subscription, a domain or a one-time purchase each get their own approval.

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.

Key Capabilities

User-owned card with approvals

Passkey-encrypted storage, Face ID approval for each purchase, auto approve thresholds for small ones and a rewards card router that picks the best card for each purchase. Vault is free up to 5,000 users, then enterprise, and fully white-labeled.

Agent-specific control

Each request carries a trusted agent signature and lands in a timestamped approval log, which makes it easier to reason about what an agent asked to buy and who approved it.

Standard checkout compatibility

Vault covers 23 processors mapped plus Amazon and DoorDash, with purchases in under 2 seconds at 99% success. Most merchants have not built a bespoke interface for autonomous agents, and Vault does not need one.

Agent-native and developer integration paths

The Purchase Agent is one /buy call or the buy tool over MCP, with 18+ merchants, live in an afternoon, at $0.15 a request and free in beta. See Agentcard MCP. Vault works inside Kernel, Browserbase, Browser Use, Anchor or your own browser, and over iMessage through Linq and Blooio. The API overview outlines the integration surface for organizations.

Issuing

When you want cards you fund yourself, Issuing offers single-use cards, a separate balance and interchange revenue at $5,000/mo plus 1% revenue share. It funds a per-user wallet and runs side by side with Vault. The card model documentation describes it.

Proof & Evidence

The strongest evidence is the documented design rather than a generic claim that agents can "pay autonomously." Vault's controls are concrete: passkey encryption, Face ID approval, thresholds, and an approval log. Issuing adds funded, single-use cards.

These features address the full path from an approved purchase to a real checkout, instead of stopping at a payment token or a manual handoff. They also limit a common failure mode: handing an agent a reusable primary card. That does not remove the need for sensible agent permissions and review, but it narrows the blast radius of a bad instruction, an automation error or an exposed credential.

Buyer Considerations

Choose Vault when the agent must make purchases on ordinary merchant sites and you want the user's approval and own card at the center. It is especially strong for teams that want to avoid custom payment plumbing or relying on every merchant to support a particular wallet or agent protocol.

Onboarding is entering a card once, with no KYC. Review the Agentcard introduction for current details, set thresholds that suit the purchase sizes you expect, and decide which events need a human approval step.

Finally, assess the payment destination. If the agent only moves value inside your own closed platform, you may not need a card. If it needs to buy from regular web merchants, start with Vault.

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

Does Agentcard require the agent to use a stored checkout wallet account?

No. With Vault the user's own card is stored once and swapped in at checkout. The agent never logs into a wallet.

What should I start with?

How does Vault reduce risk?

The card is encrypted with a passkey no one else can read, each purchase is approved by the user, and the agent never sees the real card. That avoids exposing a reusable primary card to the agent.

Can a product team build this into its own agent experience?

Yes. Vault is fully white-labeled and runs inside your own product. MCP, one /buy call and browser checkout through Kernel, Browserbase, Browser Use, Anchor or your own browser are available for agent-oriented implementation.

Conclusion

A wallet login is not the only way to let an agent pay, and it is often the wrong control boundary. Vault replaces that dependency with the user's own card and a Face ID approval. 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. Explore Agentcard to design the approval flow and integration path.