Agentic commerce: how an AI agent proves you agreed to buy

When an AI agent buys something for you, the hard problem isn't moving the money — it's proving you agreed. Every payment system in use today was built on an assumption that an agent quietly breaks: that a human is sitting at the checkout, looking at a screen, clicking the button. Take the human out of that moment and you don't just lose a click — you lose the evidence that anyone authorised the purchase at all. That's the actual problem agentic commerce is solving right now, and the answer the industry has converged on is a chain of cryptographic signatures rather than a stored card.

This is already happening to your traffic

Adobe Analytics, working from more than 1 trillion visits to US retail sites, reported in June 2026 that AI-referred traffic to those sites has grown 1,324% since October 2024 — when they first started tracking it — and was still up 138% year over year in May 2026.

The more interesting number is what that traffic does when it lands. Adobe found it converted 54% better than traffic from non-AI sources, with those shoppers spending 53% more time on the site and browsing 23% more pages per visit. A year earlier the comparison ran the other way. Whatever you think of the hype, the visitors arriving through an assistant are currently your better visitors.

And the standards are consolidating fast. On 28 April 2026, Google released v0.2 of the Agent Payments Protocol and donated it to the FIDO Alliance — the same body behind passkeys — with Mastercard contributing its Verifiable Intent work. FIDO stood up two technical working groups for agentic authentication and payments. Sixty organisations were named as contributors, including card networks, processors and marketplaces. Governance moved out of one company's hands in under a year.

The assumption that just broke

The protocol's own documentation is blunt about why any of this is needed:

The world's existing payments infrastructure was not designed for a future where autonomous, non-human agents act on a user's behalf.

Think about what your fraud system actually checks: device fingerprint, session history, typing and scrolling behaviour, whether a 3-D Secure challenge can be answered. Every one of those signals is a proxy for the same question — is a human really here? An agent fails all of them, honestly. So the merchant gets an ugly choice: decline a genuine, high-intent sale, or approve it and absorb the risk with no idea who authorised what.

The specification breaks the underlying gap into three questions that are worth reading slowly, because they're the whole design brief:

• Authorization — "What verifiable proof demonstrates that the user granted the agent the specific authority to make this particular purchase?"
• Authenticity — "How can a merchant or payment processor be certain that the agent's request accurately reflects the human user's true intent?"
• Accountability — when something goes wrong, "who is accountable? The user who delegated the task? The developer of the shopping agent? The merchant?"

Notice that none of these are about encryption or fraud scoring. They're about evidence. Today, if an agent buys the wrong thing, there is no artefact anywhere that records what the human actually agreed to.

The mechanism: a signed grant, not a saved card

Here's the shape of the fix, in plain terms.

Instead of handing an agent a card that works for anything, forever, you sign a mandate: a small, tamper-evident document that says what you authorised. The protocol defines two — a Checkout Mandate covering what's being bought, and a Payment Mandate covering what's being charged — and each exists in two states.

Say you tell an assistant: buy me a yoga mat under ₹3,000, but only from a seller who can deliver before Friday.

If you're there when the cart is ready (a "human-present" flow), the agent assembles the basket and shows it to you on a trusted surface. You approve it, and that approval is signed. The result is a closed mandate: proof tied to one specific, finalised cart. The merchant isn't taking your agent's word for it — they can verify what you saw and agreed to.

If you're not there — you're asleep, the item is out of stock, you want it bought the moment it's back — the agent instead repeats the conditions back to you and you sign those. The mandate stays open, carrying, in the spec's words, "the list of conditions under which the [agent] can fulfil the user's order." Those constraints are structured data, not a vibe: which line items are allowed, which merchants are allowed, what the ceiling is. Later, when the conditions are met, the agent binds its own endorsed key to the transaction as proof of possession — no human needed at that moment, because the human already signed the rules.

Two details make this meaningfully different from "a card on file with a spending limit":

1. The proof travels with the transaction. The merchant and the processor each receive something they can verify independently. The protocol's goal is "a non-repudiable, cryptographic audit trail for every transaction" — which is exactly what a chargeback argument needs and exactly what card-on-file doesn't have.
2. A grant gets used up. After a purchase completes, the receipt narrows what's left: the agent "reduces the scope of the open mandate based on the receipt, often preventing future presentations entirely." One authorisation, one purchase. It can't be quietly replayed next week.

Two layers, not two rivals

It's easy to read the landscape as a standards war. It mostly isn't, because the two prominent efforts solve different halves.

The checkout layer's endpoints are "REST and MCP compatible" — so if you've already built an API an agent can use, you're closer than you think. Two of its design choices matter more than the wire format: businesses "maintain their customer relationships as the merchant of record, retaining control over which products can be sold, how they're presented, and how orders are fulfilled" — you don't become a supplier to someone else's storefront — and credentials reach the agent "without exposing underlying payment credentials," so it handles a scoped token, never the customer's actual card.

Consent proof plus a callable checkout. They compose.

What to actually do about it

If you sell anything online, the honest priority list is short and mostly boring:

1. Make your catalogue machine-readable. An agent that can't parse your prices, stock and delivery windows can't recommend you. This is the step with a return today, standards or no standards.
2. Make checkout callable, not just clickable. If the only path to a purchase runs through your JavaScript, an agent has to impersonate a browser to buy from you. That's worse for both sides.
3. Decide your policy on agent traffic deliberately. Right now your fraud rules are deciding it for you, and they're voting no.
4. Keep the mandate and the receipt. They're your dispute defence. Treat them like signed contracts, because that's what they are.
5. Don't hand an agent a stored card and call it agentic commerce. That's the thing the whole standards effort exists to replace.

Our opinion

The genuinely interesting part of agentic commerce isn't the shopping — it's that we're finally getting a portable format for delegated consent. "This human authorised this software to do this specific thing, within these limits, and here's the proof" is a primitive that's been missing from the web for thirty years. Retail is just where the money forced the issue first. Expect the same shape to show up in procurement, renewals, expense approval and anywhere else an agent acts with someone else's authority.

We'd also say plainly: most businesses should not be implementing either specification this quarter. It's v0.2, four months into community governance, with working groups still forming — betting your roadmap on the final wire format is premature. What isn't premature is the half that pays off either way. A machine-readable catalogue and a clean checkout API are useful the moment an assistant tries to buy from you, and they stay useful if every one of these standards gets renamed twice.

One caution worth stating directly. The reason this is being built with signatures rather than shared credentials is that giving an agent broad, standing access to a payment instrument is genuinely dangerous — an agent's instructions can be influenced by the content it reads, which is a problem nobody has fully solved. Scoped, expiring, provable authority isn't bureaucratic overhead here. It's the containment.

How Ashvara helps

We build the layer this actually runs on: catalogues and checkout flows exposed as clean, versioned, well-documented APIs that a machine can call without guessing, with authorisation modelled explicitly rather than inherited from whoever's logged in.

That's ordinary backend and API work joined to how we think about AI systems — and the useful version of it starts well before any protocol decision. If you're wondering whether an assistant could complete a purchase on your site today, or what your fraud rules are currently doing to that traffic, tell us what you're seeing and we'll take a look.

Sources: Agent Payments Protocol — executive summary and agent authorization framework; Agentic Commerce Protocol; FIDO Alliance on the AP2 donation; Adobe Analytics retail data as reported June 2026. Both specifications are early and moving — check the current version before implementing.