HAHow AI agent payments work

The shared idea

Most of these protocols start from the same HTTP fact. RFC 9110 reserves status 402, Payment Required, and does not define how to pay. x402 and L402 both use the status anyway. MPP's Stripe documentation also describes a 402 response with payment details. The headers, the signatures, and the ledgers differ.

A payment that an agent can make without a person in the loop needs three things: a machine-readable price, a way to authorize the exact amount, and a settlement the server will accept. The rest of this page is how each protocol fills those in. The diagram is the default x402 path. The later sections are the other designs, not extra steps on that diagram.

The x402 flow

x402 version 2 defines the client, the resource server, and an optional facilitator. The HTTP transport carries a base64 PaymentRequired object in PAYMENT-REQUIRED, a base64 PaymentPayload in `PAYMENT-SIGNATURE`, and a settlement result in PAYMENT-RESPONSE. Coinbase's how-it-works guide walks the same request, challenge, retry, verify, and settle sequence.

The default flow is called authorization: verify the signature, run the resource, then settle, then respond. The specification also defines upfront settlement, which commits funds before the work, and an escrow flow that settles twice. A server that offers both a pay-later and a pay-first option should be met, the spec says, by a client that prefers authorization. The diagram below is authorization only.

Facilitators

The facilitator interface in the specification is two HTTP endpoints. POST /verify must be read-only. POST /settle submits the transfer and waits for the chain. CDP documents both. Hosting them is optional. What this index requires is the onchain consequence: the transaction sender, or the Solana fee payer, is a wallet in the facilitator registry.

That registry is the boundary between agent payments and ordinary stablecoin transfers. Without it, every USDC payment would enter the total. With it, a seller who is paid by an unregistered wallet is absent, even if the product is real. Rankings of the registered facilitators are on the facilitators page. A fee paid from one facilitator wallet to another is raw volume and fails the organic screen.

Where x402 settles

The scanned x402 chains are Base, Polygon, Solana, and Arc. The asset is 6-decimal USDC, priced at one dollar in this index. Arc also uses 18-decimal USDC as gas. Those gas transfers are not payments and are not added. Tempo is a separate protocol, below, not an extra x402 chain.

The chain split of the current window is the same rollup as the chains pages. Protocol share is a different cut. Do not add them.

Settled volume for the last 7 days, by blockchain. Updated Oct 25, 2026, 12:16 AM UTC. Chain totals are a slice of the same payments, not an extra pile of dollars.

Chain	Volume	Payments	Payers
Solana	$30,318	64,346	307
Base	$9,814	122,522	3,401
Tempo	$0.072956	80	9
Arc	$0.03659	13	11

Stablecoins, gas, and signatures

USDC implements EIP-3009. The holder signs from, to, value, a time window, and a nonce. The facilitator submits that signature and pays the network fee. The buyer does not need the chain's native gas token for that transfer. This is the usual meaning of gas sponsorship in x402. It is not a promise that every chain's gas is free, and it is not the same mechanism as an ERC-4337 paymaster.

The version 2 spec also allows Permit2 as an asset transfer method when the token has no EIP-3009 function. Circle's nanopayments product batches many EIP-3009 authorizations and documents a floor of one millionth of a USDC. Where those batches settle through a registered facilitator, they are already inside x402. The Transfer log does not say whether the scheme was exact, upto, or batch, so this index stores the scheme as transfer rather than inventing one.

MPP sessions on Tempo

MPP is the Machine Payments Protocol, co-authored by Stripe and Tempo. Stripe's overview says a server can return HTTP 402 and the agent pays without a checkout UI. The session method is a payment channel on Tempo's TIP-1034 escrow. The client deposits, signs vouchers for a cumulative amount, and the server checks those signatures locally. Settlement is periodic. Stripe's hosted variant records the settled amount to a Stripe balance in whole cents and forfeits a sub-cent remainder when a session closes.

The open session docs describe the onchain phases as open, voucher, settle, and close. This index counts only a positive deltaPaid on the Settled event, on Tempo mainnet, chain id 4217. The token comes from the channel's open event. pathUSD, OUSD, USDC.e, and USDT0 are priced one-to-one at 6 decimals. Other tokens are skipped. Card charges and per-merchant deposit addresses are MPP products this feed does not see. Closing a channel is not indexed, because that event repeats value already settled.

AP2 mandates

AP2 version 0.2 does not broadcast a payment. It defines a mandate. A checkout mandate gives the merchant cryptographic proof that the shopping agent may complete a specific checkout, or, in the open form, a checkout inside constraints such as allowed merchants and line items. A payment mandate gives the credential provider, the network, and the merchant's processor proof that the agent may pay that checkout, with optional constraints on amount, budget, payee, instrument, and recurrence.

The user signs through what the spec calls a trusted surface. The mandate is bound to the merchant's checkout by a hash. That is authorization evidence. If the rail under the mandate is x402, the USDC transfer is counted once, as x402. The mandate itself adds nothing to Agent GDP.

ACP checkout

ACP is the Agentic Commerce Protocol published by OpenAI and Stripe. The merchant implements checkout sessions: create, update, and complete, each returning the full cart. The agent, such as ChatGPT, collects buyer and payment details. The merchant calculates tax, judges risk, and charges through its existing processor. OpenAI's guide says the merchant remains the merchant of record.

Delegated payment is how the card details move. The agent requests a one-time token capped by amount and expiry. Stripe's shared payment token is one implementation. The capture sits inside the processor. There is no public settlement log, so ACP is explained here and omitted from the total.

L402 and Lightning

L402 is Lightning Labs' design. The 402 response carries WWW-Authenticate: L402 with a base64 macaroon and a BOLT 11 invoice. The client pays the invoice on Lightning, takes the preimage, and retries with an Authorization header: the L402 scheme, the macaroon, a colon, and the preimage. The macaroon commits to the payment hash, so the server can check the preimage without storing every invoice. The specification uses 402 when the credential is missing and 401 when it is present but invalid.

The receipt is a Lightning preimage, denominated through bitcoin, not a USDC transfer. There is no single contract this index can scan for every settled invoice. L402 stays in the glossary and on the protocol list. It is not estimated from a partial view of the network.

What gets added together

The protocol shares below are the indexable series only, from the same 7 day rollup as the Agent GDP page. A protocol with no bar is not a protocol with zero use. It is a protocol whose settlements are not in this database. The comparison puts the five designs in one table. The measurement page says how a row is included, priced, and screened.

Settled volume for the last 7 days, by payment standard. Updated Oct 25, 2026, 12:16 AM UTC. Share is that row divided by the standards in the total.

Protocol	Volume	Payments	Share
x402	$40,133	186,912	100.0%
MPMPP	$0.072956	80	0.0%