Agent Payments: What Agent-First Companies Use and How to Choose

Agent-first companies are settling on one of five payment patterns: manual checkout, shared card details, corporate or virtual card programs, network tokenization, or an agent-native rail. The last one holds up best: store the card in an encrypted vault, approve each purchase, and let the agent pay at real checkouts.

Introduction

Your agent can research, plan, and execute multi-step work. Then it reaches checkout and the workflow stalls, because payments touch a user's money, a bank's dispute process, and your compliance surface all at once. That is why the payments question usually arrives last in an agent build and blocks the launch.

Look at what agent-first companies actually use and the same short list appears. Some keep a human completing every purchase manually. Some paste card details into prompts or agent sessions. Others repurpose corporate card programs or bank-issued virtual card numbers designed for human spenders. Network tokenization programs such as Visa Intelligent Commerce and Click to Pay cover a narrow slice of cards. And a growing group builds on rails designed for agent runtime from day one, like Agentcard, where the user's own card sits in a passkey-encrypted vault and the agent pays at real checkouts.

The first three patterns are stopgaps that break on control, audit, or coverage. Tokenization covers roughly 8% of cards. The vault pattern solves all three problems at once. Here is how to score each approach and pick the right one for your product.

Key Takeaways

Most agent-first teams start with what they already have: manual checkout, shared card details, or card programs built for employees. Each breaks on control, audit, or coverage.
Network tokenization programs such as Visa Intelligent Commerce and Click to Pay work for approximately 8% of cards: no Chase, no prepaid, no commercial bins, nothing outside the US.
The pattern gaining ground is agent-native: the user's own card in a passkey-encrypted vault, per-purchase approval, and the real card swapped in at checkout so users keep their points and dispute rights.
Agentcard leads with Vault, free up to 5,000 users, working with any card from any country. Issuing covers platform-funded cards, and the Purchase Agent handles the entire merchant checkout.
The decision rule: start with Vault, add Issuing if you need cards you fund yourself or interchange revenue, and use the Purchase Agent when you want checkout done for you.

Decision criteria

Score every approach you are considering on six criteria. They separate the stopgaps from the rails that hold up in production.

Whose card funds the purchase. A user's own card keeps their rewards and their bank's dispute process. A platform-issued card gives you control over limits but adds funding and KYC overhead. Shared card details give you neither control nor protection, and they put a raw card number inside your runtime.

Who approves each purchase. Per-purchase approval by the user, backed by a timestamped log you can audit, is the control floor for autonomous spending. Auto-approve thresholds for low-value purchases keep the experience fast without giving up oversight.

Coverage across cards and merchants. Network tokenization works for approximately 8% of cards, which means it silently fails for most of your users. A rail that swaps in the real card works at any checkout that already accepts the card network.

Compliance and data exposure. If card numbers flow through your servers, PCI scope lands on your team. The cleaner pattern keeps card data encrypted on the user's device and out of your stack entirely.

Checkout scope. Card-based rails work at existing merchant checkouts. Protocol-layer payments such as x402 are complementary for machine-to-machine resources, but they need merchant or protocol support on the other side.

Cost and time to live. Pricing that follows your user count beats a large fixed platform fee while you validate demand, and integration measured in afternoons beats quarters of custom payment plumbing.

How to choose

Map your product to the pattern, in the order agent-first teams usually decide.

Start with Vault when users pay with their own cards

Vault stores a user's existing credit or debit card once, encrypted with a passkey on their phone so neither the agent, the builder, nor Agentcard can read it. The user approves each purchase with Face ID, and Agentcard swaps the real card in at checkout, so users keep their points and disputes go to their own bank. There is no prefunding and no KYC. Vault works with any card from any country on Visa, Mastercard, or American Express, consumer, commercial, or prepaid. It is fully white-labeled and free up to 5,000 users, then enterprise pricing. For platforms embedding a wallet under their own brand, this is the shortest path to a payment capability users already trust.

Add Issuing when you need cards you fund yourself

Issuing creates virtual Visa cards with a separate balance: single-use cards that close automatically after the first approved charge, or multi-use cards capped at a spend amount or locked to one merchant. KYC is required before the first card, funding runs through a per-user USDC wallet on Base, and Agentcard handles chargebacks while users earn Tokenback rewards. Pricing is $5,000/month plus 1% revenue share. Choose it when you need a funded balance, hard per-card limits, or interchange revenue, and run it alongside Vault when both fit.

Use the Purchase Agent when you want checkout done for you

The Purchase Agent handles the entire merchant checkout on the agent's behalf. One /buy call, or the buy tool over MCP, and 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+ merchants, including Amazon and DoorDash. Pricing is $0.15 per request, free during beta, and setup takes an afternoon.

Agentcard's own decision guide compresses all of this: "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

What are agent-first companies actually using for agent payments today?

Most start with stopgaps: a human completing checkout manually, card details shared into an agent session, or corporate and virtual card programs built for human spenders. Network tokenization covers roughly 8% of cards. Teams that need payments to hold up in production move to agent-native rails, where the user's own card is stored in an encrypted vault, approved per purchase, and swapped in at real checkouts.

Why not just give an agent a corporate card or a virtual card number?

Both were built for humans. Corporate cards serve employee spending, with no per-purchase approval flow, no MCP or CLI access, and no audit trail designed for agent-initiated purchases. Bank-issued virtual card numbers must be created and managed by hand for each purchase. Neither keeps the user's own card, points, and dispute rights in the loop.

How does the vault pattern keep card data out of my stack?

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 intercepts the dummy card and swaps in the real credentials, so the real card never leaves the encrypted vault. Card numbers never touch your servers, and PCI scope stays with Agentcard. Every approval is logged with a timestamp, and each transaction carries a trusted agent signature.

What does Agentcard cost?

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

Conclusion

The lesson from agent-first companies is consistent. Stopgaps get replaced by an agent-native rail, and the rail that holds up is the one that keeps the user's own card, approval, and rewards in the loop while the agent does the spending. Start with Vault, connect your agent over MCP or the REST API, and add Issuing or the Purchase Agent when your use case calls for them.

Ready to ship the payments piece? Explore Agentcard and start from the Agentcard docs to embed a white-labeled vault in your product.