AI agents are no longer just reading data and generating text. They are booking travel, purchasing API credits, subscribing to data feeds, and paying contractors — autonomously, without a human in the loop for each transaction. This changes payment infrastructure requirements in ways that conventional card products were never designed to handle.
This guide covers the complete technical picture: what makes agent payments architecturally different from human payments, how AgentCard layers funding, card issuance, and card delivery together, and how to walk through a real end-to-end flow from the CLI to an MCP-connected agent making a purchase.
What Makes AI Agent Payments Different
Human payments involve deliberate intent, human verification steps, and a person who can respond to fraud alerts or authorization challenges. AI agents have none of these properties. An agent that encounters a 3DS challenge or a CAPTCHA during checkout will stall or fail. An agent with access to a credit card that has no spending ceiling can rack up charges until someone notices.
The differences that matter most for infrastructure are:
- No interactive authorization flows. Agents cannot complete SMS one-time passwords, biometric prompts, or phone-based fraud challenges. Any payment flow that might trigger these must be avoided or pre-cleared.
- Unbounded execution risk. A bug in agent logic, a prompt injection in a webpage the agent reads, or a runaway loop can trigger dozens of payment attempts in seconds. Spending limits are a hard technical control, not a soft policy.
- Auditability requirements. When an agent spends money, you need a machine-readable record of what was purchased, from which merchant, at what time, correlated with the agent session that triggered it. Standard card statements do not provide this.
- Programmatic issuance and revocation. Agents may need ephemeral cards for one-off tasks, or cards that are scoped to a specific domain. Issuing and cancelling cards must be scriptable, not dependent on a human visiting a web portal.
These requirements rule out giving agents access to your personal or business card. They call for a dedicated payment layer built for programmatic use — which is exactly what AgentCard provides.
The Three Layers: Funding, Issuance, and Delivery
Every agent payment flows through three distinct layers. Understanding them helps you reason about where controls live and where failures can occur.
Layer 1: Funding
Each card you issue is funded at creation time via a Stripe checkout. You set the amount per card, so your total agent spend exposure is bounded by how much you load onto each card.
Layer 2: Card Issuance
You issue individual virtual debit cards loaded with a specific amount. You set the amount when you run agent-cards cards create --amount N, which opens a browser to complete the payment and then issues the card immediately. The card is immediately active and carries a real PAN, expiration date, and CVV that work at any Mastercard-accepting merchant online.
Card issuance is the control layer. You can:
- Issue a card with a $5 limit for a low-stakes task
- Issue a $500 card for a research agent that buys data
- Issue and immediately cancel a card to test your tooling
- List all active cards and their balances at any time
Layer 3: Card Delivery to the Agent
The issued card's details need to reach the agent at the moment the agent needs to make a purchase. This is where the MCP integration comes in. Rather than embedding card credentials in an environment variable or system prompt — both of which are risky — the agent calls MCP tools at runtime to fetch what it needs, under access controls you have configured.
The MCP server runs locally (or as an HTTP endpoint), holds your API credentials, and exposes tools to the agent: list_cards, get_card_details, and check_balance. Transactions are tracked automatically via Stripe Issuing webhooks — no manual logging required. The agent never holds raw card data in its context longer than necessary for a single operation. For the full protocol specification, see the Model Context Protocol spec.
Real Walkthrough: From CLI to Agent Purchase
Let's walk through the complete flow for a concrete scenario: you want a Claude agent to purchase a $49 API subscription on your behalf.
Step 1: Install the CLI
npm install -g agent-cardsStep 2: Authenticate
$ agent-cards login
Opening browser for authentication...
Magic link sent to you@example.com
Waiting for confirmation...
✓ Authenticated as you@example.comStep 3: Issue a Card
Issue a $50 virtual debit card — enough to cover the $49 subscription with a small buffer:
$ agent-cards cards create --amount 50
✓ Card issued in 8 seconds
Card ID: card_abc123
Last 4: 7823
Expires: 03/2026
Amount: $50.00
Status: activeThe card is now live and ready to use. The full PAN and CVV are available via agent-cards cards details card_abc123 when you need them, or via the MCP get_card_details tool when your agent needs them.
Step 4: Configure MCP
Register the AgentCard MCP server with a single command:
claude mcp add --transport http agent-cards https://mcp.agentcard.sh/mcp \
--header "Authorization: Bearer <your-token>"Replace <your-token> with your AgentCard API token (found in ~/.config/agent-cards/config.json after login). Your agent now has access to the four payment tools.
Step 5: Agent Executes the Purchase
You instruct Claude: "Subscribe to the DataFeed Pro plan at datafeedpro.com — there's a $49/month option. Use an Agent Card." Claude will:
- Call
list_cardsto see available cards - Call
check_balanceon a card with sufficient funds - Call
get_card_detailsto retrieve the PAN, CVV, and expiration - Navigate to the checkout page and complete the form
Step 6: Verify After the Fact
$ agent-cards cards list
ID LAST4 BALANCE STATUS
card_abc123 7823 $1.00 active
card_def456 1234 $25.00 active
$ agent-cards cards details card_abc123
Card ID: card_abc123
Last 4: 7823
Balance: $1.00
Spent: $49.00
Status: active
Created: 2026-03-02T14:32:11ZThe $49.00 charge is reflected in the card balance.
The Four MCP Tools in Detail
The AgentCard MCP server exposes four tools. Here is what each does and when an agent uses it.
list_cards
Returns an array of all cards in your account. Each entry includes the card ID, last four digits, current balance, and status (active, cancelled, expired). Agents use this as the first step when they need to find an appropriate card for a task.
// Example response
[
{
"id": "card_abc123",
"last4": "7823",
"balance": 50.00,
"status": "active"
}
]get_card_details
Returns full card details for a given card_id, including the PAN, CVV, and expiration date needed to complete a purchase. This is the most sensitive tool and the one where access control matters most. The MCP server only returns these details for cards in your account and only when the server process is authenticated with your API key.
check_balance
Returns the current balance for a specific card_id. Agents should call this before attempting a purchase to confirm sufficient funds, avoiding a declined transaction that might confuse the agent or trigger a retry loop.
Security Model
Spend Limits as a Hard Control
Each virtual debit card has a fixed balance that cannot be exceeded. Unlike a credit card, there is no credit line to draw on. Once a card's balance reaches zero, it declines. This is a technical guarantee, not a policy — no configuration error can make a card overspend.
Single-Use Cards
For maximum isolation, issue a card for each task and cancel it immediately after. The cost is just a few seconds of CLI time. This ensures that a card number compromised during one task cannot be reused. It also makes your audit trail trivially simple: one card, one task, one set of transactions.
Encrypted PAN and CVV
Card details are stored encrypted at rest using AES-256-GCM in the AgentCard backend. They are transmitted over TLS and only decrypted in the MCP server process, which runs locally on your machine. The raw PAN and CVV are never written to disk by the MCP server and are not logged in agent conversation history by default. This approach aligns with OWASP LLM Top 10 (LLM08: Excessive Agency) guidance on limiting tool access to minimum-required permissions.
Local MCP Process
The stdio MCP transport means the MCP server runs as a subprocess of your AI client on your own machine. There is no network hop between the AI client and the MCP server. The only network calls are from the MCP server to the AgentCard API. This limits the attack surface significantly compared to a remote MCP endpoint.
API Key Scoping
Your AgentCard API key is stored in your local environment (typically in a config file at ~/.config/agent-cards/config.json). The MCP server inherits this from the environment. You can rotate the key at any time from the dashboard or CLI without affecting issued cards.
Common Patterns
Per-Task Ephemeral Cards
Issue a card at the start of an agent task, pass the card ID to the agent via a system prompt or tool call, and cancel it when the task ends. This is the highest-security pattern and works well for batch jobs.
Shared Pool Cards
Maintain a small number of cards with defined balances that multiple agent sessions draw from. Use check_balance before each purchase to manage contention. This works well for agents that make many small purchases across a long session.
Budget-Gated Agents
Issue a card at the start of a week or sprint with the total budget for that period. The agent can spend freely within that limit. When the card balance runs out, the agent can call list_cards, notice no card has sufficient funds, and escalate to a human rather than failing silently.
What Agents Can Buy
AgentCard work anywhere virtual debit cards are accepted for card-not-present (CNP) online transactions. The cards are issued on the Mastercard network and follow standard CNP authorization flows. Common agent use cases include:
- API credits and compute (OpenAI, Replicate, cloud services)
- Data subscriptions and market feeds
- Domain registration and hosting
- Stock photography and asset licensing
- Software licenses and SaaS subscriptions
- Research databases and academic papers
Merchants that require 3DS strong customer authentication or phone verification for new cards may not work for fully autonomous agents. Most developer-facing SaaS products do not require 3DS for standard card-not-present transactions.
Limitations to Know
No payment solution for agents is without constraints. The main ones to plan for:
- No recurring billing. virtual debit cards work for initial subscription charges. Renewal charges on exhausted cards will decline. For subscriptions you want to recur, issue a new card before each renewal and update the card on file.
- No refunds to card. If a merchant issues a refund, it typically goes back to the card. If the card has been cancelled, the refund flow depends on the merchant and card network. Avoid cancelling cards for transactions that may be disputed.
- CNP-only. These are virtual cards. They cannot be used in physical point-of-sale terminals or ATMs.
Getting Started
The fastest path to an agent that can make payments:
- Install:
npm install -g agent-cards - Sign up:
agent-cards signup - Issue a test card:
agent-cards cards create --amount 5 - Add MCP:
claude mcp add --transport http agent-cards https://mcp.agentcard.sh/mcp --header "Authorization: Bearer <your-token>" - Ask your agent to check its available cards: "What AgentCard do I have available?"
For a step-by-step tutorial with screenshots, see How to Give an AI Agent a Credit Card. For expense tracking and reconciliation once agents are spending, see AI Agent Expense Tracking. To understand how to model budgets and enforce limits across multiple agents, read Setting Spending Limits for AI Agents.
If you are evaluating which agents are production-ready for autonomous spending tasks, Which AI Agents Can Spend Money covers the landscape as of early 2026. For a survey of emerging payment protocols for agents — including x402 and AP2 — see The AI Agent Payment Protocol Landscape.
Frequently Asked Questions
Can an AI agent use a real credit card?
AI agents should not be given access to real credit cards with revolving credit lines. Instead, virtual debit cards with defined spending limits are the correct approach. This prevents runaway charges, limits blast radius if an agent misbehaves, and lets you audit every transaction programmatically.
How does an AI agent access card details securely?
Through the AgentCard MCP server, AI agents can call tools like get_card_details and check_balance without the PAN or CVV ever being stored in the agent's context window or conversation history. The MCP server mediates all access and enforces authorization.
What happens if an AI agent overspends?
Each virtual debit card issued via AgentCard has a hard spending limit set at issuance time. Once the balance is exhausted, the card declines automatically. No debt can accumulate. You can also issue single-use cards that you cancel after the first successful transaction.
Which AI agents work with AgentCard?
Any agent that supports the Model Context Protocol (MCP) can use AgentCard. This includes Claude Desktop, Cursor, and custom agents built on frameworks like LangChain or AutoGen that have added MCP client support.
How long does it take to issue a card?
Card issuance typically completes in under 10 seconds via the agent-cards CLI or API. The card is immediately active and ready to use for online purchases.