Three protocols, three sponsors, three layers – and one stack that lead-gen platforms now have to read before any agent-routed flow makes it to a buyer.
Three Protocols, Three Layers, One Stack
The Agentic Commerce Protocol, the Agent Payments Protocol, and the Model Context Protocol arrived as separate announcements across a nine-month window. They were positioned in the press as rivals. They are not. They sit at different layers of the same stack.
ACP, co-developed by OpenAI and Stripe and released under Apache 2.0 on September 29, 2025, defines the HTTP contract between an AI agent and a merchant for a single purchase event. It specifies how an agent creates a checkout session, updates a cart, completes an order, and receives order-status webhooks. The Stripe-issued Shared Payment Token is its payment primitive: a scoped, single-use grant that lets the agent pay without ever touching the cardholder’s credentials. At launch ChatGPT routed buyers directly into Etsy and committed to rolling out across more than one million Shopify merchants – Glossier, Vuori, Spanx, SKIMS named at the front of the queue.
AP2, announced by Google on September 16, 2025 with more than sixty launch partners, defines a different layer. AP2 does not specify checkout endpoints. It specifies three cryptographically signed mandate artifacts – Intent, Cart, and Payment – expressed as W3C Verifiable Credentials and carried between parties as JSON objects. Mastercard co-developed a companion Verifiable Intent specification that operates as a tamper-resistant audit log of what the user authorized. On April 28, 2026 Google donated AP2 and Verifiable Intent to the FIDO Alliance and shipped v0.2, which added “Human Not Present” payment flows that let an agent execute pre-authorized transactions without an interactive consent prompt. Sixty organizations signed onto the donation: Mastercard, American Express, PayPal, Coinbase, Adyen, Salesforce, ServiceNow, Worldpay, Etsy, Intuit, JCB, Mysten Labs, Revolut, UnionPay International, Forter, and more.
MCP, introduced by Anthropic in November 2024, sits below both. It defines a JSON-RPC envelope, a client-server transport (stdio and HTTP-with-Server-Sent-Events), and a server interface that exposes tools, prompts, and resources to AI agents. By December 2025 Anthropic had donated the protocol to the Linux Foundation’s newly formed Agentic AI Foundation, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare, and Bloomberg. By March 2026 the SDKs had passed 97 million monthly downloads. As of May 24, 2026 the official MCP Registry recorded 9,652 latest server records and 28,959 server/version records, with thousands more cataloged outside the official registry across PulseMCP (15,930+), Smithery (~7,300), and Composio (1,000+ toolkits, 20,000+ tools). Whatever a single number says, the ecosystem outpaces anything competing for the same surface area.
The simplest way to read the three together: MCP defines what an agent can read and call, ACP defines how an agent buys, AP2 defines how the user’s intent and the merchant’s charge are cryptographically witnessed. A single agentic flow can use all three, and many already do. Stripe’s own Machine Payments Protocol, announced in March 2026, sits explicitly across the layers – defining how agents execute payments against APIs, MCP servers, and HTTP endpoints, with SPT handling the fiat settlement that ACP or AP2 specify the surrounding context for.
For lead-gen platforms, the question is not which protocol wins. The question is which protocols a buyer or a routing agent will require evidence from before paying for an agent-originated lead. That answer is already three.
ACP: The Transaction Layer
The Agentic Commerce Protocol specification lives at github.com/agentic-commerce-protocol with continuous release notes. The initial release dated 2025-09-29 was followed by a fulfillment enhancements release on 2025-12-12, a capability-negotiation release on 2026-01-16, and extensions plus discount features on 2026-01-30. The cadence is fast and visible. Contributors sign a CLA. Substantive changes go through a Specification Enhancement Proposal process documented in docs/governance.md. Founding maintainers are OpenAI and Stripe with a stated path toward broader community governance.
What ACP actually specifies on the wire is a small set of HTTP endpoints a merchant exposes once and any compliant agent can call. The merchant implements:
| Endpoint | Purpose |
|---|---|
| Create Checkout | Agent posts SKU and quantity, merchant returns cart context, fulfillment options, and supported payment methods |
| Update Checkout | Agent revises cart line items, shipping address, or fulfillment selection; merchant returns updated totals |
| Complete Checkout | Agent submits the Shared Payment Token; merchant authorizes the charge and returns an order confirmation |
| Order Updates Webhook | Merchant pushes order status changes (paid, shipped, refunded) back to the agent for the user’s record |
The Shared Payment Token is the protocol’s most novel piece. Stripe describes it as a scoped, programmable grant: scopeable to a specific business, limited by time or amount, revocable at any moment, and observable through webhook events. The buyer’s underlying payment credentials never leave the buyer’s wallet provider or Stripe’s vault. In June 2026 Stripe extended SPT support to Mastercard Agent Pay and Visa Intelligent Commerce networks, plus buy-now-pay-later methods including Affirm and Klarna, making SPT the first agent-payment primitive supporting both agentic network tokens and BNPL through a single artifact.
For a lead-gen platform, ACP support matters when the agentic flow includes an actual purchase. That includes:
- Insurance: Agent-initiated binding of an auto or home policy, where the lead-gen platform is also the broker of record or sits next to an aggregator that is.
- Premium financing: Agent-routed financing of insurance premiums or lead-package subscriptions.
- Paid lead packages: Agent-purchased prepaid lead credits or subscription packages from a marketplace like MediaAlpha or QuinStreet.
- Vertical commerce: Solar quote-to-purchase, home services quote-to-deposit, mortgage application-to-fee flows where money moves at the agentic boundary.
For lead-gen platforms whose entire flow ends at the lead handoff with no payment event, ACP support is optional. The flow can still terminate at an MCP tool call that submits the lead to the buyer’s CRM. ACP becomes mandatory only when an agent is paying for something the platform is selling.
A practical observation: ACP launched aggressively on the OpenAI ecosystem (ChatGPT Instant Checkout) but the specification is agent-agnostic. Any agent that speaks the protocol can transact with any ACP-compliant merchant. Implementations from commercetools, Shopify, Etsy, and the named Shopify launch merchants are already in production. Whatever the Reddit thread of the week says about OpenAI lock-in, the on-the-wire spec is Apache 2.0 and does not require a ChatGPT-specific runtime.
AP2: The Verifiable Intent Layer
AP2’s design choice was different. Where ACP specifies what happens on the wire, AP2 specifies what evidence the parties carry about user authority. The mandate trio is the central abstraction:
| Mandate | What it evidences | Signed by |
|---|---|---|
| Intent Mandate | What the user authorized the agent to do (price range, brand restrictions, fulfillment constraints) | User’s wallet key |
| Cart Mandate | What the agent assembled within that authority (specific cart contents, totals, merchant) | Agent’s key |
| Payment Mandate | What the merchant or network will charge against the user’s payment instrument | Merchant or PSP key, with user signature on amount |
Each mandate is a W3C Verifiable Credential. That choice matters: it means AP2 mandates can be verified by any party that understands W3C VC chains, without bilateral integration with Google or any specific PSP. Verifiable Intent, the Mastercard companion specification, operates as the tamper-resistant audit log – a record of mandate emission, modification, and use that can be inspected by issuing banks, networks, regulators, and the user.
The April 28, 2026 donation to FIDO and the v0.2 release added a flow that the protocol’s first version explicitly excluded: “Human Not Present” payments. Under v0.2, an agent can execute payments against pre-authorized mandates without a real-time consent prompt – a subscription renewal, a triggered reorder, a programmed transfer. The change matters for lead-gen because it opens the door to agent-managed buyer accounts that auto-renew lead-package subscriptions without a per-cycle approval. Subscription marketplaces should expect those flows in 2027.
The FIDO governance structure is the second piece operators should track. Two new Technical Working Groups stood up at FIDO alongside the AP2 donation:
- Agentic Authentication TWG – extends FIDO’s existing passkey and webauthn standards to cover agent identity and delegation.
- Payments TWG – develops interoperable standards for agent payment authorization on top of AP2 and Mastercard Verifiable Intent.
Output from those groups will define the cross-network interoperability layer that lets an AP2 mandate emitted by a Google-stack agent satisfy a Mastercard, Visa, or American Express payment authorization. That interoperability is what makes AP2 a network-wide standard rather than a Google-stack feature.
The lead-gen relevance of AP2 lives at the consent-and-evidence layer. The previously published analysis of AP2 mandates as an evidence layer beside lead-buyer consent detailed how a mandate can support evidence of user delegation, payment authority, and purpose-limited scope, without by itself satisfying TCPA, GDPR, state privacy law, or buyer-specific lead consent. That framing holds. Lead operators should treat mandates as one of several layers in the evidence stack – strong for “who was the user, who was the agent, what was authorized” and orthogonal to “did the user grant prior express written consent for marketing contact.”
MCP: The Tool and Context Layer
MCP is the oldest of the three and the most ubiquitously deployed. Anthropic introduced it on November 25, 2024 to solve a narrower problem than agentic commerce: how to give an LLM access to external data and tools through a standard interface rather than per-vendor integrations. The early adoption curve was vertical-developer, not commerce-merchant. Within twelve months it had collected every major model provider.
The original protocol defines:
- Servers that expose tools (callable functions with typed inputs and outputs), prompts (reusable prompt templates), and resources (structured documents an agent can read).
- Clients that connect to servers and surface the available tools to an LLM.
- Transports – stdio for local processes, HTTP with Server-Sent Events for remote servers, plus a streamable HTTP variant standardized in 2025.
By mid-2026 the ecosystem looked like this: 97 million monthly SDK downloads across Python and TypeScript, 9,652 servers in the official registry (28,959 versions), and material catalogs at PulseMCP, Smithery, and Composio totaling tens of thousands of tools in aggregate. ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code all consume MCP servers natively. AWS, Cloudflare, Google Cloud, and Microsoft Azure all expose MCP-native runtimes. Stacklok’s 2026 software report measured 41% of surveyed software organizations in limited or broad production with MCP servers.
The December 9, 2025 donation to the Linux Foundation’s Agentic AI Foundation transferred stewardship without changing the maintainer set. The Agentic AI Foundation is a directed fund. Anthropic, Block, and OpenAI are co-founders. Google, Microsoft, AWS, Cloudflare, and Bloomberg are supporting members. The AAIF Governing Board makes decisions on strategic investments, budget allocation, member recruitment, and approval of new projects. Individual projects, including MCP, maintain full autonomy over technical direction. The same maintainers who stewarded the protocol at Anthropic continue to steward it under the foundation, guided by community input through the SEP process.
For a lead-gen platform, MCP is the entry ticket. A platform that exposes its lead-management capability as an MCP server can be invoked by any compatible agent runtime. The simplest useful exposure is a small tool surface:
searchLeadCriteria({ vertical, zip, age, intent })– returns matched buyer panels and floor prices.submitQualifiedLead({ vertical, contact, consent_token, traffic_source })– accepts a lead with a TrustedForm or Jornaya consent token, validates against the platform’s compliance rules, and returns a routing decision.getOrderStatus({ lead_id })– returns sale or rejection status from the buyer’s CRM.
The above is not a hypothetical. The previously published WebMCP tool-defined lead capture analysis covers the browser-side counterpart, and MCP enterprise middleware for lead-gen platforms covers the server-side patterns aggregators are shipping in production. MCP support is mature enough in 2026 that “we don’t have an MCP server” is no longer a defensible operator posture.
Where the Protocols Stack and Where They Don’t
The three protocols are easier to read alongside each other than in isolation. The reference shape:
| Layer | Protocol | Primary sponsor | Governance home | What it defines | Primary artifact |
|---|---|---|---|---|---|
| Context / tools | MCP | Anthropic | Linux Foundation (Agentic AI Foundation, Dec 2025) | How agents discover and invoke tools, prompts, and resources | JSON-RPC server interface, MCP server registry entries |
| Transaction / checkout | ACP | OpenAI + Stripe | OpenAI/Stripe as Founding Maintainers, SEP process | How an agent completes a purchase with a merchant | HTTP endpoint contract, Shared Payment Token |
| Payment authorization / intent | AP2 | Google + Mastercard | FIDO Alliance (April 28, 2026) | How user authority and merchant charge are cryptographically witnessed | Intent / Cart / Payment Mandates as W3C Verifiable Credentials |
A clean agentic flow uses all three. The agent uses MCP to query a lead-gen platform’s tool surface for available buyer panels. The agent uses ACP to settle the lead-package subscription the buyer is paying for. The agent emits AP2 mandates to evidence that the user authorized this specific buying behavior with this specific price ceiling. Inside the rails, Stripe’s Machine Payments Protocol acts as the connective tissue, defining how agents execute payments against the underlying APIs, MCP servers, and HTTP endpoints that the three protocols touch.
Where they don’t stack cleanly: each protocol covers a slightly different scope, and the overlaps are where governance work is happening through 2026-27. Three live ambiguities to watch:
-
Consent dual-evidence. An ACP receipt and an AP2 mandate both witness “the user authorized this purchase.” They evidence overlapping but not identical things. ACP focuses on the cart transaction; AP2 focuses on the delegation chain and intent scope. A lead-gen buyer asked to honor both has to decide which one binds, which is the open work at FIDO’s two new TWGs.
-
Card network translation. Mastercard’s Agent Pay, Visa’s Intelligent Commerce Connect (announced April 8, 2026), and the AP2 mandate flow need to interoperate end-to-end. The translation paths exist – Visa Intelligent Commerce Connect supports Trusted Agent Protocol, Machine Payments Protocol, ACP, and Universal Commerce Protocol simultaneously – but a merchant receiving a settlement event still has to read the mandate references against the actual ACP order context to reconstruct the authorization chain.
-
MCP-as-payment-surface. MCP servers can in principle expose payment tools directly, and Stripe’s Machine Payments Protocol assumes they will. That collides with ACP’s “merchant-defines-checkout” model. The pragmatic answer in 2026 is that MCP servers expose query and submission tools; payments terminate at ACP endpoints or at AP2-authorized PSP rails. Whether MCP’s evolving spec eventually folds checkout in directly is an open question that the Agentic AI Foundation will adjudicate.
A pattern for operators: when the protocols overlap, follow the artifact. If the artifact is a JSON-RPC tool result, it’s MCP. If the artifact is an HTTP order confirmation with an SPT reference, it’s ACP. If the artifact is a signed Verifiable Credential carrying mandate scope, it’s AP2. Different artifacts, different evidence, different obligations.
What Lead-Gen Platforms Must Support
The earlier “which protocol matters” question collapses to operator math. For a lead-gen platform sitting between agent traffic and lead buyers, the priority order in mid-2026 looks like this:
Tier 1 – Required to be discoverable by agents at all:
- MCP server exposing read and submit tools.
- Schema.org markup that survives MCP-aware crawling and matches the tool schemas.
- Agent-friendly authentication (OAuth client credentials with scoped tokens) so an agent can authenticate without a human-in-the-loop step.
Tier 2 – Required to monetize agent traffic if money moves at the platform boundary:
- ACP endpoints for any purchase event (lead-package subscriptions, lead-pack credits, premium financing flows).
- SPT acceptance pathway via Stripe or via a PSP that supports SPT translation.
- Receipt-and-confirmation hooks that emit order events back to the calling agent for the user’s audit trail.
Tier 3 – Required when buyers price by agent-verified consent (insurance, lending, healthcare verticals):
- AP2 mandate ingestion and verification: accept mandates as part of the lead payload, verify the W3C VC chain, store the mandate alongside TrustedForm or Jornaya tokens.
- Verifiable Intent log integration: emit mandate-use events to the Verifiable Intent rail so issuing banks and the user can reconcile authorization.
- KYA (Know Your Agent) verification stack on top of the mandate – covered in detail in the Know Your Agent identity layer analysis – that binds the agent’s identity to the human principal.
Tier 4 – Required by the most sensitive buyer panels in 2027 and beyond:
- FIDO TWG outputs as they ship through 2026 and 2027.
- Cross-network mandate translation (Mastercard Agent Pay, Visa Intelligent Commerce, American Express agent rails) so a single lead can settle against any buyer’s preferred network.
- The Machine Payments Protocol stack from Stripe where agent-to-API or agent-to-MCP-server payments are the primary settlement path.
The cost-to-value gradient runs left to right. MCP integration is the cheapest and most leveraged; a competent platform team can ship a usable MCP server in two sprints. ACP integration costs more but pays out directly in conversion when buyers route purchases through the platform. AP2 integration is the most expensive – accepting and verifying W3C Verifiable Credentials inside a TCPA-aware compliance stack requires legal review, cryptographic infrastructure, and storage planning – but it is what buyers in regulated verticals will increasingly demand.
A practical anti-pattern: shipping ACP without MCP. ACP-only platforms are reachable by buyers who already know the platform exists. They are not discoverable by agent runtimes browsing the MCP registry for lead-management tools. Discoverability comes from MCP. Settlement comes from ACP. Evidence comes from AP2. In that order.
Interaction With TCPA, TrustedForm, and the Consent Stack
The three protocols are payment-rail and tool-rail artifacts. They do not replace the marketing-consent record that TCPA requires for telemarketing contact, and they do not replace the data-rights stack that GDPR, CCPA, the Texas Data Privacy and Security Act, and the growing list of state mini-TCPA regimes require for consumer data.
The clean way to read the interaction:
- TCPA prior express written consent. Captured at the moment a lead is generated – typically by a TrustedForm certificate, a Jornaya LeadiD token, or an ActiveProspect consent record – and traveling with the lead through the routing chain. AP2 mandates do not substitute for this record. They evidence agent authority over a transaction, not consumer authority to be contacted via regulated technology.
- GDPR Article 6 lawful basis. Required for any processing of European personal data. AP2 mandates can support a record-of-consent argument when the agent’s actions were performed with explicit user authority, but the underlying lawful-basis analysis is unchanged.
- State privacy laws. TDPSA, CCPA/CPRA, MODPA, Connecticut, Colorado, and others all impose data-rights regimes orthogonal to the protocol stack. Mandate-based evidence does not preempt them.
- Card-network cardholder authorization. Mastercard Verifiable Intent and Visa Intelligent Commerce Connect operate within the existing cardholder-authorization regime. The mandate strengthens evidence at chargeback, but does not substitute for the issuer’s risk decision.
- Buyer contract acceptance. Lead-buyer marketplaces impose their own consent and traffic-source rules. Mandate references can become part of those contracts, but each buyer defines what evidence package they will accept.
The earlier publication on Know Your Agent as a TCPA replacement claim framed this exact line: identity verification of the agent supplements TCPA consent, it does not replace it. The same framing applies one layer up. ACP receipts and AP2 mandates strengthen the evidence stack. They do not collapse it into a single artifact.
A useful image for the consent picture in 2026: a lead-buyer’s compliance review of an agent-originated lead pulls evidence from at least five sources – TrustedForm or Jornaya, the AP2 mandate trio, the ACP order receipt, the KYA agent-identity record, and the lead-buyer’s own pre-contract acceptance log. The protocols are interoperable inside the rails. The compliance review is still a multi-source reconciliation exercise that compliance and legal own.
A separate concern compounds this: agentic browsers (Comet, ChatGPT Atlas) introduce the form-fraud risk surface covered in the agentic browser form fraud analysis. The protocol artifacts strengthen evidence, but they do not by themselves prove a human was in the loop at the moment of consent. Operators integrating the protocols still need humanity verification – TrustedForm Insights, behavioral biometrics, device attestation – at the consent capture step.
Operator Decisions for Q3 and Q4 2026
The protocols matter as deadlines, not as theory. Three operator decisions live inside the next two quarters:
1. Ship MCP first. If a platform does not expose an MCP server by end of Q3 2026, it is invisible to the majority of agent runtimes that route work through the MCP registry and through PulseMCP-style catalogs. The two-sprint cost is small. The competitive cost of being absent is large.
2. Plan ACP for any purchase event. Subscription marketplaces (MediaAlpha, QuinStreet, EverQuote, LendingTree), premium-financing platforms, and lead-pack subscriptions should map every paid event in the platform to an ACP endpoint by end of Q4 2026. The Stripe SPT path is the lowest-friction; for non-Stripe processors, the Visa Intelligent Commerce Connect translation path opens an alternate route. Shopify and commercetools shops already have first-party ACP integrations to model against.
3. Prepare AP2 mandate ingestion for regulated verticals. Insurance, lending, healthcare, and Medicare panels will demand mandate evidence as part of the lead payload through 2027. Building a mandate verifier alongside the existing TrustedForm/Jornaya verifier is the cheap version. Building it after a buyer rejects a quarter of agent-originated leads for missing evidence is the expensive version.
A fourth, harder-to-time decision: which foundation’s roadmap to track. The Agentic AI Foundation (MCP, AGENTS.md, goose by Block) is the upstream for tool-and-context work. The FIDO Alliance (AP2, Verifiable Intent) is the upstream for identity, authentication, and payment authorization. OpenAI’s role spans both – co-maintaining ACP with Stripe and co-founding the Agentic AI Foundation with Anthropic and Block. Operators tracking the agentic stack should set up at least one engineer to follow Specification Enhancement Proposals in both foundations and to surface changes that touch the consent or settlement layer.
The competition framing in trade-press headlines – “ACP vs AP2 vs MCP, who wins?” – misreads the picture. The three protocols are stacking, not racing. The operators who survive the agent-routing transition will be the ones who treat all three as required infrastructure and read each as defining a different obligation: discoverable tool surface, settled transaction, witnessed authority. The platforms that build for two layers and skip the third will discover, in the live deal flow of 2027, that the missing layer is exactly where buyer demand sits.
Key Takeaways
- ACP (OpenAI + Stripe, launched September 29, 2025) defines the merchant checkout contract; Shared Payment Tokens are its scoped, programmable payment primitive that lets agents pay without holding card credentials.
- AP2 (Google + Mastercard, donated to FIDO Alliance April 28, 2026) defines three signed Mandate artifacts as W3C Verifiable Credentials; v0.2 adds “Human Not Present” pre-authorized flows.
- MCP (Anthropic, introduced November 2024, donated to Linux Foundation’s Agentic AI Foundation December 2025) defines the tool, prompt, and resource interface for agents; 97 million monthly SDK downloads and 10,000+ active servers as of mid-2026.
- The three protocols stack at separate layers rather than compete: MCP at context-and-tools, ACP at transaction, AP2 at payment authorization and intent.
- For lead-gen platforms, MCP support is the cheapest and most leveraged starting point; ACP support matters when money moves at the platform boundary; AP2 support matters when buyers price by agent-verified consent in regulated verticals.
- None of the three replace TCPA prior express written consent for marketing contact – TrustedForm, Jornaya, or ActiveProspect records continue to define the consent evidence stack, with mandates and ACP receipts supplementing rather than substituting.
- Both AP2 and MCP went through neutral-foundation donations in 2026 specifically to clear the path for AWS, Azure, Google Cloud, and competing-vendor adoption; founder-controlled protocols would not have shipped at enterprise scale.
- Operator priority through Q4 2026: ship an MCP server first (two-sprint cost), plan ACP endpoints for paid events, build AP2 mandate ingestion alongside TrustedForm verification before regulated-vertical buyers demand it.
- Ambiguities remain at the protocol overlaps – dual-evidence between ACP receipts and AP2 mandates, card-network translation across Mastercard Agent Pay and Visa Intelligent Commerce Connect, MCP-as-payment-surface collision with ACP – and FIDO’s two new Technical Working Groups will define the answers through 2026-27.
Sources
- Stripe Newsroom: Stripe powers Instant Checkout in ChatGPT and releases Agentic Commerce Protocol codeveloped with OpenAI (September 29, 2025)
- OpenAI: Buy it in ChatGPT – Instant Checkout and the Agentic Commerce Protocol (September 29, 2025)
- Agentic Commerce Protocol GitHub repository – releases through 2026-01-30
- Stripe Documentation: Agentic Commerce Protocol
- Stripe Documentation: Shared Payment Tokens
- Google Cloud: Announcing Agent Payments Protocol (AP2) (September 16, 2025)
- Google: Donating Agent Payments Protocol to the FIDO Alliance (April 28, 2026)
- FIDO Alliance: Google Donates Agent Payments Protocol (April 28, 2026)
- AP2 Protocol Specification
- Anthropic: Introducing the Model Context Protocol (November 25, 2024)
- Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (December 9, 2025)
- Model Context Protocol specification
- OpenAI: Agentic AI Foundation under the Linux Foundation (December 9, 2025)
- Stripe: Developing an open standard for agentic commerce
- Stripe: Supporting additional payment methods for agentic commerce