AP2 vs ACP vs x402: A Builder's Comparison of the Competing Agentic Payment Protocols
Most explanations of agentic commerce describe what it is conceptually: AI agents that can initiate, authorise and complete transactions on a user's behalf. Fewer explain the part engineering teams actually need to decide on — which protocol to build against, given that there isn't one. As of this year, at least three distinct approaches to agent-initiated payments are being actively developed and adopted in parallel: Google's Agent Payments Protocol (AP2), the Agentic Commerce Protocol (ACP) built by OpenAI with Stripe, and x402, a stablecoin-settlement approach built around the HTTP 402 "Payment Required" status code. None has become the default. Each solves a genuinely different part of the problem.
For a platform or engineering team deciding whether and how to support agent-initiated payments, understanding what actually differs between these three — not just that they exist — is the difference between a defensible technical decision and a guess.
Why there are three protocols instead of one
It's worth being clear about why this fragmentation exists, because it isn't simply that the market hasn't converged yet on an obvious winner — it's that the three approaches are solving meaningfully different sub-problems, built by organisations with different starting points. A protocol designed by a search and AI platform, one designed by an AI lab in partnership with a payments processor, and one designed around stablecoin settlement and web infrastructure are each shaped by the problem their creators encountered first, and those aren't the same problem.
That matters for evaluation: the honest comparison isn't "which protocol is best," it's "which part of the agentic-payments problem does each one actually solve, and which of those parts matters most for what we're building."
AP2: identity, authorisation and mandate-based trust
Google's Agent Payments Protocol focuses heavily on the authorisation and trust layer — establishing verifiable "mandates" that define what an agent is actually authorised to do on a user's behalf, and providing a way for a merchant or payment processor to verify that mandate before a transaction proceeds. The emphasis is less on moving money and more on answering the question that sits underneath every agentic-payment use case: how does a merchant know this agent is genuinely authorised to spend on behalf of the person it claims to represent, within what limits?
This is close to the exact trust problem the six-bank "Principles for Trusted Agentic Commerce" framework and the UK's recent live agentic-payment activity have been grappling with at an industry level — AP2 is one concrete technical attempt at solving the identity and authorisation piece of that same problem, rather than the settlement or execution piece.
ACP: commerce-flow integration with existing payment rails
The Agentic Commerce Protocol, developed by OpenAI with Stripe, takes a different starting point: rather than focusing primarily on authorisation semantics, it's built around integrating agent-initiated purchases directly into existing commerce and checkout flows, using payment infrastructure that already exists rather than proposing a parallel settlement mechanism. The practical implication is that ACP is oriented toward merchants and platforms who want an agent to be able to complete a purchase through something close to a standard checkout experience, with the agent acting as the initiator rather than requiring an entirely new payment rail.
This makes ACP the most immediately relevant of the three for a conventional e-commerce or subscription-commerce context: a platform already running standard card-based checkout has a more direct integration path with an approach built to slot into that flow than with an approach built around a fundamentally different settlement model.
x402: stablecoin settlement built on web infrastructure
x402 takes the most structurally different approach of the three. Built around the long-dormant HTTP 402 "Payment Required" status code, it proposes a settlement mechanism where a server can request payment directly as part of a standard web request-response cycle, typically settled in stablecoin. Where AP2 focuses on authorisation and ACP focuses on checkout-flow integration, x402 focuses on making payment a native part of how machines talk to each other over the web — relevant less to conventional storefront checkout and more to machine-to-machine and API-metered use cases, where an agent (or another piece of software) needs to pay for access to a resource or service programmatically, without a human-facing checkout step at all.
This is also where x402 connects to the broader stablecoin-infrastructure activity happening elsewhere this year: a settlement approach built around stablecoins benefits directly from the same card-network and issuer investment making stablecoin balances more broadly spendable, even though x402 itself is a web-protocol proposal rather than a card product.
The practical comparison: what each protocol actually optimises for
Reduced to the question an engineering team actually needs answered — "what should we build against, given what we're trying to do" — the honest comparison is: AP2 for scenarios where verifying an agent's authorisation and spending limits is the hard problem (regulated, higher-value, or trust-sensitive transactions); ACP for scenarios where the goal is an agent completing a purchase through something resembling an existing commerce flow, particularly where Stripe or similar processor infrastructure is already in place; and x402 for machine-to-machine or API-metered payment scenarios where there's no human-facing checkout at all, and stablecoin settlement fits the use case.
None of these are mutually exclusive at a system level. A platform could reasonably use AP2-style authorisation logic to verify an agent's mandate, then settle the actual transaction through infrastructure closer to ACP or x402 depending on the specific flow — the three aren't necessarily competing end-to-end solutions so much as addressing different layers of the same broader stack.
What this looks like against the UK regulatory backdrop
None of these three protocols exist in a regulatory vacuum, and that matters more for a UK platform than the technical comparison alone suggests. The FCA has already signalled active interest in agentic AI in financial services — including exploring agentic AI itself as a market-surveillance tool — and the Bank of England has separately flagged frontier AI models as a potential financial-stability risk worth supervisory attention. Meanwhile, live agentic-payment activity is already happening under direct UK regulatory oversight: a UK payments company processing an AI-agent-initiated account-to-account payment with the FCA directly engaged, rather than confined to an unregulated sandbox.
That combination — active regulatory attention plus live production precedent — means a UK platform evaluating any of these three protocols should treat the authorisation and audit-trail question as a first-class requirement, not an afterthought bolted on later. AP2's explicit focus on verifiable mandates is directly relevant here: whichever protocol (or combination) a platform ultimately builds against, being able to demonstrate exactly what an agent was authorised to do, and prove it after the fact, is likely to matter as much to a UK regulator's eventual expectations as it does to the underlying payment mechanics.
A practical evaluation checklist for engineering teams
Given the fragmentation, a structured evaluation is more useful than a protocol-popularity comparison. Four questions are worth working through before committing engineering time: first, what specific sub-problem does our use case actually have — authorisation, checkout-flow integration, or machine-to-machine settlement; second, which existing infrastructure do we already run that a given protocol would need to integrate with (a Stripe-based checkout stack points differently than an API-metered service architecture); third, what does the audit and authorisation trail need to look like to satisfy our own risk and compliance requirements, given the UK regulatory attention on this category specifically; and fourth, is this a single-protocol decision or does our architecture actually need elements of more than one, given that authorisation, checkout integration and settlement are separable concerns.
Working through those four questions in order tends to narrow the field far faster than starting from "which protocol has the most industry momentum," because momentum is a weak proxy for fit when the three options are solving genuinely different problems rather than competing head-to-head on the same one.
What this means for a build-vs-wait decision
Given that none of the three has converged into a clear default, the most defensible engineering position right now is not "pick one and commit fully," but "identify which specific sub-problem your use case actually has, and evaluate the protocol built for that sub-problem specifically." A platform whose primary concern is verifying that an AI agent is genuinely authorised to spend on a customer's behalf has a different evaluation to run than a platform whose primary concern is settling machine-to-machine API payments programmatically. Treating "which agentic payment protocol should we adopt" as a single, unified question is where teams tend to lose time comparing approaches that were never actually solving the same problem.
Where Innovify fits
Evaluating which of several genuinely different technical approaches actually fits a specific platform's agentic-commerce use case — rather than picking the one that's loudest in the market — is exactly the kind of assessment Innovify's Agentic Commerce & Payments practice works through with clients. Where the underlying question is closer to "is our organisation ready to evaluate this category of infrastructure at all," our AI Labs team runs that readiness conversation directly.
FAQ
What's the main difference between AP2, ACP and x402?
AP2 (Google) focuses on authorisation and verifying an AI agent's mandate to spend on a user's behalf. ACP (OpenAI with Stripe) focuses on integrating agent-initiated purchases into existing commerce and checkout flows. x402 focuses on stablecoin settlement built directly into web request-response infrastructure, aimed at machine-to-machine and API-metered payments.
Do I need to choose only one of these protocols?
Not necessarily. Because they address different layers of the agentic-payments stack — authorisation, checkout-flow integration, and machine-to-machine settlement — a system could reasonably combine elements of more than one, depending on which parts of the payment flow need which capability.
Which protocol is most relevant for a standard e-commerce checkout use case?
ACP is the most directly oriented toward integrating with existing checkout and commerce flows, given its foundation in Stripe's existing payment infrastructure, making it the most immediately relevant for platforms already running conventional card-based checkout.
Which protocol is most relevant for machine-to-machine or API-based payments?
x402, given its design around settling payment directly within web request-response cycles using stablecoin, without requiring a human-facing checkout step.
Is one of these three protocols likely to become the single industry standard?
As of this analysis, none has converged into a clear default, and each is built around a different sub-problem rather than competing to solve the identical problem. It's more useful to evaluate each against your specific use case than to wait for a single winner to emerge.
Where should an engineering team start if they're evaluating agentic payments for the first time?
Start by identifying which specific sub-problem your use case actually has — authorisation and trust verification, checkout-flow integration, or machine-to-machine settlement — rather than starting from "which protocol is most talked about." That framing points toward the right protocol far more reliably than comparing all three as if they were interchangeable options.
Conclusion
Agentic commerce doesn't have one payment protocol yet — it has three, built by different organisations to solve different parts of the same broader problem. AP2, ACP and x402 aren't competing answers to an identical question so much as three different technical layers of the same emerging stack: authorisation, commerce-flow integration, and machine-to-machine settlement, respectively. The engineering teams that get ahead of this aren't the ones betting on a single winner — they're the ones who've correctly identified which specific sub-problem their platform actually has.
