The State of Agentic Commerce Standards, Mid-2026

Agentic commerce stopped being a thought experiment some time in late 2025. By mid-2026 the question is no longer whether AI agents will transact on behalf of shoppers, but which standards they will speak when they do. The honest answer today is: several, at once. This is a snapshot of where the major protocols stand, what shipped recently, and one concrete spec gap we have been working to close.

Three protocols, coexisting

The most important fact about the standards landscape is that there is no single winner, and merchants who plan for one will be caught short. Three protocols occupy distinct but overlapping layers.

MCP — Model Context Protocol. Originating at Anthropic and fully open, MCP is the layer that exposes a system's tools and data to an LLM agent. Adoption has been the steepest of the three: SDK downloads climbed from roughly 100K per month at launch to tens of millions per month by early 2026, with thousands of public MCP servers now live. WooCommerce shipped a native MCP in version 10.3, and WordPress 7.0 standardised the underlying Abilities API for the whole ecosystem.

ACP — Agentic Commerce Protocol. Backed by Stripe and OpenAI and released under Apache 2.0, ACP focuses on the purchase transaction itself — the checkout and payment handshake between an agent and a merchant.

UCP — Universal Commerce Protocol. Backed by Google and Shopify, also Apache 2.0, UCP defines the end-to-end commerce flow including a formal checkout state machine. It is the protocol where much of the hard transactional edge-case work is currently being hammered out in the open.

These three are not interchangeable and they are not mutually exclusive. A multi-channel merchant in mid-2026 has to think about MCP, ACP and UCP simultaneously, because different agents and platforms will reach them through different doors.

AP2: the mandate layer underneath

Beneath the transaction protocols sits AP2, the agent-payments mandate model. AP2 introduces signed Intent and Cart Mandates: cryptographic evidence that a buyer authorised a specific purchase, carrying a Time-to-Live (TTL). The Cart Mandate is the merchant's non-repudiable proof of authorisation — the artifact that makes a disputed agent transaction defensible. As we will see, getting the lifecycle of that mandate exactly right is where a lot of the current spec work is concentrated.

What shipped recently

WordPress 7.0 (May 2026) standardised the Abilities API across the platform, giving every WordPress and WooCommerce store a common way to expose capabilities to agents.

WooCommerce 10.7 (April 2026) added native ACP support via an agentic_commerce flag on payment gateways, following the WooCommerce MCP that landed in 10.3.

3DS2 in UCP is moving toward being a first-class scenario (tracked in UCP issues #420 and #421). This matters more than it sounds: 3-D Secure challenges can take minutes when a buyer is interrupted, which turns long-running completions from an edge case into a normal one.

A spec gap we worked to close: mandate expiry mid-checkout

While implementing a UCP merchant server for long-tail (non-Shopify) merchants, we hit a question the spec did not answer, and opened it as UCP issue #512: what happens when an AP2 mandate reaches its TTL after Complete Checkout has been accepted but before payment finishes — while the checkout is in complete_in_progress?

This is not theoretical. Asynchronous European payment rails (SEPA Direct Debit, iDEAL, Bancontact), interrupted 3DS challenges, and PSP retries on soft declines all routinely push processing past a mandate's remaining lifetime. Without a normative answer, identical checkouts would succeed on one merchant stack and fail on another, and a payment authorised against an expired mandate would weaken the very audit trail AP2 exists to provide.

The discussion converged on a clean model:

• Evaluate once, then freeze. Mandate TTL is checked a single time, at receipt of Complete Checkout. Once accepted, processing runs to a terminal state regardless of later expiry. This follows an authorisation-versus-liveness split: acceptance settles authorisation; the TTL only gates whether the grant may be entered, never whether in-flight work stays authorised.
• Grounded in AP2 and PSD2. AP2 gives the buyer no in-protocol channel to revoke a mandate before its TTL, so the TTL is a pre-agreed bound, not a live withdrawal signal. This mirrors PSD2, where consent withdrawal (Art. 64) is bounded by irrevocability (Art. 80) — acceptance of Complete Checkout is the natural irrevocability point.
• A signed terminal artifact for the lapse. If a mandate is already expired at acceptance, the checkout never enters complete_in_progress; instead a signed EXPIRED cancellation receipt becomes the terminal state, drawn from a closed enum (USER_REQUESTED / MERCHANT_REQUESTED / COMPLIANCE_TERMINATED / EXPIRED).
• One verification path, two outcomes. The positive recorded evaluation (authorised-and-ran) and the EXPIRED receipt are siblings: the same signed, evidentiary shape verified through a single path — JCS canonicalisation (RFC 8785) plus Ed25519 — rather than two bespoke verifiers.
• Merchant-declared policy. The capability profile advertises the policy, an optional min_remaining_ttl, and the signing profile, so a platform knows the rules before it calls Complete Checkout.

The next step is normative spec text: a shared, versioned receipt envelope with a receipt_type discriminator, a common binding field tying both receipts to the same checkout, and distinct, normatively separated timestamps so revocation timing stays auditable. It is a small change with outsized impact: it is the difference between a deterministic, defensible audit trail and a pile of divergent PSP behaviour. We document the full lifecycle model — the evaluate-once-then-freeze rule, the single verification path behind both outcomes, and the merchant capability profile — on our UCP mandate-evaluation reference page.

What this means for merchants

You do not need to pick a protocol winner, because there is not going to be one soon. You need to be readable and transactable across all of them, and you need your platform — or your audit layer — to handle the unglamorous edge cases like mandate expiry correctly. The standards are maturing fast, in the open, and the merchants who follow the spec discussions are the ones who will not be surprised by the next normative change.

MerchantStamp audits catalog and storefront readiness against MCP, ACP and UCP side by side, so you can see where you stand across every door an agent might use. Run a free scan to check your current state.