AI agents are starting to complete real purchases, which raises a practical question. How does the agent pay without you handing it your credit card? Pasting your real number into a prompt is the worst option. It gives a piece of software standing, unlimited access to your money with no scope and no clean way to revoke it. The better answer is a virtual card built for agents. This post explains what that means and how it works from the first tool call to the completed checkout.
Single-use virtual cards for AI agents
A single-use virtual card is a real card number, expiry, and CVC generated for one specific purchase and closed once that purchase clears. It runs on the normal card networks, so any merchant that takes Visa or Mastercard accepts it. What makes it safe for an agent is what it lacks. It has no history, no future, and no path back to your real card.
Authoryze issues one of these for every approved purchase. On the primary rail the card is issued through Basis Theory over Visa Intelligent Commerce and Mastercard Agent Pay, which are the card networks' own programs for agent-initiated payments. The card is network tokenized and tied to the funding card you enrolled, but the number the agent receives is not your number. Privacy.com is available as an alternate rail, and cards issued that way are Mastercard, single-use, and scoped the same way.
Three properties do the work. The card is sized to one approved amount. It can be drawn by the agent exactly once. And it is short-lived, the exact window is returned with the card, so a number that leaks from a log is worth one transaction at one amount for a short window, not standing access to your account.
Why not a regular virtual card from your bank?
Many banks and card services let you create virtual card numbers, and people sometimes hand one of those to an agent. It is better than a real card, but it misses most of what makes agent payments safe. The card is reusable, so an agent stuck in a retry loop can charge it again and again. The limits live in your bank's app, where nothing knows what the agent is buying or why. There is no approval step, so a purchase you would have vetoed simply happens. And there is no record that ties a charge back to the agent's request. A virtual card for AI agents needs to be issued per purchase, after rules are checked, with an audit trail attached.
How it works end to end
Here is the full path a purchase takes through Authoryze.
The agent requests a purchase. Your agent calls request_purchase over MCP with the merchant domain, the amount, a description, a justification, and the merchant's country code. It can include an idempotency key so a retry after a timeout returns the original result instead of producing a second card. No card exists at this point.
Rules are evaluated on the server. Authoryze checks the request against the agent's per-transaction limit, its daily, weekly, and monthly caps, its total budget, and its allowed and blocked merchant domains. It then checks any aggregate caps you set across all of your agents combined. A request that breaks any rule is denied with a reason, and no card is issued. The agent cannot skip this step by rephrasing the request, because the check happens outside the agent's context.
The request is approved or sent to you. If it passes every rule and is under the agent's auto-approve threshold, it is approved immediately. If it passes the rules but is over the threshold, it goes to you by email for review, and it waits there until you approve or deny it from the email or your dashboard. Either way the agent gets a request ID and polls check_status until the request resolves.
The card is issued and retrieved once. When the request is approved, the agent calls retrieve_card with that request ID. Authoryze draws a single-use virtual card from the issuer at that moment, sized to the approved amount, and returns the number, expiry, and CVC inline in that one response. The draw is atomic. A second call with the same request ID returns already_retrieved instead of showing the card again, whether that second call is a retry, a bug, or someone probing a leaked request ID. Authoryze never stores the card number. It keeps the last four digits and a provider token for the audit log and nothing else.
The card expires. The response carries an expires_at timestamp, short-lived by design, that sets the actual window for that draw. The agent completes checkout inside that window. After the charge clears, or the window closes, the card is dead. There is nothing left to revoke.
The controls that go with the card
The card is half of the design. The other half is control over when a card gets issued at all. Per-agent limits keep one agent inside its budget. Merchant allowlists keep it at the vendors you chose, with subdomain matching so allowing amazon.com also covers aws.amazon.com. Aggregate caps across all your agents stop two agents from each staying under their own limit while together spending more than you intended. The auto-approve threshold decides which purchases you see before they happen. And the audit trail records every request, rule check, decision, and card issuance.
One thing worth saying plainly. Authoryze does not hide the single-use virtual card from the agent. The agent needs it to check out, and it lands in the agent's tool call history like any other tool result. What Authoryze isolates is your funding source, meaning the enrolled card behind Basis Theory or your Privacy.com key. If the single-use card leaks, the damage is bounded to one amount at one merchant for a short window. The security section of the docs spells out what is and is not covered.
Common questions
Is a virtual card for AI agents the same as a network token?
Close. On the primary rail, the single-use virtual card is a network-tokenized credential issued through Visa Intelligent Commerce or Mastercard Agent Pay. You do not deal with the networks directly. Authoryze handles enrollment through Basis Theory and hands your agent a card it can type into any checkout form.
Does the agent ever see my real card number?
No. Your real card is tokenized in your browser by Basis Theory during enrollment and never reaches Authoryze's servers or any MCP response. The agent only sees the single-use virtual card for the specific purchase it was approved for.
What if the agent loses the card before checkout?
It cannot get it back. Any second call to retrieve_card returns already_retrieved. The agent starts a new request, which goes through the same rules and, if needed, the same approval. This is deliberate. A card that can be shown twice is a card that can be stolen twice.
Can I use this with Claude or ChatGPT?
Yes. Authoryze is an MCP server. Claude, ChatGPT, Claude Code, Codex, Cursor, and any other MCP client connect over OAuth or an API key. The steps for each client are in the MCP configuration docs.
Want your agent paying with a single-use virtual card instead of your real one? Create an Authoryze account and connect your first agent in about ten minutes.