Who Vouches for the Bot? Agent Checkout Authentication

Agent checkout authentication has a settled half and an unsettled half, and merchants keep conflating the two. The settled half is recognition and scoped credentials: both major card networks now ship rails that bind an AI agent to a scoped credential — Mastercard’s revocable in real time — and Visa adds a protocol that lets a merchant cryptographically confirm the agent is a real shopping agent rather than a scraper. The unsettled half is liability. At the time of writing neither network has published a binding chargeback rule for a dispute an agent started, and the one specification that does address the question in writing assigns the loss to you.

That gap matters more than it sounds, because the two halves were built by different teams to solve different problems and are sold under names that blur together. Mastercard has two products called some version of Agent Pay. Visa has two products that both sit under agentic commerce. Between April 2025 and June 2026 the two networks shipped four of them, roughly a year apart at the extremes, and a merchant reading vendor documentation today can very easily integrate one thing while believing they have the other.

This guide separates them: what each launch does, what a delegated credential actually constrains, and where a dispute currently lands when an agent buys the wrong thing inside a mandate the consumer genuinely granted. It is a merchant-side decision guide rather than a protocol explainer, and it is not legal advice.

The first question is identity. Is this an authorized shopping agent acting for a real customer, or a scraper wearing a plausible user agent string? That question has a technical answer, and the payments industry has spent the last fifteen months building it: cryptographic agent recognition, tokenized credentials scoped to a named agent, spend caps enforced before the transaction reaches you.

The second question is consequence. If this purchase turns out to be wrong — wrong item, wrong quantity, wrong moment, right mandate — who pays for it? That question does not have a technical answer, and at the time of writing it does not have a published rule either. It has a specification sentence, two regulators moving in different directions, and an industry consensus that the existing dispute machinery was not designed for this.

The imbalance is visible in the shipping cadence. In a single week in March 2026, according to a HackerNoon synthesis citing the respective company announcements, Mastercard agreed to acquire the stablecoin firm BVNK for up to $1.8 billion (March 17), Visa extended the Stripe Machine Payments Protocol with the Tempo blockchain to card payments (March 18), and Visa Crypto Labs shipped a command-line tool for AI agent payments (March 19). Three days, three rails. No corresponding week produced a dispute rule.

Start here, because almost every downstream confusion comes from this table. Four distinct products were announced across roughly thirteen months. Two of them are Mastercard products whose names differ by two words. Two of them are Visa products that solve adjacent but genuinely different problems. The day column is recomputed as calendar days elapsed from the earliest of the four, so the spacing is visible rather than implied.

The shape of that scale is the story. The two consumer-agent tokenization products landed one day apart, which tells you both networks read the same market signal at the same moment and neither wanted to be second. Then nothing comparable for five and a half months, until Visa added recognition on top of credentials. Then another eight months before Mastercard extended the idea past consumers entirely, to machines paying machines.

Read as a sequence rather than a pile of press releases, the industry answered identity first, scope second and settlement third — and has not yet answered dispute at all. That ordering is not an accident. The first three are engineering problems a network can ship unilaterally. The fourth requires the network to tell issuers, acquirers and merchants who absorbs a class of loss nobody has enough data to price.

Visa shipped its two agentic-commerce initiatives in the order a merchant would want them, and they are frequently discussed as though they were one product. They are not, and the difference determines which problem you can actually solve with each.

The Trusted Agent Protocol carries three data elements, per Visa’s announcement: Agent Intent, a buy-or-browse signal; Consumer Recognition, existing-account and prior-interaction data that lets a merchant connect the agent to a known customer; and Payment Information, optional payment data the agent can carry through. The first two are the interesting ones for a merchant, because they are the difference between treating agent traffic as an anonymous risk and treating it as a returning customer with a helper.

The early partner list Visa published spans acquirers, processors and platforms rather than only card infrastructure: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay. Visa also framed the protocol as complementary rather than competitive, stating that it is aligning with the Agentic Commerce Protocol and collaborating with Coinbase on x402 interoperability — which is a meaningful signal for merchants who feared having to pick a camp.

Jack Forestell, Visa’s Chief Product and Strategy Officer, framed it as an ecosystem obligation: “We believe the entire payments ecosystem has a responsibility to ensure sellers can trust AI agents as much as they trust their best customers and networks.” Cloudflare’s Chief Strategy Officer, Stephanie Cohen, put the same point more plainly: “Securing the future of commerce is a shared responsibility, especially as AI agents begin to act on behalf of consumers.” Note what neither sentence says. Shared responsibility is a design principle, not an allocation of loss. If you are already integrating the credential side, our merchant guide to the Visa and OpenAI tokenized rollout covers the catalog and checkout work that sits underneath.

This is the trap that costs merchants the most time. Search for “Mastercard Agent Pay” and you will get coverage of two launches thirteen months apart, built for different buyers, settling over different rails. Read the date on anything you are handed.

Agent Pay for Machines runs a four-step model Mastercard describes as credential, permission, transact, settle. Every agent is credentialed through the network’s Verifiable Intent framework; organizations set spending limits that are enforced programmatically rather than by policy document; settlement spans multiple rails. A third-party implementation guide published two days after launch adds that agent credentials are initially recorded on Polygon, Solana and Base — useful context, though it is a secondary source rather than the network’s own documentation.

The credentialing framework itself is worth understanding on its own terms, because it is the piece a merchant is implicitly trusting when an AP4M transaction arrives; we covered it separately in our look at Mastercard’s Verifiable Intent trust framework. What matters for the liability question is narrower: a programmatically-enforced spending limit is a very good control against an agent that spends too much, and no control at all against an agent that spends the right amount on the wrong thing. Those are different failure modes, and only the first one has a product.

Underneath the network branding, the working primitive most merchants will meet first is Stripe’s Shared Payment Token, the payment object behind the Agentic Commerce Protocol. Its properties are refreshingly unambiguous: a token is merchant-specific, amount-limited and time-limited. Stripe’s seller-facing documentation exposes the constraint explicitly as usage_limits, carrying a currency, a max_amount and an expires_at, enforced at the API level rather than left to merchant discipline. One integration pattern documented by a third-party vendor shows tokens expiring after roughly thirty minutes.

Shared Payment Tokens are not new — Stripe’s own March 3, 2026 post on supporting additional payment methods for agentic commerce refers back to their launch “last year,” placing it in 2025. What is new is how much weight they are now carrying. The protocol layer around them gives businesses the ability to accept or decline agent-initiated transactions per agent, per transaction, or through custom logic, and the protocol site is explicit that agents do not become merchants; they facilitate discovery and hand off to you.

Read those two facts together and the shape of the deal becomes clear. The agent ecosystem has given merchants strong, enforceable controls over how much and where, plus a per-request veto. It has not given them any control over whether the purchase was the right one, because no token can encode that. And the specification is candid about where the residue lands.

The useful way to reason about this is scenario by scenario, because the frameworks do not fail uniformly. Two of the five common failure modes are already handled well by machinery that predates agents entirely. Three of them are not handled at all. The matrix below is our reading of published network, protocol and regulatory material as it stood at the time of writing — a planning aid, not legal advice.

One column is constant, and that is the finding. Whatever the failure mode, the Agentic Commerce Protocol answer does not move: merchant and PSP. The specification does not distinguish between a stolen credential, a mis-scoped mandate and a hijacked agent, because it is not trying to allocate fault — it is declaring that the AI platform is not standing in the payment chain. Merchants who read that column as a protection are reading it backwards.

The industry itself is unusually candid about the gap. Monica Eaton, Founder and CEO of the dispute-management firm Chargebacks911, has described the mismatch directly, and her framing is the cleanest statement of the problem we have found.

Her colleague Donald Kossmann, the firm’s CTO, offers the more optimistic reading of the same shift: “The industry spent years training fraud and dispute systems to read human behaviour... Agentic commerce doesn’t produce human behaviours but it produces something more consistent, more data-rich, and more auditable.” Both things can be true. The evidence available to adjudicate an agent dispute is better than the evidence available for a card-not-present human dispute, and there is still no rule saying what to do with it. If your current dispute posture was built for human buyers, our general chargeback-prevention playbook remains the right baseline; nothing in the agent stack replaces it.

The most striking thing about the regulatory picture is that the US and UK have not landed in the same place, and the divergence is substantive rather than procedural. The two readings below, and the two notes that follow them, are relayed through a HackerNoon synthesis of the liability question, which cites the underlying regulatory documents.

United States. Regulation E, at 12 CFR § 1005.6, caps consumer liability for electronic transfers a third party initiated “without actual authority.” That test was written for stolen cards and unauthorized access, and it does its job. It does not obviously reach a purchase made by an agent the consumer did authorize, within limits the consumer did set, for an item the consumer did not want. The consumer granted authority; the dispute is about its scope. Nothing in the rule tells an issuer how to score that.

United Kingdom. The Competition and Markets Authority published guidance on March 9, 2026 stating that a business is responsible for what its AI agent does in the same way it would be for an employee’s actions — explicitly including cases where a third party designed or provided the agent. That is a far more decisive position, and it resolves the delegation question by analogy rather than by waiting for one. Note the subject: it addresses businesses deploying agents, which is you and the agent platform, not the consumer whose agent placed the order.

Separately, the FCA’s Payments Regulatory Priorities Report of March 25, 2026 signals that UK regulators are willing to ask whether the payments framework itself needs changing for autonomous agents, rather than assuming existing rules apply unchanged. For a regulator whose default posture is technology-neutral application of standing rules, that is a notable departure and worth watching.

Underneath both sits a technical problem the security community named before the payments community did. OWASP’s LLM Top 10 lists Excessive Agency as LLM06, covering delegation chains in which a sub-agent has no direct relationship with the original user and knows only what its parent told it. That is precisely the fourth row of the matrix above. As agent stacks get more capable — planners spawning specialists, specialists calling tools — the question “who authorized this?” becomes harder to answer, not easier, and no amount of recognition at the merchant boundary reaches back up the chain.

Three numbers circulate in almost every agent-commerce liability discussion. All three are real, all three are widely quoted, and none of them says what it is usually deployed to say. Each is shown here with the surface it came from.

The first of those deserves a blunt restatement, because it is the most frequently misused number in this space. There is no published agent-specific chargeback rate at the time of writing. We looked for one and did not find a primary source quantifying disputes on agent-initiated purchases as a share of agent-initiated volume. The 24% growth forecast and the 324 million figure describe total chargebacks across the network across all commerce. If a vendor, a deck or an article hands you a chargeback rate for agent purchases specifically, ask where it came from before you plan against it.

The absence is itself informative. Networks price risk from observed loss data, and rules follow pricing. Nobody has published an agent-attributed dispute rate because the observation window is still too short and the volume too small relative to total commerce — which is exactly why no binding agent-dispute rule exists yet. That will change on a data timeline, not an announcement timeline. For the volume side of that picture, see our stat compilation on where agentic commerce actually stands mid-2026, which sets out the adoption figures and their contradictions.

The practical implication of everything above is that you cannot contract your way out of the unsettled rows, so the work is to shrink them. Four decisions do most of that job, and none of them require knowing what the networks will eventually publish.

Looking forward, the sequence that produced four launches in thirteen months suggests the dispute answer arrives the same way the others did: as a network product rather than a regulatory instrument, and probably from whichever network first accumulates enough agent-attributed loss data to price it. The UK’s position gives it a head start on the legal reasoning, since the employee analogy already assigns responsibility without waiting for new statute. The US path looks slower, because Regulation E’s binary has to either be reinterpreted or supplemented, and neither happens quickly.

Our expectation, offered as a projection rather than a forecast, is that the first binding rules will not try to answer “did the consumer authorize this?” at all. They will instead define an evidentiary standard — what a merchant must have captured about the mandate for a representment to stand — and allocate loss to whichever party failed to produce it. That is the pattern card networks have reached for before when a new channel outran the rules, and it is why the logging decision above is the one worth acting on this quarter. Teams rebuilding their commerce stack for this can start with our ecommerce engineering and optimization work, where the checkout instrumentation lives.