AP2 is a policy protocol (mandates as W3C VCs), not a payment rail — and knowing the difference is the whole read.
Every "AP2 will make agents transact autonomously" post gets one thing wrong: AP2 is not a payment rail, it is a mandate protocol. Intent, Cart, and Payment are modeled as W3C Verifiable Credentials that the agent presents to a merchant; the actual money movement happens over whatever rails you already had. Google announced it in September 2025 with 60+ launch partners. This essay is what AP2 actually does, where it fits above A2A and MCP, and the stablecoin narrative to hold at arm's length.
Mandate, not rail.
The clearest mental model for AP2 is that it is an authorisation protocol wearing commerce vocabulary. When an agent buys something on behalf of a user, three separate questions have to be answered: what did the user authorise the agent to do, what did the agent actually attempt, and what did the merchant charge for. Traditional card-not-present flows collapse these three into "the agent typed a card number and the merchant charged it," which works when the human clicks the buy button and cannot really work when the agent does. AP2 splits the three into distinct signed claims — an Intent that captures what the user said "yes" to, a Cart that captures what the agent is about to buy, and a Payment that captures the transaction the merchant executes — and asks each party to sign the one that binds them.
The rails are unchanged. If the user's Intent authorises a card transaction and the Cart matches, the merchant charges the card through the same processor it has always used; if the flow is bank transfer, the transfer goes through the same ACH or SEPA path. AP2 does not carry money. What it adds is a paper trail — cryptographically signed and independently verifiable — of what each participant agreed to at each step. When a chargeback arrives, the merchant does not have to argue that "the customer's agent typed a card number"; it can point at the Intent VC the user signed and the Cart VC the merchant issued and show that both matched. The protocol's whole value is that the merchant can now tell an autonomous agent from a stolen card because the agent presents a properly-scoped Intent and the stolen card cannot.
Intent / Cart / Payment as VCs.
Each of the three artifacts is a W3C Verifiable Credential — the same shape used for verifiable-university-degree and government-issued-ID pilots, applied to commerce. The Intent VC is issued by the user (or by their identity provider on the user's behalf) and states what the agent is authorised to purchase, at what price ceiling, from which categories of merchants, within what time window. The Cart VC is issued by the agent to the merchant and lists the actual items the agent proposes to buy — the merchant compares Cart against Intent before charging, and refuses the transaction if the Cart exceeds the Intent's scope. The Payment VC is issued by the merchant back to the agent (and to the user's identity provider) as receipt-shaped evidence that the transaction cleared under those authorised terms.
{
"@context": ["https://www.w3.org/ns/credentials/v2",
"https://ap2-protocol.org/schemas/cart/v1"],
"type": ["VerifiableCredential", "CartMandate"],
"issuer": "https://agent.acme.example",
"validFrom": "2026-07-10T14:22:11Z",
"validUntil": "2026-07-10T14:32:11Z",
"credentialSubject": {
"intentRef": "urn:ap2:intent:9c4a2b",
"merchant": "https://merchant.example",
"items": [{"sku": "A-1027", "qty": 1, "price": {"amount": "42.50", "currency": "USD"}}],
"total": {"amount": "42.50", "currency": "USD"},
"authorisedBy": "did:key:z6Mkf..."
},
"proof": {"type": "DataIntegrityProof", "cryptosuite": "eddsa-2022", "proofValue": "..."}
}
The lifecycle links the three via reference: the Cart VC's intentRef names the Intent it is bound to, the Payment VC references the Cart it settles. Any party that holds the chain can verify signatures independently — the user's identity provider can prove the Intent it issued; the merchant can prove the Cart it accepted; both can prove the Payment. Because they are VCs rather than session cookies, the artifacts survive out of the flow — they can be archived, replayed to auditors, and stored beyond the life of the underlying HTTP session. This is what makes AP2's paper trail useful for compliance rather than merely for real-time authorisation.
Where AP2 sits in the stack.
AP2 sits above A2A v1.0 and above MCP; it does not replace either. In a typical shopping flow the user talks to a shopping agent; the shopping agent talks to merchant agents over A2A, or to merchant APIs over MCP, or to a mix; and AP2 is the mandate layer that runs on top of both, carrying the Intent/Cart/Payment triple in whatever transport the underlying protocol supplies. On A2A, the mandates ride as structured artifacts on the task; on MCP, they ride as tool inputs and structured outputs. On direct HTTP APIs, they ride in the request and response bodies. AP2's transport-independence is deliberate — it means a merchant already integrated with A2A does not need to add a new transport to accept mandates, only a new content type.
The Agent Cards mechanism dovetails with this: an A2A merchant agent that accepts AP2 mandates advertises so in its extended card, along with the mandate schemas it supports and the identity providers it trusts as Intent issuers. A shopping agent reads the merchant card, discovers whether the merchant will accept the user's Intent format, and either proceeds or falls back to a non-agent flow (redirecting the user to a human checkout). The consequence for architecture is that AP2 does not push agents into a new topology — the same agent-to-agent or agent-to-tool topology carries the mandates without additional plumbing.
The stablecoin pitch, examined.
Every AP2 blog post that trended on Hacker News in late 2025 opened with a paragraph about stablecoins and how AP2 would let agents settle across border in seconds without banks. The AP2 specification is agnostic about the underlying rail — it can bind to card networks, to bank rails, to real-time payment schemes, and to stablecoin rails — but the specification does not require or particularly favour stablecoins over any of the others. The stablecoin narrative comes from the initial launch partners, some of whom sell stablecoin infrastructure and had commercial reasons to lead with that framing. The specification itself treats the rail as one signed field on the Payment VC among many.
The reason to hold the stablecoin pitch at arm's length is that most agent commerce in 2026 and 2027 will run on the rails the merchants already have, because the mandate story is what solves the actual bottleneck. Merchants already accept cards; the problem was not that cards were too slow but that merchants could not tell an agent from a stolen card. Once AP2 fixes that problem, the "settle in stablecoin" argument reduces to "you save the interchange fee if you can also convince the buyer to hold stablecoin" — a real saving in niche cases, not a category-defining shift. Read the stablecoin claims as one thing AP2 can carry, not as the reason to adopt AP2.
Adoption reality.
Google announced AP2 at Cloud Next in September 2025 with 60+ launch partners across payment processors, card networks, and merchant platforms. That number is credible for signalling — the participation of major processors and both major card networks means the protocol has the interchange side of the ecosystem on-side, which is the hardest part. The number does not translate into "60 places you can pay through AP2 today"; as with any commerce protocol, the merchant-side rollout lags the processor-side commitment by 12 to 24 months, and the visible-in-production merchant count in mid-2026 is smaller than the launch-partner count by a factor of five or so.
Two things are worth pinning for architecture decisions today. First, if your product involves an agent making purchases on behalf of a user, plan against AP2 as the mandate layer even if you cannot use it end-to-end yet — the alternative (using shared card credentials, or user redirects that break the agent flow) is worse and getting worse as merchants push back. Second, do not build AP2 into the critical path for flows where the merchant is not yet AP2-aware; keep an execution path that degrades cleanly to a human checkout, and expect that path to still carry most transaction volume through 2027. The commerce layer sits above the interop layer for structural reasons, and its adoption curve is on the merchant timescale, not the agent-vendor timescale.