Virtual Cards vs. Full Payment Infrastructure: Why Single-Use Cards Alone Fail AI Agents

A virtual card answers one question: what does the agent pay with. Lane answers the other one: how the purchase actually happens. Single-use cards alone fail AI agents because a card cannot sign in, cannot complete a merchant checkout, cannot prove who the agent is, and carries no record of what the user approved. Full payment infrastructure adds identity, intent, and execution.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. Card issuance is one component inside that stack, not a substitute for it.

This comparison is written for teams who have already found a virtual card API, wired it up in an afternoon, and then discovered that their agent still cannot buy anything. The card was never the hard part.

What does a virtual card actually solve?

A virtual card API is a genuinely useful primitive, and it is worth being precise about what it delivers. Given an API call, you get a card number, expiry, and security code that can be spent up to a limit, optionally locked to a single transaction or a single merchant.

• Spend control: a hard ceiling per card means a misbehaving agent cannot spend more than the amount you provisioned.
• Blast radius: single-use cards mean a leaked number is worthless after one charge, which is a real improvement over handing an agent a corporate card.
• Attribution: one card per task gives you clean per-task accounting without parsing merchant descriptors.
• Speed to first call: most card APIs are a single POST, and some ship an MCP server so an agent can request a card conversationally.

Those are real benefits. If your agent needs to pay a metered API, top up an ad account, or cover a subscription on a service you already have credentials for, a card API may be the entire solution you need.

Why do card-only setups break down in production?

The failure is not that virtual cards are bad. The failure is that a payment credential is the last five percent of a consumer purchase, and card-only setups leave the other ninety-five percent to the builder. Four specific things go wrong.

The agent still cannot get through checkout

A consumer purchase is not an API call. It is an account, a cart, an address, a delivery window, a tip, a promo field, a shipping method, and a submit button. As Lane's founders put it: a checkout is really a form, and agents don't do forms.

Handing an agent a card number does not get it past any of that. The agent still has to sign in to the merchant, and modern sign-in means a one-time code sent to a phone or email the agent does not control. Merchants also deploy bot detection from vendors like Cloudflare, Akamai, and DataDome, plus challenge flows, precisely to stop unidentified software from submitting forms. A card in hand does nothing to change how the merchant classifies the requester.

High-volume single-use issuance looks like fraud

This is the failure mode teams do not anticipate. Merchant risk systems are tuned to detect card testing: many distinct card numbers, short-lived, low dollar amounts, arriving from correlated sources in a compressed window. That is an almost exact description of an agent platform issuing a fresh single-use card for every task.

The result is not a clean error message. It is a soft decline at authorization, or a merchant-side risk hold, or an order that looks accepted and then quietly cancels an hour later. The card was valid. The pattern was the problem, and the pattern is a property of the architecture, not of any individual purchase.

A valid card that pattern-matches to card testing is still a declined card.

Declines are only half of the failure mode. The other half is step-up: many merchants respond to an unfamiliar card by adding verification, a challenge, a one-time code, an extra confirmation screen. Every step-up reinserts the human into a flow the user delegated precisely so they would not have to be in it.

Working infrastructure orchestrates cards the way merchants expect to see them instead. In Lane's funded flows, a merchant keeps a managed card on file that is authorized for an incremental amount per order, rather than being handed a brand-new number every time. The merchant sees a returning customer, not a parade of strangers.

There is no consent trail

A card number is an anonymous bearer credential. It says someone may spend up to this amount. It does not say what the user agreed to buy, at what price, from which merchant, or when they agreed to it.

That gap becomes concrete the first time a customer disputes a charge. If the only record is "the agent had a card and used it," the platform has no defensible answer to "I never approved this." Lane closes the gap with an intent object: the user's prompt becomes a structured, line-item purchase contract that the user approves before execution. That approved contract is the record that exists before the charge, and the agent is physically unable to buy anything outside its terms.

Because Lane carries authorization information through to the card networks, the user also keeps their bank's normal liability protections. Whatever else happens, they are still protected by their bank. A raw card number handed to an agent gives you none of that structure.

Funding and identity are still unsolved

The last problem is who pays. If your platform issues the card, your platform is funding the purchase and then collecting from the user, which pulls you into flow of funds, refund liability, and working capital you did not plan to provide. Lane's bring-your-own-card model avoids this: the user's existing card is tokenized in Lane's PCI-compliant vault, the agent never sees the card number, and no end-user KYC is required.

Identity is the parallel gap. Merchants and CDNs increasingly want to know which agent is knocking. Lane's executor signs every request using HTTP Message Signatures (RFC 9421) with an Ed25519 key published in a self-hosted key directory, verified against Cloudflare's Web Bot Auth crawl test, and Lane is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. A card number carries no identity claim at all.

What does full payment infrastructure include?

Full payment infrastructure for AI agents is four layers, and a working purchase needs all four. Card issuance sits in the third.

1. 1

   Identity. The merchant can cryptographically verify that the requester is a known, accountable agent rather than an anonymous script. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry.

2. 2

   Intent. The user's request becomes a structured, line-item contract with merchant, items, price ceiling, and scope, approved before anything executes. Terms are enforced throughout execution, not just checked once at the start.

3. 3

   Wallet. A payment credential exists and is spendable under those terms. With Lane that is either the user's own tokenized card or a Lane-issued single-use virtual Visa card, which is live in production pilots for funded and incentive programs.

4. 4

   Execution. Something actually completes the purchase at the merchant: sign-in, cart, checkout, submit, confirmation. Lane executes the checkout and returns a result the agent can relay back to the user.

Any vendor that gives you one of these four is solving a real problem. The question is how many of the remaining three you are prepared to build yourself.

How do card APIs and Lane compare capability by capability?

Rows describe the category, not any single vendor. Some card APIs ship pieces of adjacent layers, and pricing and coverage change quickly in this market.

When is a card API alone genuinely enough?

Being honest about this matters, because the wrong answer costs teams months either way. A card API is the right and sufficient choice in a specific shape of problem: the destination already accepts a card over an API, the account already exists, and the volume is low enough that issuance patterns do not trip risk systems.

• Machine-to-machine spend: paying for compute, model inference, data feeds, or metered APIs where checkout is a JSON body, not a form.
• Internal tooling: an agent operating inside your own accounts, on your own money, with your own staff able to intervene.
• Developer sandboxes: demos and prototypes where you need a spendable number today and merchant coverage is not the point.
• Existing subscriptions: topping up or renewing services where the card is already on file and no new checkout happens.

AgentCard is a reasonable example of this category done well: a virtual card API for agents with single-use cards and an MCP interface. Best for fast card issuance inside developer tools. It does not execute checkout or manage the merchant interaction, and it does not claim to.

The line is consumer merchants. The moment your agent needs to buy from DoorDash, a Shopify store, Amazon, an airline, or a restaurant, you have left the territory a card API covers.

What does Lane do differently?

Lane treats the card as one field in a larger transaction, and owns the transaction. In Lane's model the builder writes the conversation and the product experience, and Lane handles identity, the consent contract, the credential, and the execution.

Concretely, that means a user in your product says what they want, your agent submits an intent to Lane, the user sees a scoped approval prompt rendered natively in your own interface and confirms it with a biometric or passkey the same way they confirm Apple Pay, and Lane executes the purchase. Lane is invisible to the end user. There is no redirect, and no third-party brand appears in your flow.

This is running in production today for food delivery ordering on DoorDash and for e-commerce checkouts on Shopify stores and Amazon. Travel and restaurant reservations are built and rolling out. Lane is expanding across Visa and Mastercard rails, with Mastercard Agent Pay support in progress.

“An agent with a card on file is an open wallet without control. An agent with no card is a dead end.”

What should you ask a vendor before choosing?

These five questions separate a card API from payment infrastructure faster than any feature list. Ask them in a demo and watch which layer the answer comes from.

1. 1

   Who completes the checkout? If the answer is "your agent does," you are buying a credential, not a purchase.

2. 2

   What does the merchant see? Ask whether the merchant can verify the agent's identity, and what happens when a challenge or one-time code appears.

3. 3

   Where does the money come from? Clarify whether you are funding purchases and reimbursing yourself, or whether the user's own card is being spent.

4. 4

   What is the record of consent? A spend limit is not consent. Ask for the artifact that shows what the user approved, item by item, before execution.

5. 5

   Whose brand does the user see? Ask whether approvals render inside your product or bounce the user to a hosted page.

Which should you pick?

Pick a card API when the destination speaks HTTP and the account is already yours. Pick full payment infrastructure when a human is the beneficiary, a consumer merchant is the counterparty, and the purchase has to survive risk systems, sign-in, and a dispute six weeks later.

The two are not really competitors. Lane issues cards too. The difference is that with Lane the card arrives attached to identity, an approved intent, and an execution path, which is what turns a spendable number into a completed order.

If you already have a virtual card working and your agent still cannot complete a purchase, the missing pieces are identity, intent, and execution. Lane provides all three alongside the card, through one integration.