There are two fundamentally different approaches to AI agent payments, and they solve different problems. Virtual cards give agents access to the existing Mastercard network — any merchant, any checkout flow, anywhere cards are accepted. The x402 protocol gives agents native HTTP-layer payments — machine-to-machine, no card number, no checkout flow, payment semantics built directly into the request/response cycle.

Most writing about agent payments treats these as competing approaches. They are not. They are complementary, and any serious agent payment infrastructure needs both. Here is why, and when to use each.

What x402 Actually Is

The x402 protocol is built on HTTP 402 Payment Required, a status code that has existed in the HTTP specification since HTTP/1.1 (RFC 7231) but was "reserved for future use" for decades. The x402 protocol gives that status code a concrete implementation: when a server has a paid resource, it responds to unauthenticated requests with HTTP 402 and includes payment instructions in the response.

The flow works like this:

  1. A client (human or machine) makes an HTTP request to a paid resource.
  2. The server responds with HTTP 402 Payment Required. The response includes headers or a body specifying the price, accepted payment methods, and a payment endpoint.
  3. The client processes the payment instructions, completes the payment through the specified method, and receives a payment proof (typically a token or receipt).
  4. The client retries the original request, including the payment proof in the request headers.
  5. The server verifies the payment proof and returns the requested resource.

The entire transaction happens at the HTTP layer. No card numbers. No checkout pages. No redirect flows. No human interaction. The payment is as native to the HTTP request/response cycle as authentication headers are to authenticated APIs.

This is a fundamentally different model from card-based payments, which were designed for human-initiated transactions and involve card networks, merchant acquirers, authorization flows, and settlement delays measured in days.

What Virtual Cards Actually Are

Virtual cards are programmatically issued Visa or Mastercard numbers that work everywhere the card network is accepted. For AI agent use cases, they typically work like this: an orchestrator or the agent itself issues a virtual card with a specific amount loaded, uses it to make a purchase from a merchant, and the card is discarded after the task.

AgentCard issues virtual debit cards that are single-use by default, with the loaded amount acting as a hard spend ceiling. The card number, expiration, and CVV are real Mastercard credentials that work at any Mastercard merchant — online checkout forms, SaaS subscription pages, cloud service billing portals, or any other payment form that accepts a card number.

The fundamental property of virtual cards for agent payments is universality: they work everywhere the existing payment infrastructure works. The fundamental limitation is that they inherit all the friction of that infrastructure — card numbers that need to be secured, checkout flows designed for humans, settlement that takes days, and merchant category codes that sometimes misclassify purchases.

When x402 Is the Right Choice

x402 makes sense when both sides of the transaction are machines and the payment is for a discrete, well-defined unit of value delivered via HTTP.

API-to-API micropayments

An AI agent that needs to call a paid API endpoint — a data provider, a compute service, a specialized model — should ideally pay per-request at the HTTP layer rather than pre-purchasing credits with a card. x402 makes this possible: the agent hits the endpoint, gets a 402, pays, and gets the response. No API key management, no credit balance to monitor, no subscription to cancel. Each request is a self-contained economic transaction.

Sub-dollar transactions

Card networks have minimum transaction amounts (typically $0.50-$1.00) and per-transaction fees that make micropayments economically irrational. x402 payments can be arbitrarily small because they do not go through card networks. An agent paying $0.002 for a single API call is viable with x402 and absurd with a credit card.

High-frequency, low-value access patterns

An agent that makes hundreds of small API calls per task — checking data sources, running searches, accessing reference material — needs a payment method that scales to high frequency without accumulating transaction fees. x402 handles this natively because the payment is part of the HTTP request, not a separate transaction processed by a card network.

Services designed for machine consumption

The x402 ecosystem is growing among API providers that primarily serve machine clients: data APIs, compute marketplaces, content licensing services, and AI model providers. These services have no checkout page, no shopping cart, and no reason to accept card payments. x402 gives them a payment mechanism that matches their delivery mechanism.

When Virtual Cards Are the Right Choice

Virtual cards make sense when the merchant is a traditional business that accepts Mastercard, which is the vast majority of the commercial internet.

SaaS subscriptions and cloud services

When an agent needs to sign up for a SaaS tool, provision cloud infrastructure, or purchase a software license, the merchant expects a card number. There is no x402 endpoint for AWS, Google Cloud, GitHub, or any mainstream SaaS provider. A Mastercard works at all of them, today, without the merchant needing to adopt any new protocol.

Purchases over $1

For transactions in the $5-$500 range — buying a domain, purchasing a dataset, paying for a service subscription — card-based payments are efficient and well-understood. The per-transaction overhead of card network fees is proportionally small, and the universality of Mastercard acceptance outweighs the elegance of x402.

Merchants that will never adopt x402

The honest truth is that most merchants will not adopt x402 in the near future. A local hosting provider, a stock photo service, a domain registrar — these businesses process card payments and have no incentive to implement a new payment protocol for machine clients. Virtual cards give agents access to these merchants today, without waiting for protocol adoption.

Auditable, attributable spend

Card transactions produce clear records: merchant name, transaction amount, timestamp, card identifier. These records integrate with existing accounting workflows, expense management tools, and audit processes. As I wrote in How AI Agents Make Payments, the ability to attribute agent spend to specific tasks and review it through familiar tools is a practical requirement for production deployments.

The Convergence Thesis

Here is the position I want to stake out clearly: the future of agent payments is not x402 or virtual cards. It is x402 and virtual cards, unified under a single agent-facing interface.

The reason is simple. An AI agent completing a task does not care how payment happens. It cares that payment happens. If the agent needs data from an x402-enabled API, it should pay via x402. If it needs to buy a domain from a registrar that takes Mastercard, it should pay with a card. The agent should not need to know which payment method to use — the infrastructure should route the payment through the appropriate channel based on what the merchant supports.

This is why AgentCard supports both approaches. The x402_fetch MCP tool handles x402 payments: the agent calls it with a URL, and if the server responds with HTTP 402, the tool automatically processes the payment and returns the resource. The create_card MCP tool issues virtual debit cards for merchants that accept cards. From the agent's perspective, both are just MCP tools. The payment plumbing is abstracted away.

This convergence is not hypothetical. It is how agent payment infrastructure needs to work in practice. An agent running a research task might need to:

  1. Pay $0.003 per query to a data API via x402
  2. Purchase a $12 dataset download from a merchant that takes Mastercard
  3. Pay $0.01 to access a paywalled article via x402
  4. Buy a $29 SaaS subscription with a card

Four payments, two protocols, one task. An agent payment platform that only supports one of these protocols handles half the problem.

How x402 Works with AgentCard

The AgentCard MCP server exposes an x402_fetch tool that handles the full x402 flow transparently. When an agent connected via MCP needs to access a paid resource, the interaction looks like this:

  1. The agent calls x402_fetch with the target URL.
  2. The tool makes an HTTP request to the URL.
  3. If the server responds with HTTP 402 Payment Required, the tool parses the payment requirements from the response.
  4. The tool completes the payment according to the server's specified method.
  5. The tool retries the request with the payment proof.
  6. The tool returns the resource content to the agent.

From the agent's perspective, it called a tool with a URL and got back content. The 402 negotiation, payment processing, and retry logic are invisible. This is the right level of abstraction — the agent does not need to understand payment protocols any more than a web browser needs to understand TLS handshakes.

The Adoption Reality

I want to be honest about where x402 is today. The protocol is real, the specification is solid, and the machine-to-machine payment model it enables is genuinely important. But adoption is early. The number of production services accepting x402 payments is small compared to the number accepting Mastercard. This will change — the economic logic of HTTP-native micropayments for API access is compelling enough that adoption will grow. But today, a payment infrastructure that only supports x402 would leave agents unable to transact with the vast majority of the commercial internet.

Conversely, a payment infrastructure that only supports virtual cards leaves agents paying card network fees on $0.003 API calls (which is economically impossible) and unable to pay for resources that only accept x402. As I discussed in the virtual card API comparison, the right approach is to support both and let the infrastructure route payments to the appropriate channel.

The practical advice today: use virtual cards as your primary agent payment method because they work everywhere, and add x402 support for the growing number of services that accept it. Do not wait for x402 adoption to reach critical mass before giving your agents payment access. The merchants they need to pay today accept cards.

Security Comparison

Both approaches have distinct security properties that matter for agent deployments.

x402 security

  • No card credentials to protect: There are no card numbers, CVVs, or expiration dates. Payment proofs are typically one-time tokens that cannot be reused.
  • Per-request authorization: Each HTTP request is authorized individually. There is no persistent credential that, if compromised, enables unlimited future payments.
  • Amount-specific: The payment is for a specific amount for a specific resource. There is no "card balance" that can be drained.
  • Limited merchant set: The attack surface is smaller because x402 payments only flow to servers that implement the protocol, not to any merchant on the Mastercard network.

Virtual card security

  • Credentials require protection: Card numbers, CVVs, and expiration dates are sensitive data that must be encrypted at rest (AgentCard uses AES-256-GCM) and carefully scoped in agent contexts.
  • Spend ceiling is the balance: A debit card's maximum exposure is the loaded amount. Single-use cards with conservative load amounts limit the blast radius of any compromise.
  • Universal acceptance means universal risk: A compromised card number can be used at any Mastercard merchant, not just the intended one. This is why single-use cards with tight spend limits matter — as covered in the MCP payments guide, per-task card issuance limits the exposure window.
  • Human-in-the-loop funding: With AgentCard, the human must approve funding via Stripe Checkout before the card is loaded. This prevents a compromised agent from self-funding.

Neither approach is strictly "more secure" than the other. x402 has better per-transaction security properties (no persistent credentials, per-request authorization). Virtual cards have better universality and more mature fraud detection infrastructure. The secure architecture uses both where appropriate.

Frequently Asked Questions

What is the x402 protocol?

x402 is a payment protocol built on the HTTP 402 Payment Required status code. When a machine client requests a paid resource, the server responds with HTTP 402 and includes payment instructions in the response. The client completes payment programmatically and resubmits the request with proof of payment. The entire flow happens at the HTTP layer with no human interaction.

How does x402 work for AI agent payments?

An AI agent makes an HTTP request to a paid resource. The server responds with HTTP 402, including price and payment instructions. The agent's payment tool (such as AgentCard' x402_fetch) automatically processes the payment and retries the request with proof. The agent receives the resource without needing to understand payment mechanics.

Should I use x402 or virtual cards for AI agents?

Use both. x402 for API-to-API micropayments where the server supports it. Virtual cards for purchasing from any Mastercard merchant. AgentCard supports both through its MCP server — x402_fetch for x402 payments and create_card for card issuance.

Does AgentCard support the x402 protocol?

Yes. The x402_fetch MCP tool handles the full x402 payment flow: detecting 402 responses, parsing payment requirements, completing payment, and retrying with proof. This works alongside card issuance through the same MCP server.

What is the difference between x402 and traditional payment methods for AI?

Traditional payment methods (cards, bank transfers) were designed for human-initiated transactions with settlement delays and authentication flows that assume a human is present. x402 is designed for machine-to-machine payments at the HTTP layer: instant, automated, payment semantics built into the request/response cycle. The trade-off is that x402 only works with services that implement it, while cards work everywhere Mastercard is accepted.