DEV Community: Sylvia

Why AI Agents Need Virtual Cards

Sylvia — Mon, 27 Jul 2026 06:24:09 +0000

AI agents can browse products, compare prices, call APIs, and fill out checkout forms. Paying for something is where the workflow becomes awkward.

Many online stores still expect the same inputs they have used for years: a card number, expiration date, security code, billing address, and sometimes an additional verification step. The agent may understand the page, but it still needs a payment method that the merchant accepts.

Giving the agent access to a personal or company card is the simplest approach technically. It is also difficult to justify from a security perspective.

A normal card is a long-lived credential connected to a much larger balance or credit line. The agent only needs enough spending power to complete the current purchase. Those two permission scopes do not match.

Virtual cards provide a way to narrow that gap.

The problem with sharing a normal card

Imagine an agent has been asked to buy a $25 software license.

To finish the task, it needs to enter payment details into a checkout page. If we give it a regular card, we are not only authorizing that $25 purchase. We are exposing a credential that may remain valid for months and may be accepted by thousands of other merchants.

That creates several problems.

First, the spending limit belongs to the card account, not the task. A card with a $5,000 limit does not become a $25 credential just because the prompt says, “Do not spend more than $25.”

Second, card details can appear in places where they should not: browser traces, screenshots, tool arguments, application logs, or model context. Even when the agent behaves correctly, another component in the workflow may store the information.

Third, it is hard to revoke access cleanly. If the credential is reused elsewhere, cancelling it affects the user’s other payments as well.

This is really a permissions problem. The payment method gives the agent more authority than the task requires.

What an agent actually needs

For most purchases, an agent does not need ongoing access to a payment account. It needs a temporary credential with a few constraints:

A maximum amount
A limited lifetime
A defined number of uses
A connection to the task the user approved

A simplified authorization might look like this:

{
  "purpose": "Purchase the selected software license",
  "maximum_amount": 25,
  "currency": "USD",
  "maximum_uses": 1
}

This object is not a card. It represents the permission that should exist before a card is created.

The card can then be issued from that permission rather than treated as the permission itself. If the task is cancelled, the credential can be closed without affecting the user’s main card. If it is leaked after the purchase, it should no longer be usable.

This makes a virtual card closer to a temporary capability than a traditional financial account.

Why not use an agent-native payment protocol?

Virtual cards are not the only way for agents to pay.

When an API supports a programmable payment method, the payment can happen directly in the request flow. An HTTP service might return a price, the agent authorizes the charge, and the request continues after settlement. Direct stablecoin payments and protocols such as x402 are also better suited to machine-to-machine transactions than browser checkout.

The problem is coverage.

An agent may need to buy a SaaS plan, book a service, or order a physical product from a merchant that has not built an agent-specific payment API. The merchant already accepts Visa or Mastercard and has little reason to replace its checkout system for one new type of client.

In that situation, a virtual card acts as an adapter. The agent gets a programmable credential, while the merchant receives an ordinary card payment.

It is not the most native payment rail for an agent. It is the one that works with existing commerce infrastructure.

A practical checkout flow

A reasonable implementation separates payment authorization from browser automation.

The flow might work like this:

The agent selects a product and calculates the expected total.
It requests a budget for that purchase.
The user or an existing policy approves the request.
A virtual card is created with the approved amount.
The agent fills out the checkout page.
The final order is checked before submission.
After the charge, the card is closed.

The preview step is important because the price shown on a product page is not always the amount charged at checkout.

Taxes, delivery fees, tips, currency conversion, subscriptions, and optional extras can change the total. A card may be capped at $25, but that does not tell us whether a $24.99 charge is actually the purchase the user wanted.

Amount controls reduce financial exposure. They do not verify intent.

The system still needs to compare the merchant, product, final amount, and purchase terms with the original request.

FluxA AgentCard as one implementation

FluxA AgentCard applies this model using single-use virtual cards created from a FluxA Wallet.

An agent can request a card for a particular amount and associate it with an approved mandate:

fluxa-wallet card create \
  --amount 25.00 \
  --mandate mand_abc123

The card can then be used on a supported browser checkout. After the transaction completes, it is invalidated, and any unused balance is returned to the wallet. FluxA also records card creation, charges, closure, and the related mandate.

The useful part of this design is not simply that the card is virtual. Many banking products already provide virtual cards.

The relevant properties for an agent are that the card:

Is created when a task needs it
Has a fixed amount
Is intended for one transaction
Can be revoked independently
Has a separate activity record

FluxA’s broader wallet flow also separates agent access from payment authorization. An agent may be connected to the wallet, but it still has to operate within a user-approved budget and purpose.

That distinction matters because authentication alone does not answer the payment question. Knowing which agent sent a request does not tell us whether the requested purchase is allowed.

Browser automation is the less predictable part

Issuing a card is fairly structured. Checkout pages are not.

Each merchant can use different forms, embedded payment frames, address validation, login requirements, and anti-bot systems. Even two stores running on the same commerce platform may behave differently because of plugins or custom scripts.

FluxA currently approaches this through a preview-and-execute checkout flow. The agent first fills the page without submitting it and saves the checkout state for inspection. The documented validated surfaces currently include standard Shopify checkout routes and direct Stripe-hosted payment pages.

When the page presents CAPTCHA, OTP, 3D Secure, a login wall, or an unsupported widget, the workflow stops and hands the current state back to a person instead of reporting a successful order. ([FluxA][1])

That is a more realistic approach than assuming every checkout can be fully autonomous.

Some verification steps exist specifically to confirm that a human cardholder is present. An agent payment system should be able to pause without losing the cart, filled form, or transaction context.

Virtual cards do not solve every payment risk

A single-use card reduces the damage caused by credential leakage, but it does not make the whole transaction safe by default.

An agent can still:

Select the wrong product
Choose an annual plan instead of a monthly plan
Purchase from a misleading domain
Accept an unwanted recurring subscription
Enter an incorrect delivery address
Pay a merchant that does not match the user’s request

These are not card-security failures. They are failures to understand or enforce intent.

There are also operational questions.

How much price variation should be allowed after taxes are calculated? What happens when a merchant places a temporary authorization hold larger than the final charge? Where does a refund go after the original card has been closed? Should the agent be able to retry a declined transaction with the same credential?

A production system needs policies for these cases. “The card has a spending limit” is only the beginning of the design.

Card data also remains sensitive while the card is active. Single-use credentials should still be kept out of prompts, persistent model memory, analytics events, and ordinary application logs. Ideally, the browser automation layer receives the details through a protected channel without exposing them directly to the model.

When a virtual card makes sense

Virtual cards are useful when the agent must interact with a merchant that only supports conventional card checkout.

They are less useful when both sides already support a machine-native payment method. Paying an API through a browser with a card would add unnecessary steps if the same service can charge per request through x402 or another programmable rail.

A practical payment stack may therefore support several methods:

Card payments for existing online merchants
HTTP-level payments for APIs
Direct transfers for agent-to-agent settlement
Human handoff for transactions requiring additional verification

The agent can select the rail based on what the seller supports rather than forcing every transaction through the same process.

The main design principle

The important idea behind an AgentCard is not that an AI gets its own branded card.

It is that payment access should be created from the task.

A user approves a purpose and a budget. The system turns that approval into a restricted credential. The agent uses it during checkout, and the credential is removed when it is no longer needed.

That is a much smaller security boundary than sharing a permanent card and relying on the agent to follow instructions.

Virtual cards will not replace agent-native payments. They solve a different problem: allowing agents to purchase from merchants that still use the existing card network, without giving those agents unrestricted access to the user’s primary payment credentials.

What Is an AI Agent Wallet?

Sylvia — Thu, 18 Jun 2026 07:54:18 +0000

Give an AI agent a real job and it hits a wall fast. It wants to call a paid API, pull a dataset, maybe rent some GPU time, and every one of those wants an account, a card on file, and a human to click "confirm." The agent can plan the entire task. It just can't pay for any of it.

That gap is what an "agent wallet" is supposed to close. It's also one of the noisier corners of the whole agent stack right now, so let me try to say what one actually is without the brochure version.

So what is an AI agent wallet, really?

It's a wallet an agent can spend from on its own, inside limits you set, without a person approving each transaction.

That's the whole idea. The "inside limits you set" part is doing far more work than the demos admit, and it's usually the part they skip. A normal crypto wallet holds keys and signs whatever you tell it to. A normal card assumes a human is watching the screen. An agent wallet has to assume nobody's watching, which changes the design from the ground up.

Why can't the agent just use my credit card?

You can hand an agent your card number. People do. It works right up until it doesn't. The card has no idea it's being driven by software, it has no per-task limit it understands, and the first time the agent loops on a bad retry or gets prompt-injected into buying something stupid, your only backstop is the fraud department.

The card networks know this, which is why they've been busy. Visa shipped its Trusted Agent Protocol and Mastercard shipped Agent Pay, both essentially ways to prove "a real agent is acting for a real user" at checkout. The point was never to give agents your raw card. It's to give them a scoped, throwaway credential instead.

What does the wallet actually have to do?

A few unglamorous things:

Hold value, usually a stablecoin like USDC, sometimes a card line.
Sign payments by itself, fast, no human in the loop.
Refuse to spend outside the rules you gave it.
Leave an audit trail, so when it spends $40 you can see exactly why.

The first two are mostly solved. The last two are where everyone is still fighting.

How does an agent actually pay for something?

The cleanest answer in 2026 is x402, Coinbase's revival of the long-dead HTTP 402 Payment Required status code. The flow is almost boring, which is the best thing about it:

# 1. Agent asks for a paid resource
GET /v1/market-data HTTP/1.1
Host: api.example.com

# 2. Server says: pay first
HTTP/1.1 402 Payment Required
{ "amount": "0.01", "asset": "USDC", "network": "base", "payTo": "0x..." }

# 3. Agent signs a payment, retries with the proof in a header
GET /v1/market-data HTTP/1.1
Host: api.example.com
X-PAYMENT: <signed-payment-payload>

# 4. Server verifies on-chain and returns the data
HTTP/1.1 200 OK

No account, no API key, no signup. The agent reads the price off the response and decides. x402 has the most real traffic of any of these protocols today, which is why it keeps showing up everywhere. It's also stablecoin-only, so if your money lives on cards, you need something else underneath it.

Who's actually building this, and what do they get right?

There are a lot of names, and it's easy to feel lost. The useful way to read the space: it's a stack, not a winner.

Authorization (can this agent spend, and how much?): Google's AP2, now handed to the FIDO Alliance, with its signed "mandates."
Settlement (move the money): x402 for stablecoins, Stripe's MPP for a fiat-and-crypto mix.
Checkout (buy from a store): OpenAI and Stripe's ACP. Worth knowing this one stumbled when OpenAI pulled Instant Checkout in March.
Card networks sit underneath all of it as the credential layer.

If you only track one company here, track Stripe. It co-authored MPP, it's a founding member of the x402 Foundation, and it co-built ACP. Developers trust it for a reason, and it's standing in nearly every room.

How do you stop an agent from spending money it shouldn't?

This is the actual interesting problem, and the field has quietly agreed on one idea: don't hand the agent a reusable credential. Hand it a single-use, scoped one.

Stripe's Link Agent Wallet issues one-time-use cards. Mastercard's Agentic Tokens are scoped to one agent, one merchant, and a set spending mandate. Fireblocks shipped a spend-governance extension straight into x402. Different rails, same instinct: give the agent just enough authority to do the one thing, and nothing left over for the next mistake.

The card-rails version of this is where I spend my days. FluxA, an AI agent payment platform I work on, does it with a single-use virtual card per task plus an Intent-Pay mandate that pins down the ceiling, the merchant, and the purpose before the agent ever moves a cent. Same pattern as the Shared Payment Token and the Agentic Token, pointed at cards instead of stablecoins. I bring it up as one shape of the answer, not the answer. Pick whichever rail your money already lives on.

What's still broken

Plenty.

The liability question is wide open. x402 defines how a payment happens, not who's on the hook when an agent buys the wrong thing or gets talked into it. There's no law for that yet, so everyone is writing their own house rules.

The wallet layer is fragmented. Coinbase, Stripe, Fireblocks, and a dozen smaller players each ship a different idea of "agent financial identity," and there's no single standard a builder can safely assume. Daily volume is also still thin next to the noise, even though the protocols process real money.

None of that means the idea is wrong. It means it's early in the genuinely useful sense, where the primitives work and the conventions don't exist yet.

If you're building one

The honest starting move is small. Pick x402 for service calls. Decide whether your money is stablecoin or card. Then put a hard spending cap in front of the agent before you ever let it run unattended.

The wallet matters less than the limit. Get the limit wrong and nothing else you bolt on will save you.

How can my AI agent pay for stuff on its own?

Sylvia — Wed, 10 Jun 2026 07:24:54 +0000

AI agents can decide what to buy but mostly can't pay for it. The practical ways to give an agent payment authority, with tradeoffs and working code.

You hand your agent a task: pull the latest pricing for three competitors and summarize it. It finds the report. The report sits behind a $4 paywall. The agent stops. It can read, reason, and plan, but it has no way to complete a checkout, because nobody gave it a way to pay.

The opposite failure is worse. You paste a card number into the agent's environment so it can buy what it needs, walk away for an hour, and come back to a list of charges you never approved.

Both failures come from the same gap. The hard part of agent payments is not moving money. It is giving an agent enough authority to pay for what the task needs, and no more than that.

What does an AI agent need before it can pay?

Two things have to be true before an agent can pay without a human in the loop:

A credential it can use programmatically. Not a card you typed in once, but something an automated process can present at the moment of purchase.
Bounded authority. A hard ceiling on what that credential can spend, set before any money moves, so autonomy never means an open tab.

Most of the difference between the approaches below comes down to how each one handles the second point.

What are the ways an AI agent can pay?

Agentic commerce has produced a handful of answers, and they mostly differ in how they bound what the agent is allowed to spend. Five worth knowing:

1. Hand it your card. The naive version. You drop a real card number into the agent's context and hope it behaves. There is no per-task limit, no merchant restriction, and your full balance is exposed if the credential leaks or the agent loops. This also breaks the terms of most card programs. Skip it.

2. Scoped virtual cards. Issue a virtual card per agent or per task with a hard cap, a short lifetime, and optionally a merchant lock. The agent pays any merchant that accepts cards, and your exposure is capped at the limit you set. Good when the things your agent buys live in the normal fiat world. The tradeoff is that you depend on card rails and an issuer, and it works only where cards are accepted.

3. Programmable wallets and stablecoins. Give the agent a wallet, custodial or smart contract based, funded with a small stablecoin balance and governed by spend rules. Settlement happens in something like USDC. Good for paying APIs and other software directly. The tradeoff is that the counterparty has to accept stablecoin payment, so this fits machine to machine more than buying from a typical online store.

4. x402: pay per request over HTTP. x402 reuses the HTTP 402 Payment Required status code so any endpoint can ask for payment inline. The agent makes a normal request, gets a 402 describing what is owed, pays from a wallet, and retries. No account signup, no OAuth, no API key exchange. This is the cleanest fit for per call API and MCP tool payments, and there is a working example below.

5. Mandate based protocols. Emerging standards like Google's Agent Payments Protocol (AP2) and Stripe's Shared Payment Tokens give an agent a scoped, pre authorized credential tied to what it is allowed to buy. They get there differently: AP2 backs the credential with a verifiable mandate, while Stripe issues a token scoped to a specific purchase. Both target the same pattern, where a human approves the bounds once and the agent transacts inside them. The tradeoff is maturity. The ecosystem is still forming, so support is uneven.

How does an agent pay for a single API call?

The reason x402 reads well as a starting point is that the payment logic disappears into a wrapped fetch. Your agent code does not change.

// npm install @x402/fetch @x402/evm viem
import { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

// The wallet your agent pays from. Fund it with a small USDC balance.
const signer = privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`);

const client = new x402Client();
registerExactEvmScheme(client, { signer });

// Wrap fetch once. 402 responses are now handled for you.
const fetchWithPayment = wrapFetchWithPayment(fetch, client);

// The agent just makes the request. If the endpoint asks for payment,
// the wrapper pays and retries automatically.
const response = await fetchWithPayment("https://api.example.com/paid-endpoint", {
  method: "GET",
});

const data = await response.json();
console.log(data);

Here is what happens when the endpoint wants payment:

The first request comes back as 402 Payment Required with the amount, asset, and recipient.
The wrapper reads those requirements and checks the amount before paying, so you can reject anything above the ceiling you set.
It signs a payment from your wallet and resends the request with the payment attached.
The endpoint verifies it and returns the resource.

That ceiling is the bounded authority piece. Fund the wallet with a small balance, reject any payment above your per request limit, and a single call cannot drain it. If you want to try the full loop, x402 ships a runnable buyer and server example you can stand up locally before pointing an agent at anything real.

Which payment method should my agent use?

A rough decision path:

Buying from normal merchants that take cards? Scoped virtual cards.
Paying APIs, tools, or other agents per call? x402 or a programmable wallet.
Need a human to approve a budget once and let the agent transact within it? Watch the mandate based protocols, and prototype on whichever has support today.

In practice you end up mixing them. A single agent might carry a capped virtual card for fiat purchases and an x402 wallet for API calls. The annoying part is the bookkeeping: two things to fund, two sets of limits, two places to look when you audit what it actually spent. This is the part FluxA is built to handle, with agent wallets and disposable virtual cards plus x402 and AP2 support sitting behind one set of spend policies, so the cap lives in one place instead of three. If you would rather not run that plumbing yourself, that is the reason to reach for something like it.

How do you stop an AI agent from overspending?

An agent should never hold a payment credential larger than the task in front of it. Autonomy is safe only when the spending limit is enforced before the money moves, not reconciled after. Every approach above is really a different answer to one question: where, exactly, is the cap enforced?

Note: parts of this post were drafted with help from an AI assistant, then reviewed and edited before publishing. Run the code example yourself before relying on it.