AP2, x402, and ACP Explained: The Agentic Payment Protocols Compared

AP2, x402, and ACP are the three agentic payment protocols competing to authorize and execute payments made by AI agents.

AP2 (Google) handles authorization via signed mandates, x402 (Coinbase) handles on-chain machine-to-machine settlement, and ACP (OpenAI + Stripe) handles conversational checkout. Each protocol produces different evidence, and none of them stores the unified record your books need.

Protocols at this layer provide agents with verifiable delegated authority and merchants with a way to trust non-human buyers at checkout. Card networks also require evidence of a dispute when an autonomous purchase goes wrong.

Each protocol operates at a different layer of the stack and produces distinct evidence when AI agents move money. The resulting settlement records still land on your books.

AP2 is the rail-agnostic mandate standard

AP2 is Google's payment-agnostic mandate protocol. It defines signed mandates that form an auditable chain and is a separate payment rail that moves the money.

Google announced AP2 in September 2025 with more than 60 partners, including card networks, PSPs, and merchants. Google positioned AP2 as the authorization layer for agent-initiated card and bank-transfer payments, with an x402 extension that adds stablecoin support.

Fintech Brainfood clarifies that AP2 creates "mandates" that let humans delegate payment authority to agents. This includes cart mandates for what's being bought, intent mandates for what the human wanted, and payment mandates for the credential used.

AP2 uses a chain of mandates that is a cryptographically signed credential that captures one stage of user authority:

An Intent Mandate captures a user's raw intent or pre-authorization to pay, potentially with constraints such as "buy when the price drops below X," which an agent can use to act within the user's stated bounds. The Intent Mandate's signature limits the agent's spending to the user's stated bounds.

A real-time approval over a concrete cart, captured before checkout runs. The approval covers the specific items and amounts and excludes general permission.

The artifact the card network and issuer actually see. It records finalized payment details and, in AP2's mandate chain, can signal to payment networks that an agent was involved while preserving verifiable evidence of user authorization, which card-network dispute processes require when an autonomous purchase is contested.

W3C verifiable credentials, governance, and settlement

At each hop, the signature chain records the authorizing party and applicable constraints, including whether a human was present. The mandates are carried as SD-JWT verifiable credentials built on the W3C Verifiable Credentials model, so each party in the chain can verify the credential without trusting the issuing party.

Governance has moved faster than the spec. Google donated AP2 to the FIDO Alliance on April 28, 2026, to keep it platform-agnostic and community-led. The most recent published spec, however, is v0.2, with no stated stable release date. If you build against AP2 today, you are building against a moving draft under new governance.

AP2 proves authorization while the underlying rail moves the money. Settlement runs on whatever rail lies beneath; for example, card networks and bank transfers for regulated flows, or stablecoins via the A2A x402 extension. AP2's separation of authorization from settlement is deliberate, and it means AP2 alone cannot confirm whether a payment settled.

x402: HTTP 402 machine payments in stablecoins

x402 is Coinbase's HTTP 402-based protocol for machine-to-machine payments in stablecoins. The x402 project calls it "an open, neutral standard for internet-native payments" built to "empower agentic payments at scale."

Agents pay per request for APIs, compute, or data, with the price returned in the HTTP response and settlement happening on-chain.

The protocol has processed tens of millions of transactions, though most of that volume is early experimentation rather than steady commercial demand.

The request-and-settle flow

The documented flow is presented as a flexible payment flow rather than the whole protocol.

The facilitator is the operational dependency to scrutinize: it sits between every request and every settlement, and the spec does not define its failure-mode behavior.

On-chain settlement and what "paid" means

Settlement is on-chain in stablecoins, which changes what "paid" means for your books. Your books distinguish a transaction confirmed on-chain from settled funds in your internal accounting, a distinction we cover in depth in on-chain confirmation versus settlement.

Agent wallet and spend controls

The deployment pattern the docs assume pairs x402 with an agent wallet holding spend permissions: per-day caps and per-transaction caps, with signing keys held in secure enclaves and never exposed to the model. The agent's model decides to initiate payment; the agent wallet enforces the spend limits.

Governance under the Linux Foundation

On April 2, 2026, Coinbase handed x402 over to the Linux Foundation, which spun up the x402 Foundation to steward the specification, the reference implementations, and the change process.

x402 is no longer controlled by a single company, so teams building on it are not locked into Coinbase's roadmap. It is now community-governed, so teams adopting it are betting on a neutral standard rather than a Coinbase product.

ACP is an agentic checkout with shared payment tokens

ACP, the Agentic Commerce Protocol, is OpenAI and Stripe's protocol for agentic checkout. Agents discover products through merchant feeds and build carts against merchant endpoints. Shared payment tokens prevent credit card credentials from being exposed to the agent.

ACP doesn't replace the merchant's payment processor. It only defines the API conversation between the agent and the merchant's checkout because the merchant's existing PSP still charges the card.

Instant Checkout and the delegated payment token

The first production deployment was Instant Checkout in ChatGPT, launched on September 29, 2025, for U.S. users and initially supporting Etsy sellers, with a stated weekly audience of more than 700 million ChatGPT users.

The payment mechanics live in the delegated payment spec. OpenAI prepares a one-time delegated payment request with a maximum chargeable amount and an expiry date, passes it to the merchant's PSP, and the PSP responds with a payment token that the merchant charges through its normal flow.

The token's constraints are the control surface. The agent cannot charge more than the cap or after the expiry, regardless of what the model does.

Where liability lands

Merchant-of-record responsibility, settlement, refunds, chargebacks, and compliance remain with the merchant and their PSP.

If an agent-driven purchase goes wrong, the dispute lands in your existing PSP relationship. ChatGPT is not a party to the merchant-PSP dispute process.

AP2 vs x402 vs ACP: layer, rails, maturity, and backing compared

AP2 sits at authorization, x402 at execution, ACP at checkout, and the three protocols can stack. Teams routinely combine two or three.

Ledger requirements for AP2, x402, and ACP payments

None of the three agentic payment protocols stores a unified transaction record. The merchant's ledger must be the one place where AP2 mandates, x402 receipts, and ACP tokens converge into postings that carry agent ID, task, mandate ID, and PSP reference, and are reconciled across rails.

AP2 signed mandate: authorization evidence

An AP2 mandate proves who authorized what, at which stage, and under which constraints (Intent, Cart, and Payment). It is authorization evidence, not settlement evidence. A complete mandate chain tells you the user consented. It does not tell you money moved.

x402 on-chain receipt: settlement evidence

An x402 receipt proves that funds were moved on-chain, with a timestamp and is immutable. The receipt tells you a stablecoin transfer settled to a wallet address. It does not tell you which order, which agent task, or which customer that transfer belongs to. The metadata that ties settlement to business context lives outside the receipt.

ACP delegated payment token: scoped charging permission

An ACP token proves that the merchant's PSP was authorized to charge up to a cap before expiry for a specific cart. The token is a scoped charging permission, consumed by the merchant's existing PSP flow. The token itself does not record the resulting card settlement, the refund, or the chargeback.

The ledger as the single source of financial truth

The ledger is the single source of financial truth because it is the only system that holds all three pieces of evidence in one place.

The mandate, the receipt, and the token live in three different systems, and the merchant is the only party that sees all three.

Convergence happens in the ledger, at the posting level. Every ledger posting carries four fields regardless of which rail it came from:

A mandate issued without a matching PSP reference is an authorization with no settlement, a discrepancy the ledger surfaces instead of hides. A receipt that settles without a matching mandate or task ID is settlement with no accountable authorization behind it.

Why a core ledger sits beneath AP2, x402, and ACP

A core ledger sitting beneath whichever protocols you adopt enforces double-entry accounting programmatically and provides immutability for regulatory-grade traceability. Its rail-agnostic postings carry agent ID, task, mandate ID, and PSP reference, and reconcile protocol evidence within a single system of record.

AP2 mandates and x402 receipts use the same posting model as ACP tokens. Customers must enforce a stable idempotency key at the integration boundary before recording one resulting transaction. Any retry and deduplication behavior remains the responsibility of the surrounding workflow or integration.

Formance Ledger can record fiat, stablecoin, and other customer-defined assets as programmable money within the same posting model: an x402 receipt and a card PSP reference land in a single queryable history rather than two separate drifting systems.

A $250,000 settlement via x402

In this hypothetical enterprise B2B settlement, an agent pays a $250,000 compute invoice through an x402-style flow.

The account model uses @external:x402:base as the external x402/Base settlement boundary, @merchants:acme:available for the merchant's available funds, and @platform:revenue:fees for the platform's fee revenue.

Here, the $250,000 enters through the external boundary, with 98% going to the merchant and the remainder to platform fee revenue.

The following Numscript posting binds four fields to every settlement: agent ID, task ID, mandate ID, and PSP reference. Extractors and readers can capture the key claim without parsing the code below:

The posting splits the settlement between the merchant's available balance and a platform fee account in one atomic transaction, and the metadata binds it to the agent, the task, the authorizing mandate, and the rail-side reference.

To make retries safe, the surrounding application must enforce a stable idempotency key at the integration boundary before recording one resulting transaction in the ledger.

With idempotency enforced at the boundary, the integration rejects the agent's twentieth retry before posting and prevents a second $250,000 transaction.

Which agentic payment protocol should you build on first?

Pick the protocol that matches the layer your product operates at: x402 for machine-to-machine API monetization, AP2 for cryptographic authorization in regulated flows, or ACP for conversational checkout surfaces. Many teams will support more than one protocol.

A protocol-agnostic ledger can reconcile postings across rails by the same four fields regardless of which spec produced the evidence.

With the Formance Ledger underneath, you can provide enforced double-entry accounting, atomic postings, metadata, and tamper-evident transaction history to your agentic payment protocol. Request a Formance demo to learn more.