How AI Agents Pay: ACP, UCP, AP2, and x402 Explained

Card payments on the web were built around one assumption: a person is at the keyboard, looking at a merchant's checkout page, and clicking "buy." AI agents break that assumption. When a model fills a cart, picks a shipping option, and submits payment, the merchant, the card issuer, and the payment processor all lose the signals they rely on to decide whether the purchase is legitimate.

This is no longer hypothetical. Stripe reported on September 29, 2026 that agentic purchases made with its Link wallet increased 38x over the past month. Behind that growth sits a small stack of open protocols that let an agent check out, prove it was authorized, and move money without ever holding a raw card number.

This explainer walks through the main pieces: the Agentic Commerce Protocol (ACP), the Universal Commerce Protocol (UCP), the Agent Payments Protocol (AP2), x402, and the card network token programs underneath them. The goal is to show which problem each one solves and how they fit together.

The three problems an agent payment has to solve

It helps to split an agent purchase into three separate questions.

1. Checkout. How does an agent talk to a merchant's systems to build a cart, get a final price with tax and shipping, and place an order? Scraping and filling web forms is brittle, and a merchant cannot tell a well-behaved agent from a bot.
2. Authorization. How does anyone downstream know the user actually approved this specific purchase, and that the agent did not misread the request or hallucinate the item?
3. Settlement. How does money move? On card rails that means a credential the agent can use but cannot misuse. For machine-to-machine payments it can mean a direct transfer of a stablecoin.

The protocols map roughly onto these layers. ACP and UCP mostly cover checkout. AP2 covers authorization. Card network tokens, delegated payment tokens, and x402 cover settlement.

Checkout: ACP and UCP

Agentic Commerce Protocol

The Agentic Commerce Protocol was developed by Stripe and OpenAI and is open source under the Apache 2.0 license. OpenAI was the first AI platform to implement it, for checkout inside ChatGPT. The design choice that matters most is that the merchant stays the merchant of record. The agent platform presents products and collects the user's approval, but the merchant still decides what can be sold, prices the order, and fulfills it.

The checkout specification is a small REST surface the merchant exposes to agents:

• POST /checkout_sessions creates a session from items and, optionally, a buyer and address.
• POST /checkout_sessions/{id} updates it, for example when the user changes quantity or shipping.
• GET /checkout_sessions/{id} returns the current state.
• POST /checkout_sessions/{id}/complete submits payment and places the order.
• POST /checkout_sessions/{id}/cancel abandons it.

Each session carries a status: not_ready_for_payment, ready_for_payment, in_progress, completed, or canceled. If the card issuer requires a 3D Secure challenge, the merchant sets authentication_required and the agent must collect the result and send it back with the completion call. Every POST requires an Idempotency-Key header, so an agent that retries after a timeout does not place the order twice, and the spec recommends signing requests with a Signature header over canonical JSON plus a timestamp.

The merchant's response always reflects its own computed totals. The agent never asserts a price; it asks the merchant for one. That removes a whole class of errors where a model misreads a page.

Delegated payment

ACP's second piece is the delegate payment spec. Instead of handing the agent a card number, the payment provider vaults the user's credential and issues a token the merchant's processor can charge. The token is only valid within an allowance:

• reason must be one_time
• max_amount in minor units (for example, 2000 for $20)
• currency
• the checkout_session_id and merchant_id it is bound to
• expires_at, after which the token is invalid

So even if the token leaks, it can only be spent once, at one merchant, on one checkout, up to a fixed amount, before a deadline. Stripe's implementation of this is the Shared Payment Token, and ACP's site lists Stripe as the first compatible payment service provider.

Universal Commerce Protocol

The Universal Commerce Protocol covers similar ground with a wider scope. Its site lists co-developers including Google, Shopify, Walmart, Target, Etsy, Wayfair, Microsoft, Meta, Salesforce, and Stripe, and Stripe's agentic commerce docs describe Stripe as a member of the UCP Tech Council. UCP defines capabilities for catalog search, cart building, identity linking, checkout, and order tracking, with REST and JSON-RPC transports and built-in support for MCP, Agent2Agent (A2A), and AP2.

Two UCP details are worth knowing. Identity linking uses standard OAuth 2.0, with merchants publishing an authorization server at /.well-known/oauth-authorization-server and scopes such as dev.ucp.shopping.checkout. That lets an agent act on a user's existing merchant account, with loyalty pricing and saved addresses, without ever seeing the user's password. And payment is pluggable through "payment handlers," which define how a credential is acquired and passed between the platform, the merchant, and the credential provider.

In practice, ACP and UCP are two answers to the same question. A merchant that wants to be purchasable from many agent surfaces may end up implementing both, much as merchants today support several wallets.

Authorization: AP2 mandates

Checkout protocols make the transaction well formed. They do not, by themselves, prove the user wanted it. That is the job of the Agent Payments Protocol, announced by Google in September 2025 and now available as an extension for A2A and UCP. Standardization of the spec is moving to working groups at the FIDO Alliance.

AP2 frames the gap as three questions: authorization (did the user give this agent authority for this purchase), authenticity (does the request reflect the user's real intent rather than an agent error), and accountability (who is responsible when something goes wrong). Its answer is verifiable digital credentials: tamper-evident, cryptographically signed objects called mandates.

In the current version there are two mandate types, each with an open and a closed stage:

• Checkout Mandate. In its open form it records the user's goals and constraints before a cart exists, such as "running shoes, size 10, under $150." In its closed form it records authorization for one specific, finalized checkout. It is shared with the merchant.
• Payment Mandate. In its open form it records payment constraints such as a budget and allowed instruments. In its closed form it authorizes a specific amount bound to a finalized checkout. It is shared with the credential provider, the card network, and the merchant's payment processor.

The open and closed split is what makes both human-present and human-not-present purchases possible. If the user is watching, they sign closed mandates for the exact cart. If they are not, for example "buy these concert tickets the moment they go on sale," they sign open mandates in advance, and the agent later produces closed mandates that must fall inside those constraints. Either way, every party ends up with a signed chain linking the final charge back to something the user actually approved. In a dispute, that chain is evidence; in a model error, it is a hard limit.

AP2 is also deliberately rail agnostic. The project publishes samples for card payments with and without a human present, and one that settles through x402.

Settlement: tokens on card rails

For card payments, the settlement layer reuses tokenization, the same mechanism behind mobile wallets and card on file. Both major networks have agent-specific versions.

Mastercard Agent Pay, announced in April 2025, introduced Agentic Tokens. Mastercard describes them as dynamic credentials built to register, verify, and recognize agentic transactions, so each charge is tied to a specific authorized agent interaction with the permissions and limits the user set.

Visa Intelligent Commerce provisions agent-specific payment tokens. According to Visa's developer documentation, provisioning includes step-up verification of the cardholder and setting up a passkey. When the agent proposes a purchase, the user authenticates that payment instruction with the passkey. When the agent later requests credentials, Visa checks the request against the authenticated instruction, and VisaNet enforces controls at authorization time so the charge must come from the intended merchant for the correct amount.

The common idea across ACP delegated tokens, Stripe's Shared Payment Tokens, and network agent tokens is scoping. The credential the agent touches is narrower than the user's card: bound to a merchant, an amount, a time window, or a specific agent. Wallet providers add product features on top. Stripe's September update, for example, added incremental authorization to Link, so an agent can raise an approved amount when a checked bag or tax is added, rather than restarting the purchase.

Settlement: x402 for machine payments

Card rails assume a merchant, an order, and fees that make small payments uneconomical. Many agent purchases look different: one API call, one search query, one page of a paywalled dataset. x402, an open standard started by Coinbase and now maintained under the x402 Foundation, targets that case by finally using the HTTP status code 402 Payment Required, which was reserved but largely unused for decades.

The flow fits inside ordinary HTTP:

1. The client requests a resource.
2. The server responds 402 with a PAYMENT-REQUIRED header listing accepted options: scheme, network, asset, amount, recipient (payTo), and a maxTimeoutSeconds.
3. The client signs a payment and retries the same request with a PAYMENT-SIGNATURE header.
4. The server, usually through a third-party facilitator, verifies the signature, does the work, and settles the payment.
5. The server returns the resource with a PAYMENT-RESPONSE header describing the settlement.

All three headers carry Base64-encoded JSON in version 2 of the spec. There is no account, no API key, and no checkout page. An agent with a funded wallet can pay a service it has never seen before.

The protocol is network agnostic, with EVM chains and Solana among supported networks, and Coinbase's docs note USDC is the most common asset. Payment schemes define how a charge is constructed:

• exact charges a fixed amount. On EVM chains the recommended method is EIP-3009 transferWithAuthorization, where the client signs an authorization and the facilitator submits it, so the client does not pay gas. Permit2 is the fallback for tokens without EIP-3009.
• upto lets the client authorize a maximum and the server settle only what was used. The spec names LLM token generation as a target use case, since the cost of a completion is not known until it ends.
• batch-settlement confirms authorization up front and settles onchain later, which reduces per-request overhead.

x402 is a settlement and handshake layer, not a shopping protocol. It has no notion of carts, shipping, or returns. That is why it pairs naturally with AP2, which can supply the proof of user intent, while x402 moves the money.

How the pieces fit together

A typical consumer purchase through an agent today might look like this:

1. The user asks the agent to buy something. If the user will not be present at purchase time, an open AP2 mandate can capture the constraints.
2. The agent uses ACP or UCP to create a checkout session with the merchant and gets back the merchant's computed total.
3. The user, or the open mandate, approves that exact total, producing closed authorization.
4. The wallet or payment provider issues a scoped token: a Shared Payment Token, an ACP delegated token, or a network agent token, limited to this merchant and amount.
5. The agent completes the checkout session with the token. The merchant's processor charges it through normal card rails, and the network checks the controls attached to the token.

For an agent paying another service per request, steps 2 through 5 collapse into a single x402 exchange.

What is still unsettled

Several parts of this stack are early. ACP's own checkout RFC is labeled draft. AP2 is at v0.2 and moving into a standards body. Visa's developer page notes its product is still in development and deployment, and that features may not be available in all markets. Merchants face a real cost in implementing overlapping protocols, and discovery, how an agent learns that a merchant supports any of this, is still being worked out in each spec.

Liability is the larger open question. Mandates and scoped tokens create evidence and limits, but card network dispute rules were written for human cardholders. Stripe's move to offer purchase protection on eligible agent purchases through Link shows that providers expect agents to make mistakes and are pricing that in.

Why it matters for people building agents

If you build agents that transact, a few practical points follow from the specs:

• Never let the model hold raw credentials. Every protocol here exists to avoid that. Use scoped, single-use tokens.
• Let the merchant compute the price. Treat the checkout session response as the source of truth, and have the user approve that number, not one the model extracted from a page.
• Make retries safe. Idempotency keys on every write are mandatory in ACP for a reason: agents retry on timeouts.
• Record intent explicitly. Whether or not you adopt AP2, keep a signed or at least auditable record of what the user approved and the constraints they set.
• Match the rail to the transaction. Card tokens fit consumer goods with returns and disputes. x402 fits small, frequent, machine-to-machine payments.

The underlying shift is that payments are moving from a page a human reads to an API an agent calls. These protocols are the first serious attempt to make that API carry the same trust signals a human checkout used to provide.

Sources

• Stripe: Helping personal agents shop more intelligently and reliably with Link
• Agentic Commerce Protocol (agenticcommerce.dev)
• ACP specification and RFCs on GitHub
• ACP delegate payment RFC
• Stripe docs: Shared payment tokens
• Stripe docs: Universal Commerce Protocol
• Universal Commerce Protocol (ucp.dev)
• Agent Payments Protocol (ap2-protocol.org)
• Coinbase CDP docs: How x402 works
• x402 Foundation repository
• x402 docs: HTTP 402 and V2 payment headers
• x402 exact scheme on EVM
• x402 upto scheme on EVM
• Mastercard: Mastercard unveils Agent Pay
• Mastercard: How agentic tokens are driving agentic commerce
• Visa Developer: Visa Intelligent Commerce