Type "create a card" in Claude, and you'll get a Visa card a few seconds later. But this card isn't for you; it's for AI. A product demonstration video demonstrating the generation of virtual cards for large models is generating a frenzy of discussion on X. Applying for a virtual card for online transactions isn't anything new for ordinary people, but applying for virtual credit cards for AI is another exciting development in the payment sector after the rise of Agent payments. If you follow this field, you'll find similar excitement every few months. In September 2025, it was the x402 protocol, with Coinbase and Cloudflare collaborating to turn the HTTP 402 status code into a native payment channel for Agent payments. In October 2025, Visa and Mastercard simultaneously released their Agent payment protocols. Now it's virtual cards. The Agent payment sector remains highly fragmented; each provider solves a part of the problem, but no one has yet offered a complete solution. This article attempts to answer several questions: What exactly is an Agent virtual card? How does it differ from x402? What problems can virtual cards solve, and what problems can't they solve? And where are the opportunities in this field? Kite is the first Layer 1 blockchain for AI agent payments. This underlying infrastructure enables autonomous AI agents to operate in environments with verifiable identities, programmable governance, and native stablecoin settlements. Founded by senior AI and data infrastructure experts from Databricks, Uber, and UC Berkeley, Kite has completed a $35 million funding round, with investors including PayPal, General Catalyst, Coinbase Ventures, 8VC, and several top investment funds. What is an Agent's Virtual Credit Card? You certainly don't want to hand over your credit card directly to an Agent, just as many people don't install OpenClaw on their primary computer. The reason is simple: the risk exposure is uncontrollable. Ordinary credit cards have no single-transaction spending limit, no merchant restrictions, and cannot be easily cancelled. Once the agent malfunctions or is attacked, your entire account is exposed to risk. Agent virtual cards are not like issuing an ordinary credit card to AI; they are programmable, restricted payment credentials. Each card can have a spending limit set, and if the agent's spending exceeds the preset amount, the transaction will be automatically rejected. You can also suspend or close any card at any time without affecting your underlying bank account. In short, the core value of virtual cards lies in controllability. Taking AgentCard, the virtual card project that attracted attention yesterday, as an example, it operates through a Model Context Protocol (MCP) server. The process is as follows: You first recharge the virtual card provider, and Agent calls an MCP tool, such as "create_card(amount=$50)", and the provider's API immediately issues a one-time prepaid Visa card with the amount precisely locked at $50. The backend has several layers. The MCP server handles authentication and API calls with fintech companies. The agent cannot see the true source of your funds. The card is issued by the issuing bank on the Visa network, and funds are deducted from your pre-linked bank account or credit card. The agent receives a temporary card number for web checkout or API payment, and the card is automatically deactivated after use. Setup takes approximately 5 minutes and can be completed via CLI or configuration file. The entire process is highly isolated; your real card information is never exposed to the agent. What problem does a virtual card aim to solve? What people call "agent-based commerce" is mostly just adding an extra step to the human shopping process. You use ChatGPT to research a pair of headphones and then place your order—that's the first layer. Or you let ChatGPT find the headphones and click to buy, and you confirm the payment—that's the second layer. Or you set a condition for the agent to automatically buy when the price drops below a certain number—that's the third layer. In all three scenarios, the agent uses your payment credentials, and major card organizations and AI labs are already building the underlying protocols for these scenarios. The truly interesting scenarios begin at the fourth layer. Your agent needs to call the API of another large model, such as switching from Anthropic to a cheaper inference model, purchasing an expensive dataset to complete a research task, or hiring another agent to handle a sub-task. In these scenarios, the agent isn't swiping your card for you; it needs its own payment credentials. Currently, developers buy these things for the agent and then grant it access. This isn't called an agent; it's called a proxy. To completely liberate humans (but not completely relinquish trust), a restricted agent payment method is needed, and the programmable nature of virtual cards perfectly meets this need. Why has this problem only emerged now? Because three conditions are currently ripe. The first condition is demand. The booming lobster installation campaigns in major cities around the world are a case in point. The second condition is the supply side. Stripe Issuing already allows the creation and management of virtual cards via API, with complete technology and protocols. The third condition is the involvement of card organizations. Visa and Mastercard simultaneously released their Agent payment protocols, Cloudflare participated in the development of technical standards, and Fiserv became one of the first major payment processors to support these protocols, completing the platformization process. From grassroots entrepreneurs to card organization giants, everyone saw the same thing at the same time: agents need their own financial infrastructure. The Structural Limitations of Virtual Cards Virtual cards solve today's problems, but they inherit an old problem from bank card networks: slow settlement. Most people outside the payments industry don't realize that when you swipe your card at a store, the merchant doesn't receive the money immediately. It takes a day, a few days, and up to 30 days for cross-border payments to receive funds. Visa itself doesn't move the funds; the bank does, and bank settlements are slow and expensive. This problem is amplified for agents. If your agent is buying a lot of tokens from Anthropic and business suddenly takes off, you might run out of funds before the revenue arrives. Virtual cards also have a second limitation: cross-border costs. Cross-border payments using traditional bank cards involve currency exchange, intermediary bank fees, and compliance reviews. For agents that need to access APIs and services globally, these friction costs accumulate rapidly. The third limitation is insufficient programmability. As your agent's transaction volume increases and the number of sub-agents you need to manage grows, the flexibility of virtual cards becomes inadequate. With virtual cards, the main agent must apply for one for each sub-agent individually, or create a new card each time for a few dollars. Understanding these limitations helps explain why the x402 protocol gained attention a few months ago. The essence of x402 is to bypass bank card networks and complete on-chain payments directly at the HTTP layer using stablecoins. For example, suppose your agent needs to call a paid API to obtain real-time data. With virtual cards, you would first need to create a card, register an account on the service provider's website, bind the card, subscribe to a monthly plan, obtain the API key, and then configure it for the agent.
Using x402, the Agent directly sends an HTTP request, the server returns a 402 status code and price, the Agent automatically signs a USDC transfer, the server confirms receipt and returns the data. No registration or subscription is required; payment is based on usage.
The two are not mutually exclusive. Virtual cards are suitable for Agents to use at merchants that accept Visa, for online shopping, SaaS subscriptions, and paying cloud service bills.
Catherine
Weatherly
Kikyo
Anais