- ACP, AP2, and x402 are not competing standards fighting for dominance. They operate at different layers of the agentic commerce stack and are designed to be used together.
- x402 handles the HTTP-level payment signal. AP2 structures the mandate and proof-of-intent layer between agent and merchant. ACP coordinates multi-agent workflows that may include payment steps.
- Stripe published the x402 specification and has shipped initial production support. Visa is backing AP2 with pilot programs underway across its issuer network. ACP originates from IBM Research and targets enterprise orchestration. None of these overlap in a way that requires choosing one.
- The practical question for builders is not which protocol wins. It is which vendors in your stack have already implemented which protocol, and whether your checkout flow can surface the right one at the right layer.
- Merchants should add x402 first. Platforms building multi-step agent workflows should evaluate ACP. Anyone processing card-based agent purchases should watch AP2 closely as Visa’s network rollout progresses.
ACP, AP2, and x402 are complementary protocol layers, not competing standards. x402 is an HTTP-level payment request signal for instant machine-to-machine transactions. AP2 is a structured mandate and proof-of-intent protocol governing how AI agents receive and verify spending authority, backed by Visa. ACP is an agent coordination protocol from IBM Research that manages multi-agent workflows, including payment steps. A production-grade agentic commerce stack will likely implement all three at different layers simultaneously.
Why the “Standards War” Framing Gets This Wrong
Every major protocol transition in payments history has produced breathless coverage of a standards war that never quite materialized. TCP/IP won over OSI. EMV consolidated chip standards. ISO 20022 is replacing older messaging formats. In each case, the protocols that looked like competitors turned out to be complementary once the stack clarified.
ACP vs AP2 vs x402 is the same pattern. The confusion comes from the fact that all three were announced in roughly the same eighteen-month window and all three use the word “agent” heavily. But they solve different problems at different layers of the same transaction.
Think of it this way. When an AI agent books a flight, something needs to detect that a payment is required and request it (x402), something needs to verify that the agent has legitimate authority to spend that money on the user’s behalf (AP2), and something needs to coordinate the sequence of sub-tasks that might involve booking, seat selection, and ancillary purchases across multiple downstream services (ACP). These are not the same job.
What Is x402, and Who Is Actually Building on It?
x402 resurrects an HTTP status code, 402 Payment Required, that has been reserved in the HTTP spec since 1999 but never formally implemented. The protocol defines a standard way for a server to respond to an AI agent with a machine-readable payment request, and for the agent to pay and retry in the same round trip.
Stripe published the x402 specification and shipped initial support through its developer infrastructure. Coinbase’s CDP (Coinbase Developer Platform) has also published support, and the specification is open for other implementers. The protocol is designed for stablecoin or crypto-native payments at the HTTP layer, meaning an agent can pay for API access, data, or a service without a human entering credentials.
The core mechanic is simple: a server returns a 402 response with a payment payload header, the agent pays, attaches a payment proof header, and resends the request. The server verifies and responds with the actual resource. Latency is measured in seconds for on-chain settlement paths, milliseconds for off-chain paths with stablecoin pre-authorization.
For merchants and API providers, x402 solves a real problem: how do you charge an AI agent that has no browser, no cookie session, and no card on file? The existing card-based checkout flow assumes a human is present. x402 assumes no human is present and builds the payment negotiation directly into the HTTP exchange.
Builders evaluating their payment infrastructure options for SaaS should note that x402 has the most production-ready implementations available today. Stripe’s open specification means any payment provider can build compatible endpoints without a licensing relationship.
What Is AP2, and What Does Visa’s Backing Actually Mean?
AP2, the Agentic Payments Protocol version 2, focuses on a different problem: how does a merchant know that an AI agent has legitimate, verifiable authority to spend on behalf of a specific user? x402 handles the mechanics of payment. AP2 handles the authorization chain above that.
The central concept in AP2 is the mandate: a cryptographically signed, scoped permission that a user grants to an agent, specifying what categories of spending the agent can authorize, up to what amount, and under what conditions. The merchant receives the mandate alongside the payment request and can verify it independently before completing the transaction.
Visa announced its backing of the AP2 framework as part of its Intelligent Commerce initiative. Visa’s involvement matters for a specific reason. Visa operates one of the two dominant card networks in the world. When Visa backs a protocol for agent payments, it signals that the protocol is designed to integrate with existing card rails, not replace them. AP2 is not crypto-native. It is designed for the existing card and bank transfer infrastructure that processes the majority of commercial transactions.
This makes AP2 more immediately relevant for any merchant that primarily processes card payments from consumers and businesses. An agent using AP2 can present a mandate-backed card payment that the merchant’s existing payment processor can handle, with the added verification layer that the agent was legitimately authorized. For merchants worried about unauthorized agent purchases driving chargebacks, the mandate structure is the specific feature that addresses it.
The proof-of-intent signal in AP2 also carries dispute resolution weight. If an agent completes a purchase that a user later disputes, a properly issued AP2 mandate creates an auditable authorization chain that neither x402 alone nor a bare API call provides.
What Is ACP, and When Does It Actually Apply?
ACP, the Agent Communication Protocol, comes from IBM Research and addresses multi-agent orchestration. It is a protocol for how AI agents talk to each other, share context, delegate tasks, and report results within a workflow. Payment is one of many actions an agent might take inside an ACP workflow, not the primary concern of the protocol itself.
ACP is relevant to builders constructing complex, multi-step agentic systems. Consider a procurement workflow where one agent identifies vendor options, a second agent negotiates terms, a third agent triggers payment, and a fourth agent reconciles the transaction against a budget ledger. ACP defines how those agents pass state, instructions, and results to each other in a standardized way that different vendors can implement.
The enterprise tilt of ACP is notable. IBM’s backing means the protocol is being designed with compliance, audit logging, and enterprise security models in mind from the start. That differs from x402, which was designed by payments-focused infrastructure companies for a developer-first audience.
For most early-stage companies, ACP is not the first thing to implement. It becomes relevant when a company is building systems where multiple specialized agents collaborate on a single workflow, and where the payment step is embedded inside a larger automated process rather than being the primary interface the agent exposes. Teams running AI agent payment infrastructure at scale will likely need ACP compatibility as workflow complexity grows.
How Do ACP, AP2, and x402 Fit Together in a Real Transaction?
The clearest way to see these as complementary is to trace a single agentic purchase through all three layers.
Say a company deploys a procurement agent to reorder SaaS licenses when utilization crosses a threshold. Here is how the three protocols map to that transaction:
- The user sets up the agent and grants it a spending mandate scoped to software purchases under $5,000 per month. This mandate is issued and signed according to AP2 conventions, tied to the user’s verified identity and stored with the agent’s credential set.
- The agent identifies a vendor and initiates a purchase. The vendor’s server returns an HTTP 402 response per the x402 spec, with a machine-readable payment payload specifying acceptable payment methods and amounts.
- The agent attaches its AP2 mandate alongside the x402 payment proof and resends the request. The vendor’s server verifies both: the x402 payment proof confirms funds moved, the AP2 mandate confirms the agent had authority to spend them.
- If this agent is operating inside a larger ACP-coordinated workflow (say, alongside a budget-tracking agent and an approval-routing agent), ACP handles the inter-agent state sharing before and after this transaction completes.
None of these steps conflicts with the others. They address payment mechanics, authorization verification, and workflow coordination respectively.
Which Protocol Should a Merchant Support First for Agent Checkout?
Start with x402. It has the most production-ready implementations today, with Stripe’s open specification available and Coinbase CDP already supporting it. Adding a 402 response handler to an existing API endpoint is a relatively contained engineering task. It opens the product to AI agents that are already using x402-compatible payment flows without requiring changes to the underlying merchant account or payment processor.
Add AP2 mandate verification second, particularly if the product handles high-value or recurring purchases where dispute risk matters. The mandate verification layer is what lets merchants confidently process agent-initiated purchases and have defensible records if a user disputes an agent-authorized charge. For merchants building agentic checkout flows, AP2 becomes more important as the average transaction value rises.
Prioritize ACP only if building an orchestration platform or if the product itself manages multi-agent workflows. A SaaS tool that sells to enterprises running complex agentic processes will eventually need ACP compatibility, but most merchants can treat it as a future consideration rather than an immediate implementation priority.
The FintechSpecs Protocol Layer Map: Where Each Standard Lives
To make the complementary relationship concrete, here is how the three protocols map to distinct layers of the agentic commerce stack. This framework, which FintechSpecs calls the Protocol Layer Map, identifies where each standard operates and which team owns the implementation.
| Protocol | Layer | Primary Function | Who Implements | Backed By | Status |
|---|---|---|---|---|---|
| x402 | HTTP transport | Machine-readable payment request and proof at the API response level | Backend/API teams at merchant or API provider | Stripe, Coinbase CDP (open spec) | Live implementations available from Stripe and Coinbase CDP |
| AP2 | Authorization and identity | Mandate issuance, proof-of-intent, scoped spending authority | Identity/auth teams; payment processors integrating with card rails | Visa | Pilot programs underway via Visa’s Intelligent Commerce initiative |
| ACP | Agent orchestration | Multi-agent communication, state sharing, task delegation including payment steps | Platform/orchestration teams building multi-agent systems | IBM Research | Specification published; enterprise pilots in progress |
The layer distinction is the key insight. A merchant implementing x402 is writing code in their API layer. A company implementing AP2 is working with their payment processor and identity systems. A company implementing ACP is working on their agent orchestration architecture. These are different teams, different timelines, and different technical scopes.
Who Backs Each Protocol and Why That Changes the Risk Profile
Stripe and Coinbase backing x402 is a developer-distribution story. Both companies have enormous developer audiences and existing payment infrastructure. If Stripe makes x402 a first-class citizen in its APIs, adoption among Stripe-connected merchants happens through integration updates, not through a decision any single merchant needs to make. That is a fast adoption path.
Visa backing AP2 is a network-effects story. Visa’s reach is not developer mindshare, it is issuer relationships. If Visa mandates or incentivizes AP2 mandate support among issuers, banks, and processors on its network, AP2 becomes infrastructure rather than optional. The risk for merchants is not that AP2 fails to win adoption. It is that the timeline is slower because financial institution change cycles are measured in years, not quarters.
IBM Research backing ACP signals enterprise legitimacy but also enterprise pace. IBM’s primary customers are large financial institutions, insurers, and manufacturers running complex workflows. ACP is being designed for that environment, which means thorough audit trails, role-based access, and integration with existing enterprise identity systems. For startups, the question is whether their enterprise customers will eventually require ACP-compatible agent systems in vendor contracts, which is a real possibility in regulated industries.
The risk of waiting for a winner is that each protocol has different maturity curves. x402 is shippable now. AP2 is moving through Visa’s network. ACP is in the specification and early-pilot phase. A company that waits for consensus may find that its competitors have already shipped x402 support and built a meaningful head start in agent-initiated purchase volume.
What About TAP and UCP? Do They Change This Picture?
TAP (Transaction Authorization Protocol) and UCP (Universal Commerce Protocol) are additional proposals circulating in the agentic payments space. Neither has the institutional backing or implementation momentum of x402, AP2, or ACP at the time of writing. TAP has been discussed in open standards forums but does not have a major payment network or infrastructure provider publicly committed to it. UCP remains largely conceptual in published documentation.
Including them in a decision framework at this stage would be premature. The three-protocol picture of x402, AP2, and ACP represents where the actual engineering and institutional weight is being placed. If TAP or UCP gain a major backer, that changes the calculus, but that has not happened yet.
Frequently Asked Questions
Do ACP, AP2, and x402 compete with each other?
No. They operate at different layers of the agentic commerce stack. x402 is an HTTP-level payment signal. AP2 is an authorization and mandate verification layer. ACP is an agent orchestration protocol that can include payment steps. A production agentic system can implement all three simultaneously without conflict. The confusion arises because all three were announced in a similar timeframe and all use “agent” prominently in their descriptions.
Which protocol does Stripe support?
Stripe is the primary backer of the x402 specification, which it published as an open standard, and has shipped initial production support through its developer infrastructure. Check Stripe’s x402 developer documentation for the current implementation status. Stripe does not publicly claim to implement AP2 or ACP, though its infrastructure is compatible with card-rail-based implementations that AP2 is designed to work with.
What is a mandate in AP2 and why does it matter for merchants?
A mandate in AP2 is a cryptographically signed permission that a user grants to an AI agent, scoping what the agent can purchase, up to what dollar amount, and under what conditions. Merchants receive the mandate alongside the payment request and can verify it before completing the transaction. For merchants, the mandate creates an auditable authorization chain that is defensible in a dispute, unlike a bare API call or x402 payment alone that carries no proof of user intent.
When should a startup prioritize ACP over x402 or AP2?
Prioritize ACP when the product being built is an orchestration platform or when the core use case involves multiple specialized agents collaborating on a single workflow, where payment is one step among many. Most merchants and API providers should implement x402 first and evaluate AP2 mandate support second. ACP becomes relevant when the engineering team is building the coordination layer between agents, not when the primary goal is accepting a payment from an agent at a checkout endpoint.
Is x402 only for crypto or stablecoin payments?
x402 as Stripe originally specified it is designed for stablecoin and crypto-native payments at the HTTP layer, because on-chain settlement allows instant, programmable payment verification without a card network intermediary. Some implementations are exploring off-chain paths with pre-authorized stablecoin balances. Traditional card payments operate through a separate authorization flow that does not map cleanly to the synchronous 402 request-pay-retry cycle. For card-based agent payments, AP2 is the more relevant protocol.
Can a merchant support x402 without changing their payment processor?
In most cases, yes for the initial implementation. Adding a 402 response handler to an API endpoint is primarily a backend engineering task. The payment settlement layer depends on which stablecoin or crypto rails the x402 implementation uses, and merchants need a way to receive and convert those funds. Stripe’s x402 support integrates with Stripe’s existing settlement infrastructure. Merchants using other processors would need to evaluate whether their processor has shipped or plans to ship x402 support, or whether they can accept the stablecoin payment separately.
How does AP2 handle fraud and unauthorized agent purchases?
AP2’s mandate structure is specifically designed to address unauthorized purchases. Because each mandate is cryptographically scoped to specific spending categories, amounts, and time windows, a merchant can verify at the point of sale that the agent’s request falls within the user’s stated intent. An agent that exceeds its mandate scope should fail the verification check before the payment completes. This creates a fraud-prevention layer that does not exist in unstructured agent-initiated API calls and reduces the chargeback risk that merchants face from agent-attributed purchases the user did not sanction.
What happens if an agent exceeds its AP2 mandate during a transaction?
The transaction should fail at the mandate verification step before payment is processed. AP2 mandates are scoped by category, amount ceiling, and time window. If an agent attempts a purchase that exceeds any of those parameters , say a $6,000 software purchase against a $5,000 monthly mandate , the merchant’s verification layer rejects the mandate as out of scope and the payment does not proceed. The agent receives a rejection signal and, depending on implementation, may escalate to a human approver or abort the workflow. This is a design-level control, not a post-hoc fraud flag, which is what distinguishes AP2’s mandate model from traditional card authorization alone. Builders should confirm how their chosen AP2 implementation surfaces these rejection events to the orchestrating agent, since silent failures in multi-step workflows can be harder to debug than explicit error responses.
Will large enterprises require ACP compatibility from their vendors?
This is likely in regulated industries over a two-to-four-year horizon, though not a widespread requirement today. IBM’s enterprise customer base includes large financial institutions and manufacturers that tend to impose vendor interoperability standards through procurement contracts. As ACP gains adoption in those environments, enterprise SaaS vendors and payment providers serving that segment may face ACP compatibility requirements in RFPs. Startups selling to mid-market buyers are unlikely to see this pressure in the near term.
How to Decide What to Build First
If the business primarily sells API access or digital products and wants to monetize AI agent traffic now, x402 is the right first implementation. The specification is open, Stripe has production support, and the engineering scope is contained. Merchants already thinking through which fintech APIs to build on should add x402 compatibility to that evaluation checklist.
If the business processes card payments and is seeing early signs of agent-initiated purchases, the AP2 mandate layer deserves attention now even if full implementation is six to twelve months out. Getting familiar with Visa’s pilot program timeline and making sure the payment processor is tracking AP2 gives a meaningful head start on dispute-proofing agent transactions before they become a significant portion of volume.
The protocols are converging toward a world where an AI agent can walk up to any merchant endpoint, prove it has authority to spend, pay instantly, and do all of this with a complete audit trail. x402 handles the payment mechanics. AP2 handles the authority proof. ACP handles the workflow that got the agent there. A builder who understands those three distinct jobs stops worrying about which protocol wins and starts asking which vendors have implemented which layer. That is a concrete, answerable question. The linked vendor comparisons on FintechSpecs answer it by category.
The parallel worth holding onto: nobody asked whether HTTPS “competed” with OAuth. HTTPS secured the transport layer. OAuth secured the authorization layer. They composed. ACP, AP2, and x402 are composing the same way, and the stack is still early enough that shipping now gives an advantage that waiting for certainty will not recover.
