The Mandate That Replaced the Checkout Button: How FIDO AP2 and Verifiable Intent Build a Trust Layer for Agentic Payments

1. Buy the Tickets the Moment They Drop#

At 09:00 on a Tuesday, a batch of limited-run concert tickets sells out in ninety seconds. One buyer got their pair while sound asleep. Their shopping agent had been told the night before, "buy two, up to $400, the moment they drop" -- and at 09:00:03 it did. No one clicked "buy." No thumb touched a fingerprint reader. No human was within three meters of the transaction. So when the merchant, the card network, and the issuing bank each ask the question that has always mattered in commerce -- who authorized this? -- what do they point at?

Nothing is broken here. The purchase is correct, wanted, and within budget. That is what makes the moment so disorienting. There is no signature to capture, no 3-D Secure challenge a sleeping person could answer, and a network token -- even one locked to a single merchant -- proves only that an instrument was used, not that this specific purchase reflected the buyer's intent. The scenario is not hypothetical: Google's own protocol announcement uses exactly this case, "securing and purchasing limited-run tickets the moment they're on sale... based on pre-authorized user instructions" ^[3].

The discomfort has a precise cause. As the Agent Payments Protocol puts it, "today's payment systems generally assume a human is directly clicking 'buy' on a trusted surface," and "the rise of autonomous agents... breaks this fundamental assumption" ^[1]. Every mechanism the payments industry built over twenty-five years to answer "who authorized this?" quietly assumes a body at a surface -- a body that, at 09:00:03, was asleep.

AP2 frames the problem as three questions that a signed mandate exists to answer ^[5], ^[1]. Authorization: did the user actually grant this specific authority, with these limits? Authenticity: does the request reflect a real human instruction rather than a model's hallucination or a hijacked prompt? Accountability: when something goes wrong, who is liable, and what evidence settles the dispute? Hold onto those three words. Every later section is, in the end, an attempt to answer one of them without a human in the room. "FIDO AP2" is shorthand for FIDO's stewardship, not its authorship: FIDO stewards AP2 but did not create it and has not ratified it. Section 6 states the full provenance and dates ^[2], ^[3].

Here is the thesis, stated plainly so you can test it against everything that follows: for the whole history of digital commerce, authorizing a purchase and being present for it were the same event, and the checkout button is that assumption made physical. Agents pull the two apart. The rest of this article is about the one idea that makes the severed link safe -- turning consent into a portable, signed artifact that survives the click -- and about how much, and how little, that idea can guarantee.

If "a present human clicks buy" is the assumption agents break, where did it come from, and why is it wired so deeply into commerce that pulling it out breaks everything downstream?

2. The Presence Assumption Baked Into Commerce#

Commerce assumed a body long before it assumed a browser. Card-present payments bound authorization to two physical facts: a physical card and a physical terminal. You inserted the card, entered a PIN, signed a slip. The authorization was the presence -- there was no separate proof-of-intent step, because standing at the terminal with the card in hand was the proof. When the web arrived, the checkout button inherited that logic wholesale. A human looking at a cart, clicking "buy" over HTTPS, re-enacted the person at the terminal. The surface changed; the assumption did not.

That reconstruction is the whole story of the next two decades, and it runs down two tracks that never quite met.

Track one: make presence stronger. Card-not-present commerce had broken the physical binding, so the networks bolted a presence challenge back on rather than rethinking the model. 3-D Secure -- the technology behind "Verified by Visa" and its successors, now stewarded by EMVCo -- added an "is the real cardholder actually here?" challenge to remote purchases ^[6]. "Verified by Visa" launched around 2001 on technology from Arcot Systems (later acquired by CA Technologies). That provenance is history color corroborated by public reporting rather than a single fetched primary source; the load-bearing point is only that 3-D Secure is a presence bolt on card-not-present flows ^[6]. EMV Payment Tokenisation went further, replacing the real card number (the PAN) with a token constrained to a specific merchant, device, or scenario ^[7]. Both were real advances. Both made presence more trustworthy. Neither questioned whether presence should be required.

Track two: delegate access, but never money. In parallel, a different problem was being solved cleanly. OAuth 2.0 (RFC 6749, D. Hardt, Ed., October 2012) let a third-party application "obtain limited access... on behalf of a resource owner" without handing over the owner's password ^[8]. This is delegation -- letting software act for you -- and it is genuinely close to what agents need.

But look at what OAuth's consent actually is. It is a server-side grant: a record, held by the authorization server, that a user once clicked "Allow." It governs API access, not payment intent, and it still assumes you were present to click "Allow" in the first place. OAuth taught the industry to delegate authority over an inbox or a calendar; it never taught anyone how to delegate a purchase with the human gone.

timeline
title The lineage of delegated purchase authorization
1995 : Web checkout button, presence is authorization
2001 : 3-D Secure bolts a presence challenge onto remote card payments
2012 : OAuth 2.0 delegates limited access, still assuming a present click
2019 : WebAuthn proves a present human gesture with public keys
2025 : W3C VC 2.0 and SD-JWT make signed claims portable : AP2 v0.1 introduces Intent and Cart Mandates
2026 : AP2 v0.2 adds Checkout and Payment Mandates and Human Not Present payments : Verifiable Intent becomes the evidence layer

Notice the shape of the diagram: two tracks, both anchored to a present human, one reinforcing presence and one quietly depending on it. That shared anchor is exactly what the last two entries pull loose. But we are getting ahead of the story. When the first wave of "AI that can buy things" arrived, engineers did the reasonable thing -- they reached for the tools already on the shelf. Every one of them failed the agentic case, and they failed it in instructive, almost identical ways.

3. Making Agents Pay Before Mandates Existed#

Here is the honest engineer's tour: four things you would try first to let an agent buy something, and the exact point where each one breaks. All four are instructive failures, and they fail for the same reason.

Attempt one: let the bot drive the human interface. Screen-scraping and robotic process automation point an agent at the same web form a person would use, and have it type the card number into the checkout page. It works without any merchant cooperation, which is its whole appeal. It is also fragile (a redesigned page breaks the script), insecure (the real card number crosses a scriptable surface), and -- decisively -- it carries no verifiable proof of intent. A scraped form submission is byte-for-byte indistinguishable from a hallucinated or hijacked one.

AP2's design premise is the exact inversion: "Verifiable Intent, Not Inferred Action," anchored to "deterministic, non-repudiable proof of intent" ^[5]. Driving the UI infers action; it never proves intent.

Attempt two: hand the agent the card. Store the PAN, let the agent spend. This grants unbounded authority with no ceiling on price, no allowlist of merchants, and no window of time -- and it leaves the liability question unanswerable when the agent errs. (Card-on-file remains perfectly good for a human setting up recurring billing; it is delegation to an autonomous spender that it cannot survive.)

Attempt three: harden the instrument. Network tokenization and Click to Pay do something real: they swap the raw PAN for a token "constrained... to a specific merchant, device or payment scenario" ^[7]. That protects the value if the token leaks. But a token is still an instrument, not an authorization. It says which card may be used; it says nothing about whether this specific purchase was one the user wanted. It protects the card, not the intent. This is a complement that still ships today, not a dead end -- but it does not answer any of the three questions.

Attempt four: build a private silo. Each platform invents its own closed "AI checkout." The trouble is not that any one silo cannot work; it is that a payment authorization only has value if a merchant, a network, and an issuer who do not share a codebase can each verify it. A per-vendor scheme cannot cross those boundaries, and it fragments the industry into incompatible proprietary payment models -- the anti-pattern the eventual standardization exists specifically to prevent ^[5].

Line the four failures up and the same shape is cut out of each. None of them produces durable, portable, tamper-evident consent: proof of what the user intended that outlives the moment of authorization and that three parties who do not trust each other can independently check. That missing artifact is the hole in the middle of every attempt.

There is a classical name for what goes wrong when authority and intent come apart like this.

An agent with a stored card and a vague instruction is a confused deputy waiting to happen: it holds spending authority but cannot prove, to anyone downstream, whose intent it is acting on. So rather than patch the four attempts one more time, it is worth taking the genealogy seriously. What does the sequence of prior authorization primitives, generation by generation, reveal about the shape of the thing that is missing?

4. Generation by Generation Toward the Mandate#

Treat the genealogy as a forcing function. Each generation of delegated purchase authorization was pushed into existence by a specific failure of the one before it. The interesting content is not the dates -- it is precisely why each generation breaks the moment the human is absent.

Gen 0 -- Human-present checkout (mid-1990s onward). Presence is authorization; the click is ephemeral and self-authenticating by context. It fails for agents in the most basic way possible: remove the human and you have removed the authorization itself, because there is no persisted artifact of consent to fall back on.

Gen 1 -- OAuth 2.0 delegation (RFC 6749, 2012). The first serious attempt to let software act for you: scoped, revocable, server-mediated authority ^[8]. It fails delegated payment three ways at once. Consent is a server-side grant, not portable evidence a third party can carry and verify. It governs API access, not payment intent. And it still assumes you were present to click "Allow." OAuth's own threat model catalogues how delegated tokens get misused ^[10]; reading those patterns as the payment-side confused-deputy risk is this article's analytical mapping, not a claim of the RFC.

Gen 2 -- WebAuthn / passkeys and Secure Payment Confirmation (2019). WebAuthn produces an origin-bound public-key proof of "the presence and consent of the user" at the moment of the gesture ^[11]; its User Presence test is, literally, a proof-of-presence check. Secure Payment Confirmation aims that same gesture squarely at the payment moment, signing the merchant origin and the transaction amount ^[12]. These are the strongest primitives on this whole list -- and they prove exactly the wrong thing for an agent. They are the best possible statement of presence at the precise instant the problem becomes absence.

"Today's payment systems generally assume a human is directly clicking 'buy' on a trusted surface... The rise of autonomous agents... breaks this fundamental assumption." -- Google, Announcing the Agent Payments Protocol

Gen 2.5 -- W3C Verifiable Credentials and SD-JWT (2025). This is enabling substrate, not a superseded rung. The W3C Verifiable Credentials model -- a 2019 Recommendation (VC DM 1.0), now version 2.0 (15 May 2025) -- standardizes portable, independently verifiable signed claims ^[13], ^[14], and SD-JWT (RFC 9901, November 2025) adds selective disclosure so a holder reveals individual claims ^[15]. Necessary, nowhere near sufficient: this is generic credential machinery with no payment semantics -- no mandate types, no Open-to-Closed lifecycle, no merchant or issuer roles. It is the toolbox the mandate is built from, not the mandate.

Gen 3 -- AP2 v0.1 (September 16, 2025). The first cryptographic encoding of delegated purchase intent. Consent becomes a Mandate: "tamper-proof, cryptographically-signed digital contracts... signed by verifiable credentials," in the original Intent Mandate / Cart Mandate vocabulary ^[1], ^[16], ^[17]. It was superseded quickly because the Intent/Cart split was coarse, the evidence layer was not yet a standalone thing, and single-vendor governance risked the very fragmentation the effort wanted to avoid.

Gen 4 -- AP2 v0.2 and Verifiable Intent, donated to FIDO (April 28, 2026). The frontier: Checkout Mandate and Payment Mandate, each moving through Open and Closed stages; explicit "Human Not Present" payments; a protocol-agnostic evidence layer in Verifiable Intent; and neutral stewardship under the FIDO Alliance ^[5], ^[3], ^[2], ^[4]. The September 2025 launch used Intent Mandate and Cart Mandate; the current specification uses Checkout Mandate and Payment Mandate, each moving Open to Closed. This article frames the change strictly by its two documented endpoints and does not assert the exact micro-version at which the rename landed ^[1], ^[5].

flowchart TD
G0["Gen 0, 1995: human-present checkout, presence is authorization"] --> G1["Gen 1, 2012: OAuth 2.0 delegates access, not payment intent"]
G1 --> G2["Gen 2, 2019: WebAuthn and SPC prove a present gesture"]
G2 --> G25["Gen 2.5, 2025: W3C VC and SD-JWT, portable signed claims, no payment semantics"]
G25 --> G3["Gen 3, Sep 2025: AP2 v0.1 Intent and Cart Mandates"]
G3 --> G4["Gen 4, Apr 2026: AP2 v0.2 and Verifiable Intent, consent outlives the click"]

Now step back and read the column that matters. From 3-D Secure through passkeys, every advance made presence stronger -- and every one stayed exactly as useless for the sleeping ticket-buyer, because none addressed absence at all. The FIDO CTO says it without flinching: "Today's infrastructure assumes a human is present at checkout. It offers limited support for: Delegated authority to software agents; Persistent, machine-readable consent; Verifiable evidence of user intent" ^[18].

That is the reframe the whole field needed. The question was never "how do we prove the human is here?" It was "how do we make consent survive the human leaving?" What does an artifact built to answer that question look like?

5. The Mandate as a Persisted, Tamper-Evident Consent Artifact#

Here is the whole idea in one sentence, and then the rest of the section earns it: decouple authorization from execution. Authorization is when the user consents -- possibly in advance, possibly asleep. Execution is when the agent acts -- possibly with no human present. For the entire history of commerce these were the same instant, welded together by the click. The mandate splits them by encoding consent as a signed credential that persists after the moment of the click. Three mechanisms make that real.

One: the mandate is an artifact, not a session. An AP2 mandate is a signed, tamper-evident object ^[5]. Two properties fall out of that. Because it is signed, any alteration is detectable and its origin is verifiable. Because it is portable, a merchant, network, and issuer can each verify it without a shared database or a trusted referee. This is what Gen 0 through Gen 2 lacked: OAuth's consent lived inside one authorization server, and a passkey assertion evaporated when the gesture ended. A mandate is a thing you can hold, hand on, and check later.

Two: the Open-to-Closed lifecycle is the decoupling made concrete. AP2 gives each mandate two stages. An Open mandate captures "the user's constraints and goals for the transaction before a specific cart is finalized for autonomous execution." A Closed mandate captures "the user's (or agent's) authorization for a specific, finalized checkout" ^[5].

Read those two definitions against the concert-ticket scene and they light up. The night-before instruction -- two tickets, up to $400, this event -- mints an Open mandate, signed while the user is present. The next morning, the agent finds the conditions satisfied and generates a Closed mandate binding those exact constraints to the actual cart. The Open mandate is the sleeping user's standing instruction; the Closed mandate is the 09:00 execution -- and chained back to the Open one, it is the concrete answer to "who authorized this?"

sequenceDiagram
participant U as User
participant A as Shopping Agent
participant M as Merchant
participant C as Credential Provider
Note over U,A: Night before, the user is present
U->>A: Sign Open mandate with constraints, two tickets, budget cap, this event
Note over A: Authorization captured and signed, the human can now leave
Note over U,A: Next morning, tickets drop, no human present
A->>M: Conditions met, generate Closed mandate bound to the actual cart
M->>C: Present the chained mandates for verification
C->>M: Verify signatures and constraints, then approve
Note over U,C: The Closed mandate is the answer to who authorized this

The logic that lets an agent make that Open-to-Closed jump on its own is small enough to read. The following is illustrative -- it is not a real AP2 SDK call -- but it shows the shape of the decision: given a signed Open mandate and a concrete cart, may the agent auto-generate a Closed mandate?

// Illustrative only -- not a real AP2 SDK call.
// An Open mandate carries pre-authorized constraints the user signed last night.
const openMandate = {
maxAmount: 400,                 // currency units
currency: "USD",
allowedMerchants: ["ticketvendor.example"],
itemQuery: "Particle Wave live, 2 tickets",
quantity: 2,
expiresAt: Date.parse("2026-07-02T00:00:00Z"),
};

// The next morning the agent has a concrete proposed cart.
const proposedCart = {
merchant: "ticketvendor.example",
description: "Particle Wave live, general admission",
quantity: 2,
total: 372,
currency: "USD",
at: Date.parse("2026-07-01T09:00:03Z"),
};

function canAutoGenerateClosedMandate(cart, m) {
const checks = [
  [cart.currency === m.currency, "currency matches"],
  [cart.total <= m.maxAmount, "total within budget cap"],
  [m.allowedMerchants.includes(cart.merchant), "merchant is allow-listed"],
  [cart.quantity === m.quantity, "quantity matches"],
  [cart.at < m.expiresAt, "mandate not expired"],
];
const failed = checks.filter(function (c) { return !c[0]; });
return {
  allowed: failed.length === 0,
  reasons: (failed.length ? failed : checks).map(function (c) { return c[1]; }),
};
}

const v = canAutoGenerateClosedMandate(proposedCart, openMandate);
console.log(v.allowed ? "OK: agent may mint a Closed mandate" : "BLOCKED: a constraint failed");
console.log(v.reasons.join(", "));

The point of the code is not the arithmetic. It is that the constraints being checked were signed hours earlier by a human who is no longer here, and the check is deterministic. The agent is not inferring what the user probably wanted; it is testing a concrete cart against an explicit, signed authorization.

Three: the two-layer split is what makes the severed link safe. Naming the division of labor is where the thesis is actually proven. AP2 is the coordination, or mandate, layer: it answers "Who is allowed to do what, on whose behalf, and under what constraints?" ^[18]. Verifiable Intent is the evidence layer: it defines how that consent is represented and independently checked. The FIDO CTO draws the line in a single sentence.

"If AP2 defines how intent is created and shared, Verifiable Intent defines how it is proven." -- Nishant Kaushik, CTO, FIDO Alliance

The breakthrough is not a cleverer way to simulate a present human. It is abolishing the requirement that authorization and execution happen at the same instant. An Open mandate captures consent whenever the user is willing to give it; a Closed mandate spends it whenever the agent acts; a signature threads the two together. Consent no longer has to be present at execution, because it was captured, signed, and carried forward. That -- not a better button -- is delegation without presence.

If that is the idea, the details are where it lives or dies: which mandates, which roles, which credential format, which disclosure rules. Time to open the machine.

6. The Full AP2 and Verifiable Intent Architecture#

You now believe the idea. Here is the whole machine, organized by its two layers and then mapped onto FIDO's three pillars. Provenance and draft status get stated once, in full, at the end of the section.

AP2, the coordination layer#

AP2 engineers trust with Verifiable Digital Credentials, and it defines a cast of roles that maps cleanly onto rails a payments engineer already knows ^[5], ^[3]. The user is the cardholder. The shopping agent (and, on the seller side, a merchant agent) acts for a principal. The merchant sells. The Merchant Payment Processor plays the acquirer or PSP role. The Networks are the card networks. The Credential Provider holds the user's payment credentials, the way an issuer wallet does. Put the AP2 names on the familiar chain and nothing is mysterious.

flowchart LR
U["User, the cardholder"] --> SA["Shopping agent"]
SA --> M["Merchant and merchant agent"]
M --> MPP["Merchant Payment Processor, the acquirer or PSP"]
MPP --> N["Networks, the card networks"]
N --> CP["Credential Provider, like an issuer wallet"]

Across those roles, AP2 defines two mandate types, each with the two-stage lifecycle from the last section. The Checkout Mandate captures what to buy and is shared with the merchant. The Payment Mandate captures how to pay and is shared with the Credential Provider, the Networks, and the Merchant Payment Processor. Chained together, the mandates form "a complete, verifiable audit trail for both human-present and human-not-present transactions," and v0.2 adds explicit "Human Not Present" payments ^[5], ^[3].

AP2 does not float free of the rest of the agent stack. It is an open extension of the Agent2Agent (A2A) protocol -- the agent-to-agent substrate -- with the Model Context Protocol (MCP) as the agent-to-tool complement ^[19], ^[20]. ※ A2A is agent-to-agent; MCP is agent-to-tool. AP2 rides the first to coordinate a purchase across agents, and can use the second to reach the tools that execute it. Reference flows for human-present cards, human-not-present cards, x402, and Android digital payment credentials ship in the Apache-2.0 repository, so none of this is paper-only ^[21].

Verifiable Intent, the evidence layer#

If AP2 says who may do what, Verifiable Intent says how anyone downstream can check it. VI is "a layered SD-JWT credential format that creates a cryptographically verifiable chain binding an AI agent's commercial actions to an end-user's explicitly stated purchase intent" ^[4]. The chain has three layers. L1 is the issuer credential, signed by the Issuer -- say a bank, or a network acting on the bank's behalf -- into a Credential Provider's wallet. L2 is the user intent, created by the User. L3 is the agent action, created by the Agent when it acts in Autonomous mode.

Each layer cryptographically constrains the next through key-confirmation claims ^[22]. A key-confirmation (cnf) claim embeds the next signer's public key inside the layer above, so the next layer verifies only if its signer proves possession of that key. That is what binds L2 to L1 and L3 to L2 into one unforgeable chain, rather than three tokens that merely sit next to each other ^[15].

flowchart TD
L1["L1 issuer credential, signed by the Issuer"] -->|key confirmation binds the next layer| L2["L2 user intent, created by the User"]
L2 -->|key confirmation binds the next layer| L3["L3 agent action, created by the Agent in Autonomous mode"]

VI runs in two execution modes: Immediate, where the user confirms in the moment, and Autonomous, where the agent acts under delegated authority ^[4]. The landing site enumerates eight constraint types the chain can bind -- amount bounds, merchant allowlists, budget caps, recurrence terms, and more -- so the "intent" is not a vibe but a set of signed, checkable limits ^[22]. And because it is built on SD-JWT, VI supports selective disclosure: "each party in a transaction sees only the claims relevant to its role" ^[4].

Selective disclosure is easier to feel in code than in prose. The credential publishes only salted digests of its claims; the holder later discloses the raw claims a particular verifier needs, and the verifier recomputes each digest to confirm it. Verification cost is $O(n)$ in the number of claims actually disclosed -- you pay for what you reveal, nothing more ^[15].

// Illustrative model of SD-JWT selective disclosure -- not a real SD-JWT library.
// A tiny stand-in digest; real SD-JWT hashes base64url(salt, claim) with SHA-256.
function digest(salt, name, value) {
const s = salt + ":" + name + ":" + JSON.stringify(value);
let h = 0;
for (let i = 0; i < s.length; i++) { h = (h * 31 + s.charCodeAt(i)) | 0; }
return "sd_" + (h >>> 0).toString(16);
}

// The full claim set, each paired with its own random salt.
const claims = {
cardholder: ["s1", "Ada L."],
amountCap:  ["s2", 400],
merchant:   ["s3", "ticketvendor.example"],
pan:        ["s4", "4111111111111111"],
};

// The issued credential publishes only digests, never the raw claims.
const issued = Object.fromEntries(
Object.entries(claims).map(function (e) {
  const name = e[0], salt = e[1][0], value = e[1][1];
  return [name, digest(salt, name, value)];
})
);

// present(disclose) reveals only the named claims to one verifier.
function present(disclose) {
return disclose.map(function (name) {
  return { name: name, salt: claims[name][0], value: claims[name][1] };
});
}

// verify() recomputes each disclosed digest -- linear in disclosed claims.
function verify(disclosures) {
return disclosures.every(function (d) {
  return digest(d.salt, d.name, d.value) === issued[d.name];
});
}

const toMerchant = present(["merchant", "amountCap"]);        // no cardholder, no PAN
const toIssuer   = present(["cardholder", "pan", "amountCap"]);

console.log("merchant view verifies:", verify(toMerchant));
console.log("issuer view verifies:", verify(toIssuer));
console.log("merchant never saw the PAN:", !toMerchant.some(function (d) { return d.name === "pan"; }));

One credential, two role-tailored views: the merchant confirms the amount cap and the merchant name without ever seeing the cardholder or the card number, while the issuer sees what it needs to authorize. That is the privacy property the evidence layer buys you. SD-JWT is RFC 9901, published November 2025 by D. Fett, K. Yasuda, and B. Campbell. An earlier secondary search in this project surfaced "RFC 9426" for SD-JWT; that number is wrong and should not be used ^[15].

Mapping both layers onto FIDO's three pillars#

FIDO organizes the work into three focus areas: Verifiable User Instructions, Agent Authentication, and Trusted Delegation for Commerce, developed across an Agentic Authentication Technical Working Group (chaired by CVS Health, Google, and OpenAI) and a Payments Technical Working Group (chaired by Mastercard and Visa), both formed on April 28, 2026 ^[2], ^[23]. VI supplies the Verifiable User Instructions and the evidence for Trusted Delegation for Commerce; AP2 supplies the coordination for Trusted Delegation for Commerce; and Agent Authentication -- proving which agent is acting -- is the pillar still being built, a point Section 9 returns to.

State the provenance cleanly, because it is the single most-mangled fact in coverage of this topic. AP2 was created by Google and announced on September 16, 2025; Verifiable Intent was co-developed by Mastercard and Google; both were contributed to the FIDO Alliance on April 28, 2026, where AP2 is under development in the Payments TWG but is not yet a ratified standard, and VI is a v0.1-draft dated 2026-02-18 ^[2], ^[3], ^[4]. "Verifiable Intent" has two legitimate referents -- the verifiableintent.dev draft specification and Mastercard's canonical program announcement; Section 11 disambiguates them ^[4], ^[24].

This is one coherent stack. But it is not the only agentic-commerce effort in 2026, and the honest question is which of the others actually compete with it, and which quietly compose with it.

7. Competing and Complementary Approaches#

Most of the 2026 agentic-commerce headlines read like a cage match. Most of them are actually complementary layering. The real rivalry is narrower than it looks, and it is worth naming precisely.

ACP -- the Agentic Commerce Protocol (OpenAI and Stripe). ACP standardizes the commerce interaction (agentic checkout, cart, product feed) and pairs it with a delegated-payment model built on a Shared Payment Token: single-use, "restricted by the delegated payment's max amount and expiry," with the explicit note that "OpenAI is not the merchant of record" ^[25], ^[26].

Look closely at what the token constrains. It bounds the instrument -- how much this token may spend, and until when. It says nothing, cryptographically, about whether the purchase reflects the user's intent. That is the one genuine competition on this list: a scoped payment token versus a signed proof of intent as the trust primitive for card-based agentic checkout.

UCP -- the Universal Commerce Protocol (Google and Shopify). UCP is a commerce-orchestration layer spanning discovery, checkout, and post-purchase, and it does not reinvent the trust layer -- it rides AP2 for provable payment. UCP's payment mandates are "scoped specifically to a checkout hash, preventing 'token replay' or amount manipulation" ^[27], ^[28]. This is composition, not competition: UCP calls AP2 exactly where it needs a signed authorization.

A2A x402 -- the web3 rail. The x402 extension revives the long-dormant HTTP 402 status code for machine-native payment over stablecoin rails ^[29]. It is a rail AP2 can settle over, not a trust layer that competes with mandates; AP2's own launch called out x402 as a supported extension ^[1]. The chain mechanics are out of scope here.

Network and closed-loop programs. Visa Intelligent Commerce provisions "a tokenized version of her card" and asks the user "to authenticate with her Passkey," binding an agent purchase to issuer identity verification ^[30]. Mastercard's Agent Pay is the network's own agentic-payments track ^[31]. American Express runs a closed-loop program, Agentic Commerce Experiences (ACE) ^[32], ^[2]. These excel at instrument protection and at telling a legitimate agent from a bot; where they struggle is portability and openness, because the authority is anchored to one network's rails rather than to a portable credential.

FIDO's stated role across all of this is harmonization: "liaising with other industry standards bodies to ensure harmony amongst agentic commerce initiatives" ^[2]. The market numbers behind the land-grab are attributed analyst color, not primary fact. Analysts estimate roughly $5 trillion in agentic commerce by 2030 (McKinsey, as quoted and linked in the FIDO press release) ^[33], ^[2], and Deloitte likewise projects "trillions" by 2030 (linked from the FIDO trust-layer post) ^[34], ^[18].

Layered or rival, every one of these leans on the same promise: that a signed credential can stand in for a human's authorization. So it is time to ask the uncomfortable question. What can a signed mandate actually guarantee -- and what can it never guarantee, no matter how good the cryptography gets?

8. What a Signed Mandate Can and Cannot Guarantee#

You are a believer now, so this section is the deliberate cold shower. A signature is a proof about a message, never a proof about the world. A valid signature means $\text{Verify}(pk,\, m,\, \sigma) = 1$ holds for the exact bytes $m$ that were signed -- change one byte and it fails. That is enormously useful, and it is also strictly less than what the marketing implies. The distinction governs the whole section: tamper-evidence proves what was authorized; it never proves the authorization was correct or wise.

Start with what genuinely is provable, because it is a real and valuable list. A mandate delivers integrity and authenticity: any alteration is detectable and each mandate's origin is verifiable ^[5]. Chained mandates deliver non-repudiation -- "a complete, verifiable audit trail" ^[5]. SD-JWT delivers selective disclosure with bounded linkage between what different verifiers see ^[15]. And scope binding delivers real anti-replay: binding a payment authorization to a checkout hash "prevent[s] 'token replay' or amount manipulation," while SD-JWT key binding adds a nonce for freshness ^[27], ^[15].

Now the other column, which does not get shorter with better engineering.

The oracle problem. No construction can certify that a signed intent faithfully captures the user's actual desire, or that the desire was sensible. A proof of intent is only ever as truthful as the moment of signing. The primary sources frame the goal -- "Verifiable Intent, Not Inferred Action... anchored to deterministic, non-repudiable proof of intent" ^[5] -- but a goal is not a closed gap; that the gap is irreducible is an analytical claim this article makes, consistent with the sources rather than asserted by them.

The confused deputy is bounded, not eliminated. Portable, constraint-bearing mandates shrink the classic confused deputy ^[9] by making authority explicit and attenuated -- an agent can only spend inside signed limits. But an agent that is manipulated within its authorized constraints can still be induced to buy. Constraints reduce the blast radius; they do not prove the agent's reasoning was honest. Reading mandates as a bounding of confused-deputy risk, rather than a cure, is again this article's analytical framing.

"Non-repudiable audit trail" is not "fraud-proof." Tamper-evidence makes disputes adjudicable -- there is a signed record to point at. It does not make fraud impossible. A coerced or deceived user can sign a perfectly valid mandate.

Privacy versus auditability is managed, not dissolved. Selective disclosure lets each party see a role-tailored subset, but a complete audit trail and minimal disclosure pull in opposite directions. SD-JWT manages that trade-off; it does not remove it ^[15].

Freshness and revocation imply online infrastructure. A purely offline, instantly revocable credential is not achievable. Revocation needs reachable status infrastructure or short-lived credentials -- an availability-versus-authority trade-off, consistent with the key-binding freshness model SD-JWT already assumes ^[15].

"The hard problem isn't inventing new primitives, it's binding human intent to agent action with cryptographic guarantees that hold across organizational boundaries." -- Jeff Malnick, VP of Engineering, 1Password

State the gap plainly. The ideal "provably-correct-intent" credential is not achievable, because correctness of intent is not a cryptographic property. What is achievable is narrower and worth naming exactly: a portable, privacy-preserving, promptly-revocable credential that binds a verified agent identity to a specific, constrained, non-repudiable authorization. AP2 and VI approach that target -- but at draft maturity, and without a settled agent-identity binding, they do not yet fully deliver it.

These are the structural ceilings, true even if the specs were finished tomorrow. But the specs are not finished. What is still genuinely unsettled as of mid-2026?

9. What Is Unsettled as of Mid-2026#

This is a standards frontier, not a complexity-theory one, so the open problems are engineering and governance questions with concrete partial states -- not conjectures. Six of them are worth carrying in your head.

1. Ratification and semantic stability. AP2 is donated but not ratified, and VI is a v0.1-draft; the normative semantics can still move. They already have: the September 2025 Intent/Cart naming became the v0.2 Checkout/Payment model, so integrators who built to v0.1 had to migrate ^[5], ^[4]. Standardization now proceeds in the FIDO Payments Technical Working Group, co-chaired by Mastercard and Visa ^[2]. Until ratification, expect churn.

2. Binding a verified agent identity to a mandate. This is the one most people underrate. A mandate proves the user authorized an agent under constraints. It does not prove which agent instance actually acted, or that the acting agent is legitimate rather than an impersonator wearing a stolen credential. Accountability -- AP2's third question -- needs agent authenticity, not just user intent. FIDO's Agentic Authentication Technical Working Group, chaired by CVS Health, Google, and OpenAI, targets exactly this ^[2].

It is also the precise seam where this article meets the blog's agentic-identity work: "who is the principal when an agent acts?" is the identity half of the same problem AP2 and VI solve for money.

3. Cross-protocol interoperability. Several stacks now carry overlapping intent semantics on different rails and under different governance: AP2/VI, ACP, UCP, and the network programs. There is real convergence machinery -- VI is protocol-agnostic with AP2, ACP, and UCP mappings ^[4], UCP calls AP2 for provable payment ^[27], and FIDO has taken on the liaison role ^[2]. But a public, cross-vendor conformance and interoperability suite does not exist yet, so "interoperable" is a design intention more than a tested fact.

4. Revocation, freshness, and replay at scale. A pre-authorized Open mandate can outlive the intent that created it -- last night's "buy up to $400" should not still be live next month. Checkout-hash scoping blocks amount manipulation and replay for a given checkout ^[27], and SD-JWT key binding supplies nonce-based freshness ^[15], but a general revocation infrastructure for long-lived Open mandates is unspecified. Someone has to build the status service, and its availability becomes part of the trust model.

5. Liability and regulatory alignment. How do mandates map onto PSD2, Strong Customer Authentication, network rules, and chargeback regimes when no human is present at the transaction? AP2 positions its audit trail as "aiding in dispute resolution" ^[5], and card networks are separately adding their own commercial commitments -- American Express, for example, backs Card Members and Merchants in its closed-loop agentic-commerce program ^[32]. Deep regulatory reconciliation is explicitly out of this article's scope, and it remains genuinely open work for the industry.

6. The oracle and authenticity problem, operationalized. Section 8 established that no signature can prove a signed intent reflects genuine desire rather than a hallucination or coercion. Operationally, the mitigations are procedural, not cryptographic: require human-present confirmation for high-risk actions, tighten constraints, add anomaly detection. That these are the available levers -- and that none is a technical fix for the oracle gap -- is an inference from the structure of the problem, not a claim any fetched source makes.

Six open problems -- and yet the specifications, the SDK, and the reference flows are all public today. So what can an engineer actually do with AP2 and VI right now, and what should they refuse to do?

10. Engaging With AP2 and Verifiable Intent Today#

None of this is paper-only, so here is the do-this-now guide, keyed to the layer you occupy.

Read the primary sources. Start at ap2-protocol.org for the mandate model ^[5] and the Apache-2.0 google-agentic-commerce/AP2 repository for the code ^[21]. Read the SD-JWT credential format at verifiableintent.dev/spec to see how the evidence layer is actually shaped ^[4].

Run the reference flows. The repository ships runnable samples -- human-present cards, human-not-present cards, x402, and Android digital payment credentials -- so you can watch an Open mandate become a Closed one instead of taking my word for it ^[21].

Then pick by the layer you occupy.

• Payment provider, issuer, or network. Implement AP2 Payment Mandates plus Verifiable Intent for a portable, auditable proof of intent, and keep your network tokens for instrument protection. This is complementary, not either-or: tokens protect the card, mandates prove the authorization ^[4].
• Merchant or commerce platform. Adopt UCP if you want the full discovery-to-post-purchase lifecycle riding AP2 for provable payment ^[28], or ACP if you want fast agentic checkout on an existing Stripe or PSP stack ^[25].
• Building on a chat or agent surface. ACP is the shipping path today for agent-initiated checkout ^[25].
• Your core requirement is cross-boundary, human-absent, auditable authorization. Then AP2 with Verifiable Intent is the only stack that makes intent itself a portable credential rather than constraining an instrument ^[4].

Map the roles onto your own system, and if you intend to build on this seriously, participate in the FIDO Payments Technical Working Group while the semantics are still being set ^[2].

Five things to do today, and a short list of things to stop assuming. Before you brief your team, though, there are a handful of misconceptions worth dismantling by name.

11. Misconceptions Worth Dismantling#

So gather the evidence and restate the claim we opened with. For twenty-five years, authorizing a purchase and being present for it were the same event, and the checkout button made that assumption physical. Agents severed the two, and every prior primitive -- 3-D Secure, network tokens, OAuth, passkeys, Secure Payment Confirmation -- either strengthened presence or delegated access while quietly still assuming a present human.

Standing orders and recurring card billing already execute payments with no human present -- but for a fixed, pre-agreed amount to a fixed payee, carrying no portable proof of the buyer's intent. The mandate is the first artifact built for an agent's chosen purchase in absence: it captures consent as a tamper-evident, portable, signed credential that outlives the click, coordinated by AP2 and proven by Verifiable Intent, under neutral FIDO stewardship. It is early, it is draft, and it cannot certify that intent was wise. What it does establish is genuinely new.

The new primitive is not a better button. It is cryptographic, human-absent authorization of a purchase -- consent captured at one moment, signed, and spent at another, with a verifiable thread between the two. Delegation without presence is now a first-class, standardizing primitive. That is the thing the checkout button was never designed to carry, and it is the thing the mandate was built to be.