How AI agents pay in 2026: scoped tokens, signed mandates and who carries the risk. Where each payment programme stood in September 2026, what changes for fraud checks and disputes, and a ten-step checkout checklist.
Author
Anichur Rahaman
At 9:12 on a Tuesday, an order reaches the owner of a small electronics shop from a customer's AI assistant: one laptop charger, 49 dollars, paid with a token the customer's bank issued for this shop alone and valid for 30 minutes. There is no card number, no account and no browser session.
Her fraud rules were tuned for people. They see a new device, no mouse movement and a checkout finished in two seconds, so they score the order as high risk and decline it. The same morning, a request that only claims to be an agent in its headers passes her rule for known good automation. She has turned away a real sale and waved through a bot. (This is an illustrative scenario, not a real shop.)
The fix is neither a looser rule nor a stricter one. A checkout that sells to agents asks three questions in order: who is asking, what was the agent allowed to buy, and how risky is this particular order? The rest of this article explains the pieces behind those questions.
Part 1 of this series asked whether an AI agent can find and understand your store. Part 2 asked whether an assistant will recommend it. This part asks the question that decides who gets paid: when the agent is ready to buy, can your checkout say yes safely? Every serious programme in 2026 replaces the card with a narrow, revocable credential and a signed record of what the shopper allowed. Below you will find where each programme stood in early September 2026, and a checklist of what to fix in your checkout now.
This is part 3 of 3 in the series "Selling to AI Agents". Part 1 is Agentic Commerce: How to Sell When Your Next Customer Is an AI Agent. Part 2 is Generative Engine Optimization for Online Stores.
When you pay online, you type a 16-digit number into a form. If an agent did the same, that number would sit inside a model provider's systems, logs and memory. The industry's answer is to give the agent a stand-in.
That stand-in is a tokenised credential. The real card stays with the bank or a wallet. The agent receives a token that is limited to one merchant, a maximum amount and a short time window, and that the shopper can revoke. If it leaks, an attacker holds a permission slip that is already almost used up, not a card.
Tokens are not new. Card networks have used network tokens for years behind mobile wallets and saved cards. What is new is attaching rules to the token: who the agent is, what it may buy and for how long.
Several programmes overlap, and they are not rivals in the way browsers are. Some define how an agent talks to a store, some how permission is proven, and some how the payment is authorised. Here is the public record as of early September 2026.
| Programme | What it covers | Status, September 2026 |
|---|---|---|
| Agentic Commerce Protocol (OpenAI and Stripe) | How an agent starts a checkout and passes a payment token to a merchant | Open standard released in September 2025. OpenAI's Instant Checkout inside ChatGPT was reported retired in March 2026, but the protocol continues, with a spec revision dated April 2026 |
| Stripe Shared Payment Tokens and Agentic Commerce Suite | Scoped tokens limited to a seller, an amount and a time | Launched in December 2025; other payment providers can take part through the protocol's delegated payment specification |
| Agent Payments Protocol, AP2 (Google) | Signed mandates that prove what the shopper authorised | Announced September 2025; handed to the FIDO Alliance for standardisation in April 2026 |
| Universal Commerce Protocol and Universal Cart (Google) | Catalog and checkout standard, plus a cart across Search and Gemini | Standard announced in January 2026; the cart was announced in May 2026 for a US rollout over the summer. Check current availability before you plan around it |
| Visa Intelligent Commerce and Trusted Agent Protocol | Agent tokens, plus signed requests that identify a trusted agent | Announced in October 2025 with merchant and processor partners; developer sandbox open |
| Mastercard Agent Pay | Agentic tokens on existing card tokenisation | First live agentic payments reported in Asia-Pacific from March 2026; its Verifiable Intent framework was contributed to the FIDO Alliance |
Two points matter more than any single row. First, the one programme that tried to put the whole purchase inside a chat window scaled back, while the plumbing underneath it kept moving. Second, the standards bodies are now involved: in April 2026 the FIDO Alliance announced working groups for agent authentication and agent-initiated commerce, starting from Google's and Mastercard's contributions. That usually means the field is converging.
Volumes are still small. Plan for a merchant checkout that can accept an agent, not for a revenue line that depends on one.
A token says "this credential may be charged". It does not say why. A mandate fills that gap. It is a signed record of the shopper's permission, and AP2 splits it into three parts:
Think of a signed purchase order. The shopper authorises a budget, the agent fills in the order, and the signatures tie them together. When a dispute arrives months later, the question "did the customer really agree to this?" has a document behind it.
You will not write cryptography yourself. Your payment provider or platform verifies signatures. Your job is to keep the data a signature depends on stable: the cart you return must match the cart you charge, down to price, tax, shipping and currency. A checkout that quietly adjusts totals after quoting them breaks the chain.
Nobody has fully settled this. Card rules were written for a person at a screen. When an agent buys something the shopper did not mean to buy, it could be fraud, a merchant error or an authorised purchase. I know of no published rule that assigns fault cleanly among the shopper, the agent provider and the merchant across all programmes. Until your provider's terms say otherwise, assume the merchant carries the loss.
The networks are working on it. Signed agent identity and mandates exist so that an issuer can tell "authorised by the cardholder through an agent" from "fraud". Treat that as direction, not guarantee, and read your payment provider's terms for agent transactions before you enable them.
An illustrative example: a shopper tells an agent to buy "a charger for my laptop". The agent buys a model with the wrong connector. The shopper disputes the charge. If your listing stated the connector type clearly and the cart mandate shows what was shown at the time, your evidence is strong. If the listing was vague, the dispute is hard to win and the fault is arguably yours.
Most fraud systems quietly rely on human behaviour: mouse movement, typing speed, a device seen before, a browsing history. An agent has none of that. A legitimate agent order can look like a bot attack, and a real bot attack can borrow an agent's clothes.
Update your rules in four ways:
Put together, the decision for a single agent order looks like this. Identity comes first because the other two checks mean nothing without it. A missing mandate or a high risk score does not have to end in a decline: the shopper can be asked to approve, which turns a doubtful order into a confirmed one.
Many stores answer the bot problem with a blanket block. That worked when every automated visitor was a scraper. Now some automated visitors are shoppers' representatives, and blocking them means losing the order.
The workable approach is triage. First, ask whether the request carries a verifiable identity. Visa's Trusted Agent Protocol and the Web Bot Auth proposal both use HTTP message signatures: the agent signs each request with a private key, and you check the signature against a published public key. Cloudflare announced support for this approach together with Visa and Mastercard in October 2025.
Revisit your robots rules and bot-protection settings too. A rule that blocks "all non-browser user agents" on checkout may already be rejecting legitimate agents.
A person who buys on a site sees the confirmation page. When an agent buys, the shopper sees whatever the agent reports, so your confirmation must be readable by software as well as people.
Refunds deserve special care. If the original payment was a scoped token, refund to the same payment method through your provider, not by a manual transfer.
None of this requires adopting every protocol this quarter. It requires a checkout that is clean enough that adopting one is a small project. Work through the list in order.
The three parts fit together. An agent has to find you (part 1), has to choose you (part 2) and has to be able to pay you without a human fixing the checkout (this part). The common thread is data you can stand behind: accurate products, specific policies, binding quotes and a record of what each customer allowed.
Back to the shop owner at 9:12. With the three checks in place, the 49-dollar charger order takes a different path. The signature verifies, the mandate (one charger, up to 60 dollars) covers the cart, and the valid mandate counts in the risk score's favour. The charge goes through her payment provider, and the confirmation reaches the customer's assistant and inbox within seconds.
The request that only claimed to be an agent fails the first check and never touches her cart. Her rules did not get stricter or looser. They got specific: they now look at who is asking and what they were allowed to do, instead of how a human would click.
Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.
About the Author
Anichur Rahaman
Continue Reading
