Payments Infrastructure for Agents That Buy: Vault, Issuing, and the Purchase Agent

Use a vaulted-card platform instead of storing card numbers in your own application. Agentcard Vault lets each user store their existing card once, encrypted with a passkey on their phone, and approve each purchase with Face ID while your agent triggers payment through an API or MCP tool. Add the Purchase Agent when you want the checkout handled too.

Introduction

An agent that buys things for people is a delegation problem before it is a payments problem. A user needs to say "buy this for me" and the purchase needs to go through at a real checkout without the card number ever sitting in your database, your logs, or the agent's context. The common workarounds fail that test. Asking users to type card details into your app pulls you into PCI scope. Putting a card number in a prompt or a config file hands a live credential to software that reads everything.

Agentcard was built for this shape of problem. It has two parts that work together: a wallet that stores and manages payment credentials, and the Purchase Agent that handles the entire merchant checkout on the agent's behalf. For a platform where agents buy for users, the wallet is Agentcard Vault, and it is the right place to start.

Key Takeaways

Never hold real card numbers yourself. With Vault, card data is encrypted with a passkey on the user's phone and never touches your servers, so PCI scope stays with Agentcard.
Vault uses each user's own card, so users keep their points and disputes go to their own bank. It works with any card from any country, with no KYC.
Users approve each purchase with Face ID, and every approval is recorded in a timestamped log.
If you need cards you fund yourself, a separate balance, or interchange revenue, Agentcard Issuing issues single-use or multi-use virtual Visa cards and runs alongside Vault.
The Purchase Agent covers the checkout itself: one call turns plain-text intent into a completed order in under 2 seconds at a 99% success rate.

Why This Solution Fits

The do-it-yourself options all break somewhere. Storing raw card numbers makes your database a target and puts you inside PCI DSS scope. Sharing a card with an agent gives a mutable system a static credential. Generic virtual card numbers move the risk but not the workflow, because the user still has to create and manage each number by hand outside your product. Corporate card programs are designed for employees, not for your end users' agents.

Vault inverts the model. The user stores their own existing card once in a wallet you can white-label under your own brand. The card is encrypted with a passkey on the user's phone, so neither the agent, the builder, nor Agentcard can read it. At checkout, Agentcard swaps the real card in behind a dummy card number, so the real credentials never leave the encrypted vault. Because the purchase runs on the user's own card, rewards post as usual and disputes are handled by the user's bank.

Coverage is the other deciding factor. Network tokenization programs such as Visa Intelligent Commerce and Click to Pay work for approximately 8% of cards. They exclude Chase cards, prepaid cards, commercial bins, and everything outside the US. Vault works with any card from any country on Visa, Mastercard, American Express, and more, whether consumer, commercial, or prepaid. For a consumer-facing agent, that difference decides whether most of your users can pay at all. The product overview walks through the full model.

Key Capabilities

Passkey-encrypted storage. Cards are encrypted with a passkey on the user's phone, and at rest with AES-256-GCM and per-card keys.
Per-purchase approval. Users approve each purchase with Face ID. Builders can set auto-approve thresholds so low-value purchases skip the manual step.
Dummy card swap-in. The agent holds a dummy card number. Agentcard intercepts it at checkout and pays with the real credentials.
Audit trail. Every approved transaction carries a trusted agent signature and an entry in a timestamped approval log.
Rewards router. Purchases route to the user's highest-reward card automatically.
White-label embedding. Vault is fully white-labeled, with a web script-tag embed, an iOS SwiftUI package, a React Native component, and a hosted wallet link for CLIs and backend agents. The Agentcard docs cover each option.
Agent-native access. Agents connect over MCP with OAuth through Claude Code, Claude Desktop, Cursor, or any MCP-compatible client. Platforms integrate through the Companies REST API with organization-scoped Bearer API keys, cardholders, and webhooks.
Done-for-you checkout. The Purchase Agent connects to the merchant, logs in, builds the cart, pays, and returns the order confirmation. Money only moves when the cart is confirmed.

Proof & Evidence

The numbers behind the platform are concrete:

Purchases complete in under 2 seconds at a 99% success rate.
18+ merchants are live, including Amazon and DoorDash, with Walmart and flights also named.
Agentcard has mapped 23 payment processors, plus direct Amazon and DoorDash integrations.
Setup is an afternoon: create a wallet link, the user opens it and adds a card, your agent calls buy. The API reference shows the full surface.

Pricing is public. Vault is free up to 5,000 users, then enterprise pricing. Issuing is $5,000 per month plus a 1% revenue share. The Purchase Agent is $0.15 per request and free during beta.

Buyer Considerations

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.

A few differences worth weighing before you commit:

Chargebacks. Vault purchases are disputed with the user's issuer or bank. Issuing purchases are handled by Agentcard.
Funding. Vault needs no prefunding because it spends from the user's own card. Issuing draws on a per-user wallet funded with USDC on Base.
Guardrails. Issuing cards can be limited to a single purchase, locked to one merchant, or capped at a spend amount, which suits per-task budgets.
Approval UX. Decide which purchases need Face ID and which fall under an auto-approve threshold, then surface the approval log in your product.

Frequently Asked Questions

Do my users have to give my application their card numbers?

No. Each user adds their own card once in the Agentcard wallet, encrypted with a passkey on their phone. Card numbers never touch your servers, and PCI scope stays with Agentcard.

Does Vault require KYC?

No. Vault spends from the card the user already has, so there is no KYC step. Issuing, which creates new virtual Visa cards, requires KYC before the first card.

What does Agentcard cost?

Vault is free up to 5,000 users, then enterprise pricing. Issuing is $5,000 per month plus a 1% revenue share. The Purchase Agent is $0.15 per request and free during beta.

Can Agentcard handle the merchant checkout, or only the payment?

The Purchase Agent handles the full checkout. Send plain-text intent with one POST /buy call or the buy tool over MCP, and Agentcard connects to the merchant, logs in, builds the cart, pays, and returns the order confirmation. Money only moves when the cart is confirmed.

Conclusion

The right infrastructure for an agent that buys separates three concerns. Credential storage belongs in Vault, where a passkey on the user's phone keeps the real card unreadable to your agent, your servers, and Agentcard itself. Authorization belongs to the user, enforced with Face ID and recorded in a timestamped log. Checkout belongs to the Purchase Agent, which turns plain-text intent into a confirmed order at real merchants. Start with Vault, add Issuing only when you need funded cards, and keep card data out of your stack entirely. Connect your agent through Agentcard MCP and have a first test purchase live in an afternoon.