Soon, a lot of checkouts will happen without somebody hovering over a Buy button.
That is easy to picture when the agent is hunting down a pair of shoes. It gets more interesting when a procurement agent renews a SaaS tool, a logistics agent purchases cold-chain data midway through a shipment, or a software-building agent buys a domain, hosting and an API subscription to finish the job it was given.
The payments industry is moving in that direction. Mastercard launched Agent Pay in 2025, then introduced Agent Pay for Machines in June 2026. Visa is rolling out Visa Intelligent Commerce and has announced work to bring Visa payment capabilities into OpenAI experiences. Google’s open Agent Payments Protocol, or AP2, has pulled card networks, payment providers and technology companies toward a shared approach for agent-led transactions. [1] [2]
That does not mean every chatbot can now roam the internet with your personal Visa or Mastercard. Thankfully. We are still early, and the real story is not giving an agent a card in the first place.
It is about giving an agent a controlled right to spend through cards, tokenized credentials, corporate virtual cards, bank-account rails, stablecoins and other methods. The card is the rail. The valuable part is the permission layer around it.
Agentic payment is delegated purchasing authority, not autonomous access to a wallet.
Checkout turns into a policy decision
Digital commerce spent years trying to make payment disappear. Cards on file, wallets and one-click checkout worked because the buyer was assumed to be right there, identifiable, looking at the order.
An agent changes that. It may find an offer, build a cart and ask to pay while its owner is asleep. Or while the employee who set it up is in a meeting. Or after the person who made the original request has forgotten about it entirely.
So the question changes too. It is no longer just, “Is this card valid?” It becomes, “Was this agent allowed to make this purchase, from this merchant, at this price, under these conditions?”
A chat transcript is not enough. “Get me running shoes” is not a good audit trail for a $600 order from a retailer the customer has never used. The system needs to know the product, total amount, merchant, delivery terms, timing, payment method and the boundaries the owner set.
AP2 calls the evidence behind that decision a mandate. In a human-present transaction, the user gives the agent an initial instruction, looks over the cart and approves the final order. In a delegated transaction, the user can set the rules in advance: buy concert tickets when they go on sale, but only in these sections, only before this date, and never above this price. The signed mandate is meant to tie the authority to those conditions and preserve a record from intent through checkout and payment. [3]
Visa and Mastercard use different labels, but they are heading toward the same basic shape. Visa talks about spending limits, merchant-category restrictions, approval thresholds and agent identity signals. Mastercard talks about registered agents, tokenized credentials and verifiable intent backed by explicit consent. [1] [2]
That is the new checkout. Not a button. A policy engine.
What an agent payment flow actually looks like
The glossy version is, “Tell an agent what you want and it buys it.”
The useful version is a bit more careful.
1. Define the job — A person or business asks an agent to buy something or finish a bounded task. Check: category, budget, preferred merchants, location, timing and whether it may act without another prompt.
2. Create authority — The instructions become a purchase policy or signed mandate. Check: who approved it, which agent can use it, when it expires and what needs a human exception.
3. Search and assemble — The agent compares options and builds a proposed cart or transaction. Check: product fit, price, stock, total cost, delivery, cancellation and return terms.
4. Approve or validate — The user signs off on the exact cart, or the system checks it against pre-approved rules. Check: amount, merchant, category, date and quantity stay within policy.
5. Present payment — The agent uses a tokenized or scoped payment credential on the relevant rail. Check: the credential is valid for this agent, task and transaction, instead of exposing a reusable card number.
6. Authorize and fulfill — Merchant, processor, issuer and network handle authorization and fraud checks. Check: agent identity, user intent, risk signals, receipt, delivery and a record for reconciliation or disputes.
Each player only sees part of the deal. The agent needs enough room to do the job. The merchant needs to tell a real shopping agent apart from a scraper, an abusive bot or a fraud attempt. The issuer still needs to decide whether to authorize the charge. The customer needs a receipt, an explanation and an easy way to stop or dispute a purchase.
Visa’s Trusted Agent Protocol is directed at the merchant side. It uses signed information that is specific to the merchant and the stated purpose, time-bound, and intended to resist replay. The merchant can receive the agent’s stated intent, selected customer-recognition data and payment information appropriate to its own flow. [5]
But this part is worth underlining: agent identity is not customer authority. Knowing that a request came from a registered agent is useful. It does not prove the customer wanted that item from that seller at that price. A solid payment design needs both proofs.
There are two ways to approve an agent purchase
The first is familiar: human in the loop. The agent researches, negotiates or fills the cart, then puts the finished order in front of the person for approval. That should be the default for high-value, hard-to-reverse or unusually personal purchases. Travel. Financial products. Medical supplies. Gifts. Anything that starts a recurring commitment. Anything likely to cause regret.
The second is delegated approval. Here the human approves the rules, not every individual charge.
“Reorder printer toner from approved suppliers when inventory drops below 10 units, up to $300 per month.”
“Book the usual hotel near the client office if the nightly rate is under $275.”
“Buy the ticket if it matches the price and seating rules I already set.”
That is where agents earn their keep. No one wants a push notification for every low-stakes, repeatable purchase. But delegated approval only works when the permission is narrow enough to mean something and visible enough to manage.
Here is the control model I would expect serious teams to ship.
Control model for serious teams
Per-transaction limit — Example: no purchase over $150 without confirmation. Why: a bad decision stays small.
Time-boxed authority — Example: permission ends after 72 hours or one completed order. Why: less standing access; fewer forgotten permissions.
Merchant or category allowlist — Example: buy office supplies from named vendors only; no cash equivalents, gift cards or gambling. Why: “buy something useful” stops being dangerously vague.
Budget and velocity caps — Example: maximum $1,000 per month and five purchases per day. Why: contains loops, compromised agents and faulty instructions.
Exact-cart approval — Example: require a signed approval once the final price, tax and delivery terms are known. Why: keeps a human checkpoint for decisions that deserve one.
Step-up authentication — Example: ask for a passkey or biometric confirmation when an exception appears. Why: confirms that a real person, not a prompt or a hijacked session, expanded the authority.
Kill switch and logs — Example: revoke the agent’s credential immediately and keep a readable decision record. Why: makes recovery possible after something goes wrong.
A corporate agent should not be handed a general-purpose card number in a prompt, a database field or a tool configuration. That is credential sharing with fancier language. Give it a limited-use payment instrument, a budget and a revocable policy instead. Visa describes tokenized credentials and purchase-intent capture in its developer materials. Mastercard’s program is built around agentic tokens, registered agents and controls linked to verified intent. [2] [6]
The unglamorous limits still matter most
There is real momentum here. There is not a universal, settled operating model.
Coverage is patchy. The agent platform, the issuer or credential provider, payment network, processor, merchant and merchant experience all need to line up. Visa says Intelligent Commerce is still being developed and deployed, and that not every described feature may appear in the final product. Mastercard is working with a wide partner group. That is meaningful progress. It is not universal acceptance across the web. [1] [4] [7]
An approved card charge does not mean the agent made a good choice. An agent can misunderstand a request, follow hostile content on a webpage, invent a constraint or simply optimize for the wrong thing. Payment controls limit the damage. They do not make a weak buying agent suddenly discerning. Good product data, constrained tools, confirmation rules and hard testing still matter.
Prompt injection now has a spending consequence. If an agent can browse untrusted pages and call a payment tool, a malicious instruction embedded in a page is not just an information-security problem. It could become an order. Treat web content as untrusted input. Keep payment authority separate from browsing context. And enforce policies outside the model, not through a hopeful instruction that says, “Please be careful.”
Disputes have not gone away. The card system already has chargebacks, fraud monitoring and issuer controls. Agentic commerce adds more actors to the chain: the user, agent provider, merchant, merchant agent, credential provider, issuer, network and orchestration layer. AP2 names authorization, authenticity and accountability as the problems its shared protocol is trying to address. A cryptographic record should help. It will not settle every argument over wrong goods, altered instructions or poor service. [3]
Payment is only one part of commerce. Tax, identity checks, age restrictions, delivery, returns, subscriptions, contracts and customer support remain stubbornly human problems. An agent getting a payment approved is not the same as a merchant delivering a good outcome.
Privacy calls for restraint. Agents may know a lot about a person or a business. A merchant does not need the buyer’s full reasoning history or every personal preference to fulfill an order. Share the minimum needed to complete the transaction. Keep payment credentials and purchase history compartmentalized.
Where the first real value may show up
The early wins will not be agents with unlimited buying power. They will be agents with small, specific authority doing boring work well.
Recurring consumables. Approved B2B procurement. Travel inside a policy. Software services purchased by a build or operations workflow. Small machine-to-machine payments for data, compute, API calls or logistics events. Mastercard’s Agent Pay for Machines is aimed at high-frequency, low-value and programmatic transactions, with settlement across cards, accounts and stablecoins. [4]
Consumer shopping will get the attention because it is easy to see. Business workflows may be where the economics land first. A person can spend ten minutes comparing a jacket. A business cannot spend ten minutes reconciling every $2 service call in an automated supply-chain workflow.
For merchants, the question is not simply whether to accept “AI payments.” The real question is whether the merchant can recognize a legitimate agent, provide reliable product and policy data, return a structured offer, honor a documented authorization and support the customer after the order. Block every bot and you will miss real demand. Trust every bot and you will invite a mess. The useful middle ground is authenticated, attributable automation.
For product teams, the question is simpler: what is the smallest permission that lets this agent do something genuinely useful? Start there. Make the authority easy to inspect. Build the exception path before the autonomous path. And make the system capable of explaining what it bought, why it was allowed to buy it and how to undo it.
The payment rails are coming into view. The advantage will not go to the company that gives an agent a credit card. It will go to the company that gives the agent just enough authority to help, and no more.