Agentic Commerce Protocols Compared: ACP, UCP, AP2, TAP, VIC, AP4M, MPP and PAP by Layer

Agentic commerce protocols are the open standards that let an AI agent find a product, prove who it acts for, pay and settle. At least eight now matter, and they do different jobs in three layers. The buyer layer records what the person authorised. The seller layer lets a business expose checkout to agents and recognise them. The middle layer moves and settles the money. Pick by layer, not by logo.

If your team has been asked "which of these do we support?", start here. This guide covers what each protocol does as of October 2026, what has shipped versus what is only announced, and the gap that opens when a business supports more than one. If you would rather walk through your own stack, talk to us.

Key takeaways

• The eight protocols split into three layers. Most businesses need one from each layer, not one overall.
• ACP and UCP are seller-side checkout standards. TAP is seller-side agent recognition. AP2, Visa Intelligent Commerce and PAP describe what the buyer authorised. MPP and AP4M move and settle the money.
• Every protocol carries the buyer's authority in a different format: a signed mandate, a scoped token, a signed HTTP request, an OAuth scope or a pre-authorised payment. None of them reads the others' format.
• A business on three protocols therefore runs three sets of spending limits and keeps three different audit records. That is the gap to plan for.
• None of the eight specifications says who bears the loss when an agent buys the wrong thing, and none standardises a shared record of what was refused.

What are the three layers of agentic commerce?

The three layers of agentic commerce are the buyer layer, the seller layer and the middle layer. The buyer layer captures what a person authorised their agent to do. The seller layer lets a merchant publish checkout to agents and verify them. The middle layer authorises, moves and settles payment, including machine-to-machine payments too small for a card.

The timing matters. McKinsey estimates agentic commerce could orchestrate up to $1 trillion in US retail revenue by 2030 (McKinsey, Oct 2025). Today the volume is small. Checkout.com research reported in July 2026 found 89% of merchants preparing for agentic commerce, while only 3% of transactions involved an AI agent (Forkast, Jul 2026).

Protocol choices made now, before that volume arrives, are the expensive ones to undo later. Here is the whole map. "Main layer" is the job each protocol is mainly built for. The last column shows the second layer it touches.

Key takeaway: the protocols are not rivals for one slot. They are parts of one transaction, and most businesses will run one from each layer.

Seller-layer protocols: how do merchants expose checkout to AI agents?

The seller layer answers a merchant's two questions: how does an agent check out with me, and how do I know this agent is legitimate? ACP and UCP answer the first. TAP answers the second.

What is the Agentic Commerce Protocol (ACP)?

The Agentic Commerce Protocol (ACP) is an open standard created by Stripe, OpenAI and Meta that defines how AI agents complete purchases with businesses on a buyer's behalf. ACP covers checkout sessions, product feeds and carts, delegated payment tokens, delegated authentication through OAuth 2.0, and order webhooks. The current specification is dated 17 April 2026.

ACP launched in September 2025 alongside Instant Checkout in ChatGPT (Stripe docs). Its delegated payment design means the agent passes a scoped payment token to the business, so the AI platform never handles raw card details. The full specification lives at agenticcommerce.dev.

The product around ACP has moved more than the standard. In March 2026 OpenAI scaled back Instant Checkout after weak uptake, saying the first version "did not offer the level of flexibility" it wanted. Merchants can now keep their own checkout inside ChatGPT, and the focus shifted to product discovery (Retail Gazette, Mar 2026).

Support ACP if: you sell to US consumers and want to be purchasable from ChatGPT and other ACP agents. If you are on Stripe, much of the work is done for you.

What is the Universal Commerce Protocol (UCP)?

The Universal Commerce Protocol (UCP) is Google's open standard for agentic shopping, launched in January 2026 and co-developed with Shopify, Etsy, Wayfair, Target and Walmart. UCP lets an agent discover what a business sells and which payments it accepts, run checkout, apply discounts and track the order, over plain APIs, A2A or MCP.

More than 20 other companies endorsed UCP at launch (InfoQ, Jan 2026). Two design choices make it the broadest seller standard. It is transport-agnostic, so one capability document can serve several agent platforms. It also separates the payment instrument from the payment handler, so a merchant is not locked to one processor.

Google's own implementation powers buying inside AI Mode in Search and in Gemini. UCP hands payment authorisation to AP2.

Support UCP if: you want to be purchasable inside Google surfaces, or you want one capability document that more than one agent platform can read.

What is Visa's Trusted Agent Protocol (TAP)?

Visa's Trusted Agent Protocol (TAP) is a standard, built with Cloudflare and released on 14 October 2025, that lets merchants tell trusted shopping agents apart from bots. The agent signs its HTTP requests using the HTTP Message Signatures standard, aligned with IETF Web Bot Auth, so the merchant can verify who sent each request.

A TAP-signed request carries three things: a signal that the agent is trusted and intends to browse or buy, whether the consumer already has an account with the merchant, and optional payment data (Visa).

Launch partners included Adyen, Checkout.com, Coinbase, Fiserv, Microsoft, Shopify, Stripe and Worldpay. The initial TAP specification applies to the Visa network.

Support TAP if: your bot defences are blocking agents you want, or you want to recognise returning customers who arrive through an agent.

Key takeaway: ACP and UCP decide how an agent checks out with you. TAP decides whether you let that agent in.

Buyer-layer protocols: how is a person's authority recorded?

The buyer layer answers the question every dispute comes back to: what did the person actually authorise? AP2 records it as signed mandates, Visa Intelligent Commerce as network credentials with limits, and PAP as consented account access.

What is the Agent Payments Protocol (AP2)?

The Agent Payments Protocol (AP2) is Google's open protocol, announced on 16 September 2025, for recording what a user authorised an AI agent to buy. AP2 uses signed mandates: an intent mandate captures what the user wants, and a cart mandate captures their approval of a specific basket. More than 60 merchants and financial institutions backed it at launch.

An intent mandate might read "white running shoes, size 10, under $120." A cart mandate approves the exact pair in the cart. For fully delegated purchases, a detailed intent mandate with price limits and timing lets the agent produce the cart mandate itself (TechCrunch, Sep 2025).

AP2 also has an x402 extension, built with Coinbase, MetaMask and the Ethereum Foundation, so the same mandates can authorise payment from a crypto wallet.

Support AP2 if: you build the agent, or you accept high-value purchases where you will want proof of the user's instruction later.

What is Visa Intelligent Commerce (VIC)?

Visa Intelligent Commerce is Visa's program for agent payments on its network, launched on 30 April 2025. Visa Intelligent Commerce issues tokenised credentials to a specific AI agent, lets the cardholder set spending limits and conditions, and shares commerce signals with Visa in real time so Visa can apply controls and help manage disputes.

Launch partners included Anthropic, IBM, Microsoft, Mistral AI, OpenAI, Perplexity, Samsung and Stripe (Visa). In Visa's words, "Each consumer sets the limits." In September 2025 Visa added an MCP server and an Acceptance Agent Toolkit for developers.

Visa Intelligent Commerce is the credential and control layer on the Visa network. TAP is how that trusted agent presents itself to a merchant.

Support VIC if: your customers pay by Visa card and you want agent purchases to arrive as recognised, tokenised transactions.

What is the Personal Agent Protocol (PAP)?

The Personal Agent Protocol (PAP) is an open, OAuth-based standard that Sierra and Meta announced on 6 October 2026. PAP defines how a customer's personal AI agent finds a business, signs in with the customer's permission and acts on their account, with the customer choosing read-only or write access and the business choosing how agents reach it.

An agent can open a guest session to check availability or a returns policy. Account access needs the customer to sign in and choose a scope. The business then picks the route: its website, its APIs (MCP or OpenAPI), or its own customer-service agent. Sierra says "companies set parameters for what those agents can do" (Sierra, Oct 2026). Partners include Genesys, Rocket, Shopify, Stripe and Walmart.

PAP is early. The v0.1 specification was due "later this month" at launch and was not public as of 9 October 2026 (eesel, Oct 2026). Payments are a possible future extension, not a current feature.

Watch PAP if: you run high-volume customer service (banking, telecoms, airlines, retail accounts), where agents will soon ask for refunds, changes and cancellations rather than purchases.

Key takeaway: the buyer layer is where liability will be decided, because it holds the only record of what the person actually asked for.

Middle-layer protocols: how do agents pay and settle?

The middle layer authorises, moves and settles payment. It is also where machine-to-machine payments live: agents paying for APIs, data and other agents, often in amounts too small for a normal card transaction.

What is the Machine Payments Protocol (MPP)?

The Machine Payments Protocol (MPP) is an open standard co-authored by Stripe and Tempo and launched on 18 March 2026. With MPP, an agent requests a resource from an API, MCP server or any HTTP endpoint, the service replies with a payment request, the agent authorises it, and the resource is delivered.

For Stripe businesses, MPP payments settle into the existing Stripe balance like any other transaction. Businesses can accept stablecoins, or cards and buy-now-pay-later through Shared Payment Tokens (Stripe, Mar 2026).

MPP also supports sessions, where funds are set aside up front and many small payments settle as one transaction. Visa has extended MPP to card payments and Lightspark to bitcoin over Lightning. Design partners named at launch include Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, Standard Chartered and Visa (The Block, Mar 2026).

Support MPP if: you sell metered access (APIs, data, compute, content) and want agents to pay per use without an account or an invoice.

What is Mastercard Agent Pay for Machines (AP4M)?

Mastercard Agent Pay for Machines (AP4M) is a Mastercard service, announced on 10 June 2026, for payments that AI agents and machines start and complete on their own, including high-frequency, low-value transactions. AP4M covers four functions: credentialing agents, permissioning with spending limits, transacting across providers, and settling across cards, bank accounts and stablecoins.

AP4M builds on Mastercard Agent Pay, the 2025 program for how trusted AI agents take part in payments. Organisations set authorisation rules and spending limits that are "enforced programmatically," per Mastercard's announcement, which lists 32 initial participants including Adyen, Checkout.com, Cloudflare, Coinbase, Stripe and Tempo (Mastercard, Jun 2026).

Mastercard's Verifiable Intent framework, released in March 2026, links the consumer's identity, their instruction and the transaction outcome into one tamper-resistant record. Verifiable Intent is designed to work alongside AP2 and UCP rather than replace them (PYMNTS, Mar 2026).

Support AP4M if: your agents or your customers' agents will make frequent, small, unattended payments and you want them on card-network terms, with stablecoin settlement as an option.

Key takeaway: MPP and AP4M both make agentic payments small and frequent enough for machines. They differ on who runs the network: an open standard on Stripe and Tempo, or Mastercard's rails.

Which agentic commerce protocols should you support first?

Choose agentic commerce protocols by business model. US retailers should start with UCP and ACP, then add TAP. API and data sellers should start with MPP. High-ticket sellers should add AP2 for proof of what the customer approved. Banks and other service businesses should watch PAP. No business needs all eight on day one.

Key takeaway: most businesses need one checkout standard, one way to recognise agents and one way to get paid.

What do agentic commerce protocols not solve?

Agentic commerce protocols do not share one record of the buyer's authority. Each protocol stores that authority in its own format. A business using several runs separate spending limits and separate audit records, keeps no common record of refused attempts, and has no published rule for who pays when an agent gets it wrong.

Here is where each protocol keeps the buyer's authority:

Each format makes sense for its own layer. The gap is not a flaw in any one protocol. It appears when agentic payments run across several at once, which is where most businesses are heading. Three problems follow.

1. Your limits are scattered. Picture a procurement agent that buys through a UCP merchant, pays an API through MPP and settles a supplier on a card network. "No more than $5,000 a week with approved vendors" now has to be set up in three places. No single place enforces it across all three. A weekly cap split across three systems is not a weekly cap.

2. Your records do not line up. When a payment is questioned, the evidence sits in three places: an AP2 mandate, an MPP payment record and a card network record. Each was written by a different party, and each party has a commercial interest in the outcome it recorded.

3. Refusals leave no trace. The protocols describe what was approved. None of them standardises a record of what was blocked. An auditor testing a spending control needs the refusals, because a refusal is the only proof the control did anything.

Underneath all three sits liability. None of the eight specifications sets out who bears the loss when an agent buys something the person did not want. In the US, Regulation E excludes from "unauthorized" transfers those "initiated by a person to whom the consumer furnished the access device."

How that exclusion applies when the credentials were given to an AI agent is an open question (Payments Dive, Oct 2026). Until it is settled, the party that can prove what was authorised wins the dispute.

Key takeaway: the protocols standardise how agents pay. Nothing yet standardises one record of what an agent was allowed to pay for across them.

Where does Abstraxn fit with agentic commerce protocols?

Abstraxn sits beside agentic commerce protocols, not in place of them. Abstraxn's KYI (Know Your Intent) checks each agent payment against one signed mandate before it executes, whichever protocol carries it, and returns a signed receipt for every decision, including refusals. Abstraxn holds no funds and no keys.

One mandate across every protocol. The person responsible for the agent writes the rules in plain English, for example: "Approved vendors only, $500 per order, $5,000 a week, anything else waits for Priya." KYI reads them back as exact rules. The owner confirms them once, and the confirmed version is signed.

Before the agent completes an ACP or UCP checkout, authorises an MPP payment or pays over x402, it checks that one mandate. The weekly cap holds across all of them because it lives in one place.

One weekly limit, three protocols: a worked example

Here is the procurement agent from above, with a mandate of approved vendors only, $500 per order and $5,000 a week. It has already spent $4,600 this week.

Without one mandate, the third attempt goes through, because ACP's token, MPP's payment and the card network each see only their own slice of the week. The receipt for the refusal looks like this:

decision:  deny
rule:      weekly_cap
passed:    vendor, per_order
version:   2
receipt:   0x7c4e…19af

One receipt for every decision, including refusals. Every check returns a decision with a signed receipt naming the rule and the mandate version. Refusals take the same path as approvals. A third party can verify each receipt without access to your systems or ours.

What we learned building it. We wired KYI into Sorted, an invite-only demo where one agent shops across public MCPs of some of the biggest names in quick commerce and food delivery. Sorted is a demo, not a product, and is not affiliated with those vendors. The main lesson: none of the vendor endpoints verified the user's mandate themselves. So the check had to sit before checkout, outside every vendor, which is the design above (how we built Sorted).

What is live, and what we set up with you. Approved-counterparty lists, per-transaction limits and signed allow and deny receipts are live today. Limits over time (weekly or monthly caps), routing to a named approver and protocol-specific hooks are configured with our team for each deployment, because every business draws those lines differently.

Rails and wallets where you need them. For agents that pay for tools, data and services, Abstraxn provides smart-account wallets (ERC-4337 and EIP-7702) with x402 and MPP payment rails. Live policy controls cover address allowlists, blocklists and per-transaction limits.

What Abstraxn does not touch. KYI holds no funds, holds no keys and does not sit in the payment path. Your checkout, your processor and the card networks keep doing what they do. That separation is deliberate. A record kept by a party with no stake in whether the payment succeeds is the only kind an auditor or a disputes team can rely on.

Frequently asked questions

Related reading

• Know Your Intent (KYI): Agents Have an Identity Layer. They Have No Intent Layer.
• Know Your Agent (KYA): What It Proves, What It Misses, and the Controls AI Agents That Spend Still Need
• Who Is Liable When an AI Agent Is Right?
• The AI Agent Security Questionnaire