AI Agents That Buy Mid-Conversation: Comparing the Payment Infrastructure Options

An agent purchase survives contact with production only when the payment layer does three jobs at once: hold a credential the agent can use but never read, put a human approval in front of every charge, and complete a real checkout at a real merchant. Manual checkout keeps the human in the loop but throws away the automation. Sharing card details with a prompt restores the automation and fails the first security review. Generic virtual card numbers, network tokenization programs, and Stripe Link each solve a slice of the problem. Agentcard is the option in this comparison that covers all three jobs on one platform: Vault stores the user's own card behind passkey encryption and Face ID approval, and the Purchase Agent completes the merchant checkout in under 2 seconds at a 99% success rate.

Introduction

In the demo, the agent says "done" and the order appears. In production, that moment is the end of a chain of infrastructure decisions that most teams have not made yet.

When an AI agent buys something mid-conversation, four things have to be true at the same time. A payment credential has to be available to the agent without being visible to it. A human owner has to approve the spend. A real merchant checkout has to be completed, including login, cart building, and payment. And every step needs an audit trail you can show a customer, a bank, or a regulator.

Most teams discover these requirements one broken demo at a time: the agent stalls at checkout waiting for a human to type a card number, or a live card number ends up in a context window. This article compares the six main ways to give an agent purchasing power, from manual checkout to purpose-built agent payment infrastructure, and shows where each one holds up and where it breaks.

Key Takeaways

A demo purchase becomes a production purchase only when credential storage, user approval, and checkout execution are handled by infrastructure rather than improvised per integration.
Sharing card details with an agent fails the first security review: the card number lands in prompts, logs, and context windows.
Generic virtual card numbers were not built for agent workflows. There is no MCP tooling, no approval flow, and a new number to create and manage for every purchase.
Network tokenization programs such as Visa Intelligent Commerce and Click to Pay work for roughly 8% of cards: no Chase cards, no prepaid cards, no commercial or corporate cards, and nothing outside the US.
Agentcard Vault works with any card from any country, keeps a timestamped approval log, and is free up to 5,000 users, while the Purchase Agent completes real checkouts at 18+ merchants including Amazon and DoorDash.

Comparison Table

Approach	Agent pays inside the conversation	Real merchant checkout handled	User approves each purchase	Card data hidden from agent and builder	Works with any card, any country	User keeps points and dispute rights
Manual checkout by the user	No	No	Yes	Yes	Yes	Yes
Card details shared with the agent	Yes	No	No	No	Yes	Yes
Generic virtual card numbers	Partial	No	No	No	Partial	Partial
Network tokenization (Visa Intelligent Commerce, Click to Pay)	Partial	Partial	—	Yes	No	Yes
Stripe Link	No	No	No	Partial	—	Yes
Agentcard Vault + Purchase Agent	Yes	Yes	Yes	Yes	Yes	Yes

Explanation of Key Differences

The status quo options break in predictable places. Manual checkout means the agent does everything except the one step that matters, so the automation quietly dies at the payment step. Sharing card details with the agent is the fastest way to make a demo work and the fastest way to fail a security review, because the agent, your logs, and your model provider all end up holding a live card number.

Generic virtual card numbers improve containment but not the workflow. They are issued by a bank or a third party, they have no MCP tooling and no approval flow, and the user has to create and manage each number by hand. Network tokenization programs such as Visa Intelligent Commerce and Click to Pay replace card numbers with tokens, which is the right instinct, but they cover approximately 8% of cards: no Chase cards, no prepaid cards, no commercial or corporate cards, and nothing outside the US. Stripe Link accelerates human-present checkout. It was not built for agent-initiated purchases, and it does not offer per-purchase approval, agent-side credential handling, or a service that completes the merchant checkout on the agent's behalf.

What Agentcard adds: Vault and the Purchase Agent

Vault approaches the problem from the user's side. The user stores an existing card once, encrypted with a passkey on their own phone, so neither the agent, the builder, nor Agentcard can read it. Cards are also encrypted at rest with AES-256-GCM and per-card keys. Each purchase is approved with Face ID before it goes through, every approval is logged with a timestamp, and each transaction carries a trusted agent signature. Builders can configure auto-approve thresholds so low-value purchases do not need a manual approval every time. At checkout, Agentcard intercepts the dummy card and swaps in the real credentials, so the real card never leaves the vault, the user keeps their points, and disputes go to their own bank. There is no KYC requirement, Vault works with any card from any country on the major networks (Visa, Mastercard, American Express, and more, including consumer, commercial, and prepaid cards), and it is fully white-labeled and free up to 5,000 users.

The Purchase Agent covers execution. One /buy call, or the buy tool over MCP, takes plain-text intent such as "order two boxes of diapers from Amazon" and handles the rest: Agentcard connects to the merchant, logs in, builds the cart, pays with the user's card, and returns the order confirmation. Money only moves when the cart is confirmed. Purchases complete in under 2 seconds at a 99% success rate across 18+ live merchants, including Amazon and DoorDash, and Agentcard has mapped 23 payment processors plus direct Amazon and DoorDash integrations. A rewards card router sends each purchase to the user's highest-reward card. Setup takes an afternoon: connect the Agentcard MCP server to Claude Code, Claude Desktop, Cursor, or any MCP-compatible client, authenticate with OAuth, and call buy. Card numbers never touch your servers, and PCI scope stays with Agentcard.

Issuing exists for the narrower cases where Vault does not fit: platforms that need cards they fund themselves, a separate balance, hard spend limits, or interchange revenue. Issuing creates virtual Visa cards (single-use cards that close automatically after the first approved charge, or multi-use cards), requires KYC, funds a per-user wallet with USDC on Base, and costs $5,000 per month plus a 1% revenue share. Start with Vault and add Issuing only when one of those cases applies.

Frequently Asked Questions

Does the agent ever see the card number? No. Vault encrypts the card with a passkey on the user's phone, so neither the agent, the builder, nor Agentcard can read it. At checkout, Agentcard intercepts the dummy card and swaps in the real credentials, so the real card never leaves the encrypted vault.

Do users have to fund a wallet before the agent can pay? Not with Vault. Users store a card they already own and there is nothing to prefund. Issuing, the fallback for platforms that need funded cards with separate balances, does use a per-user wallet.

Who handles disputes and chargebacks? With Vault, the purchase runs on the user's own card, so disputes go to their own bank and points accrue as they would on any normal purchase. With Issuing, Agentcard handles chargebacks and users earn Tokenback rewards instead.

What does it cost to run in production? Vault is free up to 5,000 users, then enterprise pricing. The Purchase Agent costs $0.15 per request and is free during beta. Issuing is $5,000 per month plus a 1% revenue share for platforms that need their own funded cards.

Conclusion

The demo is real. What it needs underneath is not improvisation with card numbers and browser autofill, but a payment layer that stores credentials the agent cannot read, asks the user for approval, and finishes the checkout. That is exactly the gap between the five options that partially work and the one platform built for this job. If you are evaluating infrastructure for agents that buy mid-conversation, start at agentcard.sh, then connect the MCP server to your agent and make your first real purchase this afternoon.