2026 Comparative Analysis: Agentic Commerce Payment Protocols and the Race to Make AI Agents Pay — Applied Technology Index

Executive Summary

Agentic commerce is moving from checkout demos to a protocol contest over authority, liability, identity, and settlement. This analysis compares AP2, ACP, x402, Visa TAP, Mastercard Agent Pay, and Cloudflare Pay per Crawl to clarify which layers enterprises, merchants, publishers, and API operators should prepare for in 2026.

Key findings

  • Agentic payments are not one market. They split into at least four layers: checkout orchestration, delegated payment authority, agent identity, and metered resource access.
  • Google AP2 and Stripe/OpenAI/Meta ACP address merchant commerce flows, but from different starting points. AP2 emphasizes cross-platform authority and accountability. ACP emphasizes agent-ready checkout, product feeds, payment delegation, and order lifecycle integration.
  • x402 is the strongest fit for low-friction API, data, compute, and content access where a software agent can pay per request. It is less complete as a retail-commerce trust and dispute framework.
  • Visa TAP and Mastercard Agent Pay show card networks moving toward cryptographic agent identity, consumer recognition, tokenization, and issuer-grade risk controls rather than replacing existing payment rails.
  • Cloudflare Pay per Crawl reframes AI crawler access as a paid HTTP transaction. It is adjacent to agentic commerce, but its buyer is often a crawler or AI company rather than an end-user shopping agent.
  • Operators should avoid treating any one protocol as the universal answer. Near-term production stacks will likely combine product feeds, agent identity proofs, delegated payment tokens, conventional processors, and HTTP-native micropayments.

Methodology

Applied Technology Index reviewed primary and technical sources published by protocol sponsors, payment networks, infrastructure providers, and public repositories. The comparison focuses on six dimensions that determine deployment readiness: transaction subject, authorization model, settlement path, integration surface, merchant or publisher control, and operational risk.

This is not a benchmark of transaction success rates or fraud outcomes. Public production data is still limited, sponsor pages are partly forward-looking, and several protocols remain in development or restricted partner access. The analysis therefore treats official documentation as evidence of design intent and current integration surface, not proof of broad market adoption.

Search and X signal checks were used to identify query demand and frontier discussion clusters. Current discussion is concentrated around phrases such as “agentic payments,” “x402,” “AP2 vs ACP,” “AI agent commerce protocol,” “Visa Trusted Agent Protocol,” “agentic checkout,” and “pay per crawl.” Existing ATI topics cover MCP adoption and AI-native development workflows, so this topic avoids obvious duplication.

Comparative Analysis Table

Protocol or initiativePrimary problemBest-fit transactionAuthorization and trust modelSettlement or payment rail2026 readiness read
Google Agent Payments Protocol, AP2Prove agent authority and accountability across platformsAgent buys goods or services on behalf of a userMandates and verifiable user intent, designed as an extension to A2A and MCPPayment-agnostic, intended to work with many providersBroad ecosystem signal, still requires implementation alignment
Stripe, OpenAI, Meta Agentic Commerce Protocol, ACPLet agents browse, cart, checkout, and track ordersProduct discovery and checkout inside AI surfacesProduct feeds, agentic checkout, delegated payment, delegated authenticationStripe and payment-handler oriented, open specification referencedStrong near-term merchant path, especially for ChatGPT commerce
x402Turn HTTP 402 into machine-payable accessAPI, data, compute, content, MCP tool callsClient receives payment requirements, signs payment, retries requestNetwork and value agnostic, with strong stablecoin and onchain implementationsDeveloper-ready for metered resources, less complete for retail disputes
Visa Trusted Agent Protocol, TAPDistinguish trusted shopping agents from malicious botsBrowsing, product selection, and payment context at merchant sitesCryptographic signatures, merchant and purpose binding, time bounds, consumer recognition signalsWorks around Visa Intelligent Commerce and card credentialsImportant trust layer, officially described as in development and deployment
Mastercard Agent PayEnable trusted agentic transactions through card-network controlsAgent purchases via tokenized credentialsTokenization, consumer control, issuer and merchant risk postureMastercard network and partner ecosystemStrategically important, access to source pages may vary by region
Cloudflare Pay per CrawlLet content owners charge AI crawlers for accessCrawler or agent access to web contentHTTP 402 response, crawler payment intent headers, publisher rulesCloudflare-managed experiment, built on existing web infrastructureHighly relevant for publisher monetization, private beta in source material

Observed Profiles

Google AP2: authority and accountability for delegated commerce

AP2 answers a foundational question for agent commerce: how can a merchant, payment provider, and user know that an agent had permission to transact? Google describes AP2 as an open protocol for securely initiating and transacting agent-led payments across platforms. It is explicitly positioned as compatible with broader agentic protocols, including Agent2Agent and Model Context Protocol.

The design center is not just payment execution. It is accountability. Google frames the core issues as authorization, authenticity, and accountability. In practical terms, AP2 is trying to make the agent’s mandate portable, verifiable, and acceptable to merchants and payment providers. That matters because the classic checkout model assumes a human clicks buy on a trusted page. Agent commerce breaks that assumption.

AP2 is likely to matter most where transactions have meaningful value, dispute risk, regulated goods, returns, or multi-party responsibility. Examples include travel booking, enterprise procurement, subscription changes, insurance products, and marketplace purchases. Its weakness is the same as its ambition: broad payment-agnostic coordination requires many participants to implement compatible rules.

ACP: agent-ready checkout and product-feed integration

ACP, as documented by Stripe and OpenAI, is more directly merchant-operational. Stripe states that ACP was created by Stripe, OpenAI, and Meta to define how AI agents interact with businesses to complete purchases on behalf of buyers. Its building blocks include agentic checkout, cart and feed, delegated payment, delegated authentication, orders, and webhooks.

OpenAI’s commerce docs currently emphasize product feeds for ChatGPT shopping experiences. Merchants are asked to share structured catalog data including titles, descriptions, images, price, and availability. That makes ACP highly relevant for retailers that want to be discoverable and transactable inside AI interfaces.

ACP’s advantage is deployability. Merchants already understand feeds, carts, payment handlers, OAuth, and webhooks. ACP gives those familiar primitives an agent-facing shape. The risk is platform concentration. If ACP adoption is driven through major assistant surfaces, merchants may optimize for those distribution points first rather than for a neutral internet-wide commerce layer.

x402: HTTP-native payments for APIs, data, compute, and tools

x402 is the clearest protocol for agent-to-resource payments. The x402 Foundation describes x402 as an open standard for internet-native payments that aims to support all networks and forms of value, including stablecoins, tokens, and fiat. Its principle set emphasizes HTTP or transport-native behavior, network and currency agnosticism, and backward compatibility.

For AI systems, x402 is attractive because agents already consume resources through HTTP. A server can return payment requirements, the client can satisfy them, and the request can proceed without a conventional account, subscription, or invoice workflow. The GitHub reference implementation already includes packages for EVM, SVM, Aptos, Stellar, Hedera, Keeta, fetch, Express, Hono, Next.js, paywalls, extensions, and MCP.

The most plausible early market is not retail shopping. It is paid API calls, premium datasets, crawling, specialized model endpoints, agent tool calls, and small units of compute. x402’s limitation is governance and remediation. Payment completion is not the same thing as consumer authorization, refund handling, product substitution, age gating, or chargeback allocation.

Visa TAP: trusted-agent recognition before checkout

Visa’s Trusted Agent Protocol focuses on merchant visibility into agent identity and intent. Visa states that agents increasingly help customers browse merchant sites, discover products, compare prices, and make selections before checkout. Historically, merchants have treated automated traffic as bots and often blocked it. TAP tries to let merchants distinguish trusted commerce-focused agents from malicious automation.

The public Visa developer page and GitHub repository describe cryptographic signatures that are merchant-specific, purpose-specific, time-bound, and resistant to replay or relay. The protocol can also carry consented consumer signals, such as merchant account identifiers, device indicators, location parameters, and payment-related information.

TAP is best understood as an identity and trust layer, not a full replacement for checkout. It helps answer: is this agent legitimate, is it acting for a user, and is this request bound to a permitted purpose? That makes TAP complementary to AP2 or ACP rather than strictly competitive.

Mastercard Agent Pay: network tokenization and issuer-grade controls

Mastercard Agent Pay represents the card-network version of the same transition. Public search results and Mastercard-facing materials describe a program for secure, scalable, trusted agentic AI payments. Because direct source access can be region or bot restricted, this analysis treats Mastercard details cautiously and does not infer technical mechanics beyond the public framing.

The strategic direction is still clear. Card networks are unlikely to abandon their existing tokenization, issuer authorization, fraud scoring, and merchant acceptance infrastructure. They are more likely to adapt those systems so AI agents can initiate purchases under consumer-defined constraints. In enterprise terms, Mastercard Agent Pay should be monitored as a control and acceptance layer rather than as a developer-first agent API.

Cloudflare Pay per Crawl: monetizing AI access to content

Cloudflare Pay per Crawl is not a shopping protocol, but it is part of the agentic payments landscape because it applies HTTP 402 to AI access. Cloudflare describes a third path between blocking AI crawlers and allowing uncompensated access. In its private beta model, a crawler can present payment intent via request headers and receive HTTP 200, or receive HTTP 402 Payment Required.

This matters for ATI’s audience because crawler economics and agent economics are converging. AI systems need current web content, publishers want compensation or control, and HTTP-native payments offer a standardized negotiation surface. Pay per Crawl may become one of the first places where non-human buyers regularly encounter paid web resources.

Buyer and operator implications

For merchants, the first practical step is catalog and checkout readiness. Structured product feeds, accurate price and availability data, order webhooks, refund paths, and delegated authentication will matter before fully autonomous buying becomes common. ACP is the most immediate playbook for merchants seeking ChatGPT or assistant-surface commerce.

For API and data providers, x402 deserves early experimentation. If a resource can be priced per request, per dataset, per tool call, or per compute unit, HTTP-native payments may reduce account-creation friction and open usage to autonomous agents. Operators should still add quotas, abuse controls, receipts, and refund policies.

For payment and risk teams, AP2, TAP, and network-led programs should be watched as governance layers. The central question is not only whether an agent can pay. It is whether a later reviewer can prove what the user authorized, what the agent requested, what the merchant fulfilled, and who is liable for error or fraud.

For publishers, Cloudflare’s model points to a separate agentic monetization path. AI crawler control should be evaluated alongside robots.txt, llms.txt, licensing programs, CDN bot rules, and content syndication contracts.

Limitations

This report relies on public documentation and official announcements. It does not claim access to private beta terms, live transaction volumes, fraud rates, or merchant conversion data. Some sponsor pages are explicitly forward-looking. Mastercard source access was partially blocked in this run, so claims about Mastercard are intentionally conservative. Protocol naming is also fluid: ACP can refer to agentic commerce, agent client, or agent communication in different communities, so this paper uses ACP only for Agentic Commerce Protocol unless otherwise stated.

References

  1. Comparative readiness scorecard for agentic commerce product feeds, including OpenAI ACP, Google Merchant Center, and marketplace APIs.
  2. x402 for AI data providers: pricing models, abuse controls, and MCP tool monetization patterns.
  3. Visa TAP, AP2, and delegated authority: what agentic commerce changes about chargebacks and liability.
  4. Pay per Crawl and publisher economics: whether HTTP 402 can become the paid-access layer for AI search and LLM retrieval.

Optional derivative angle

A single organic derivative angle for Agitech-owned properties would be a technical checklist for making commerce, API, or content assets agent-readable before protocol adoption. This would only be justified if tied to implementation readiness, such as structured feeds, llms.txt, pricing.md, bot policies, and event logging. No commercial link is included in this draft.

Changelog

  • 2026-06-25: Initial publication.

Corrections

No corrections have been issued for this document.