What is agentic commerce, and how does an AI agent actually pay?

The problem both specs are trying to solve

Existing payment rails assume a human clicked buy on a site they trust. AP2's documentation states the consequence directly: when an autonomous agent initiates a payment, that assumption breaks, and three questions have no answer in current systems. Authorization — how does anyone verify the user gave this agent authority for this specific purchase? Authenticity — how can a merchant be sure the request reflects the user's real intent rather than an agent error or hallucination? Accountability — when a transaction goes wrong, is it the user, the agent developer, the merchant, the issuer, the processor or the orchestration layer who is liable?

Those are not abstract. They determine who eats a fraudulent or mistaken charge, which is why payments companies rather than model labs are doing most of this work.

Note the deliberate scope difference. ACP is mostly an answer to "how does an agent talk to a checkout," and AP2 is mostly an answer to "how does a merchant know the user meant it." They are not straightforwardly interchangeable, and AP2's own documentation describes an integration path alongside other protocols rather than a winner-take-all contest.

ACP: standardising the merchant checkout surface

The Agentic Commerce Protocol repository describes itself as an interaction model and open standard connecting buyers, their AI agents, and businesses, maintained by OpenAI and Stripe, currently in beta and licensed Apache-2.0. Stripe's documentation describes it as created by Stripe, OpenAI and Meta. The repo carried 1,544 stars when checked and was created on 29 September 2025.

Stripe's documentation lists the building blocks: agentic checkout for creating, updating and completing checkout sessions with cart management and fulfilment options; cart and feed for browsing catalogues; delegate payment for passing payment tokens between buyer, agent and business via payment handlers; delegate authentication using OAuth 2.0; and orders plus webhooks for confirmation, shipping, delivery and refunds.

The spec is date-versioned rather than semantically versioned, and the repository's own layout shows the release cadence: spec directories for 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30 and 2026-04-17, plus an unreleased directory for current development. The 2026-04-17 changelog states that it promotes accumulated changes since 2026-01-30 and deprecates the previous version — worth knowing before you pin an integration to a date. Each release ships OpenAPI, JSON Schema and OpenRPC artifacts.

Two design choices matter commercially. The ACP site states that businesses remain the merchant of record, keeping the customer relationship and control over what can be sold and how orders are fulfilled. And the site's FAQ is explicit that implementing the spec does not automatically list your products in any agent — each AI platform runs its own participation process, and businesses wanting to appear in ChatGPT have to apply.

AP2: standardising proof of what the user authorised

Google's Agent Payments Protocol takes the trust angle. Its core mechanism is verifiable digital credentials — tamper-evident, cryptographically signed objects the documentation calls mandates. A Checkout Mandate captures the specific items and purchase details negotiated between agent and merchant and is shared with the merchant; a linked Payment Mandate covers the payment side. The stated principle is verifiable intent, not inferred action: trust anchored to non-repudiable proof from the user rather than to the agent's assertion, which also produces a cryptographic audit trail for dispute resolution.

AP2 is positioned as an extension of Google's Agent2Agent protocol and interoperates with MCP-equipped agents, so it sits above the tool layer rather than replacing it. The repository is Apache-2.0, was created on 30 May 2025, and had 3,178 stars when checked. Its published releases are v0.1.0 on 16 September 2025 and v0.2.0 on 28 April 2026.

The governance direction is the notable recent development: AP2's documentation links Google's announcement of the v0.2 release and a donation to the FIDO Alliance, with standardisation continuing in FIDO working groups. Google's documentation also describes the initial version as supporting pull payment methods such as credit and debit cards, with e-wallets, push payments including real-time bank transfers, and digital currencies on the roadmap — that is a stated roadmap, not shipped capability.

Who should care, and what to actually do

If you sell online, the near-term question is not which spec wins but whether an agent can read your catalogue and complete a purchase without a human in your checkout UI. ACP's feed and checkout surfaces are the concrete thing to read, and Stripe documents both REST and MCP integration patterns against existing commerce backends. Also read the participation caveat above before treating implementation as distribution.

If you build agents, the interesting piece is the authorization model rather than the API shape. An agent that can spend money needs an answer to what happens when it is wrong, and AP2's mandate structure is currently the most developed public attempt at that answer. Google publishes runnable samples for human-present, human-not-present and x402 scenarios.

If you are neither, the useful takeaway is that the phrase means something specific. Agentic commerce is not a chatbot that recommends products; it is a transaction where a program holds delegated spending authority. That is why the specs spend most of their length on tokens, mandates and liability rather than on shopping.

What is still unresolved

Fragmentation is the obvious open question. Two well-funded specifications with different centres of gravity exist, and neither documentation claims the other is obsolete. AP2 describes integration with the Universal Commerce Protocol and positions itself as an extension layer, which points toward coexistence, but that is a stated direction rather than an observed outcome.

Maturity is the second. ACP's README carries a beta status badge and its date-versioned releases deprecate their predecessors, so an integration written today has a maintenance cost. The unreleased changelog directory was actively accumulating entries when checked, covering feed updates, error-code documentation and schema alignment.

Consumer-side questions are the third, and no specification answers them: what recourse you have when an agent buys the wrong thing, how spending limits are enforced end to end, and how disputes are handled in practice. AP2's cryptographic audit trail is designed to help dispute resolution, but real-world resolution depends on issuers, processors and merchants, not on the protocol alone.

Limits of this answer

RepoRadar has not implemented either specification. Everything above comes from current primary documentation, repository metadata and published release history, not from hands-on integration.

Repository star counts and the pushed dates quoted here are point-in-time observations from the GitHub API on the date of publication, not growth measurements. Adoption figures for either protocol are not published in a form RepoRadar can verify, so this article makes no adoption claim.

Pricing, fees and commercial terms for agentic transactions are set by processors and platforms and are outside both specifications; nothing here should be read as a cost estimate.

A useful next action

Read one spec surface rather than both overviews. If you are a merchant, open the ACP agentic checkout OpenAPI file for the dated release you would target and check whether your existing cart, fulfilment and refund flows can be expressed in it. If you are building an agent, read the AP2 specification's mandate section and decide what you would need to sign before you would be willing to let your own code spend your own money.