x402 and Agent-to-Agent Payments: Protocol Guide and Comparison

Last updated: September 13, 2026. Protocol details below were checked against the x402 specification repository, the AP2 repository, the MPP drafts at paymentauth.org, and each vendor's own published code on that date.

Agents that call paid APIs need a way to pay for a single request without a signup, an API key, or an invoice. Four approaches are competing for that job, and they are not really competing — three of them sit at different layers, and the fourth is not a protocol. This page explains x402, compares it honestly with the alternatives, and shows what has to exist underneath any of them before an agent can be trusted to spend.

For the wallet-by-wallet view of this market, see the best agent wallets for developers. For a broader survey that also covers ACP, see agentic payment protocols compared.

What is x402?

x402 is an open payment standard that turns the HTTP 402 Payment Required status code into a working payment challenge for machine clients. When a client requests a resource without paying, the server answers with a machine-readable PaymentRequired object describing what it will accept — the payment scheme, the network, the asset, the amount, and the address to pay. The client signs a payment authorization with its wallet and repeats the request carrying that authorization. A third party called a facilitator verifies the signature and settles the payment on-chain, and the server returns the resource.

The protocol has three participants: a resource server that gates something behind payment, a client (an application or an agent) that wants it, and a facilitator that handles verification and blockchain settlement. Splitting the facilitator out is what lets a resource server accept payment without running blockchain infrastructure or holding keys.

x402 was created by Coinbase and contributed to the x402 Foundation, an open-governance body hosted by the Linux Foundation. The Linux Foundation announced the foundation's operational launch on July 14, 2026, alongside the completion of Coinbase's protocol donation, with 40 member companies from financial services, cloud infrastructure and payments. The specification is published under Apache-2.0 at github.com/x402-foundation/x402.

The protocol is blockchain-agnostic. It is used mainly for stablecoin payments on EVM chains and Solana, and the specification separates the payment scheme (the logic of how value moves) from the transport (how the messages are carried), so the same payment types work over HTTP, MCP, and A2A.

How an x402 payment works

The v2 specification defines a four-step cycle:

1. Client request. The client requests a protected resource with no payment attached.
2. Payment required. The server responds with a PaymentRequired object. Over HTTP, this travels in a base64-encoded PAYMENT-REQUIRED response header. It contains x402Version, a resource description, and an accepts array — one entry per payment method the server will take.
3. Payment authorization. The client picks an entry from accepts, signs an authorization with its wallet, and retries the request with the signed payload in a PAYMENT-SIGNATURE header.
4. Settlement. The server verifies the authorization — usually by calling a facilitator's /verify — serves the resource, and has the facilitator /settle the payment on-chain.

A PaymentRequired payload looks like this:

The scheme field is the extension point. Four schemes are specified in the repository today:

The default flow verifies payment before the resource runs and settles afterwards. Schemes may declare other orderings.

One version caveat. Both v1 and v2 are published in the spec repo, and they do not use the same header names — v1 implementations carry the payment in an X-PAYMENT header, v2 uses PAYMENT-REQUIRED and PAYMENT-SIGNATURE. A client and a server still have to agree on a version. Check which one a given SDK implements before assuming interoperability.

The protocol landscape

x402 is one of several things people mean by "agent payments." They sit at different layers, and the useful question is usually which layer you are missing, not which protocol wins.

Three points that the table can obscure:

AP2 is not an alternative to x402. Its own overview describes it as an extension for A2A, MCP and UCP. It answers "what verifiable proof shows the user granted this agent authority to make this purchase," using Mandates — signed credentials with defined types (mandate.checkout.1, mandate.payment.1) that a user approves on a trusted surface and delegates to the agent. A verifier challenges the agent, the agent presents the mandate, and the verifier returns a receipt. An agent can hold an AP2 mandate and settle over x402.

MPP's main design difference from x402 is that it does not invent headers. It is built on a Payment HTTP authentication scheme, so the exchange is an ordinary HTTP auth challenge. That buys compatibility with existing HTTP tooling — proxies, auth middleware, caches — at the cost of expressing payment semantics inside a framework designed for identity. x402 does the opposite. Reasonable engineers disagree about which is better.

Plain MCP tool-calling with a funded wallet is what most agents actually do today, and it is worth naming as the baseline rather than dismissing it. It works, it needs no protocol, and it is entirely adequate when the agent and the service are both yours. It gives you nothing when they are not: no standard challenge, no receipt, no way for an unknown service to charge an unknown agent.

How mature is x402, really?

x402 has the most momentum of the three, and it is still early. Both things are true and it is worth being precise about which.

The x402.org dashboard reported the following for the trailing 30 days, retrieved September 13, 2026:

That is real usage. It is also an average of roughly $0.32 per transaction — a micropayment profile consistent with API metering and pay-per-call inference, not with commerce. Anyone citing x402 transaction counts next to card-network volume is comparing different things.

Two more honest signals. The v1/v2 header split above is unresolved interop friction. And the vendor field is thinner than the announcement list suggests: several vendor x402 repositories have not been touched in roughly six months, which is a long time in a protocol that shipped a new major spec version in that window.

None of that argues against building on it. It argues for pinning a spec version, testing against the facilitator you will actually use, and not assuming any two implementations interoperate because both say "x402."

What an agent needs underneath a payment protocol

A payment protocol tells an agent how to pay. It says nothing about whether the agent should. Every one of these protocols assumes four things already exist below it, and that layer is where autonomous spending actually goes wrong.

A funded account the agent controls. Not a shared treasury key. One account per agent, so you can attribute, rate-limit and revoke each independently. For the exact scheme on EVM the payer signs off-chain, so the account needs the stablecoin but not gas — though it will need gas or sponsorship for anything that touches the chain directly.

Signing authority scoped to the job. The agent should hold authority to sign a bounded set of operations, not custody of a key that can sign anything. Scope means specific contracts, specific methods, a spend ceiling, and a time window. The practical test: if the agent's process is compromised, what is the worst single transaction it can produce?

A spend policy enforced before the signature exists. Checking spend after the fact is accounting, not control. The policy has to run at the point of signing and refuse to produce the signature. It should be fail-closed — if no rule matches, deny — because an allowlist that defaults to permit is not an allowlist.

An audit trail. Every signature, what it authorized, which policy admitted it, and when. This is what makes an incident investigable and what AP2's mandate-and-receipt model is trying to standardize at the protocol level.

x402 deliberately leaves all four out of scope — its specification excludes client-side budget management and session handling. That is the right call for a wire protocol and it means the wallet layer has to supply them.

Openfort's agentic wallets implement this as backend wallets plus signing policies, where policy evaluation is fail-closed and runs automatically on every operation. See also agent permissions and identity and how to build an agent wallet.

Implementing x402 with Openfort

Openfort does not ship an x402 module in its SDK. It documents x402 as a recipe built on the standard embedded and backend wallet APIs, with source in recipes-hub. That distinction matters if you are comparing vendors: Thirdweb and Privy ship x402 helpers inside their main SDKs, which is a shorter path for the common case.

EVM: signing the payment authorization from a backend wallet

The exact scheme on EVM asks the payer for an EIP-712 TransferWithAuthorization signature (EIP-3009). It is an off-chain signature, so the agent's wallet never needs ETH. Fetch the backend wallet, then sign the authorization the server asked for:

The signed payload is base64-encoded into the payment header and sent back with the retried request. Gas is covered one of two ways, and they are mutually exclusive: an Openfort fee sponsorship (the backend wallet is upgraded to an EIP-7702 delegated account and the transaction runs through a paymaster), or the Coinbase CDP facilitator, which verifies the off-chain signature and pays gas to submit transferWithAuthorization itself. The recipe covers USDC on Base and Base Sepolia.

Bound the wallet with a signing policy before it signs anything in production. Openfort policies are account- or project-scoped and fail closed:

Solana: the signer Solana Foundation publishes

On Solana the integration is upstream rather than in Openfort's own repo. Solana Foundation's solana-keychain includes an Openfort backend-wallet signer in Rust, TypeScript and Python, published on npm as @solana/keychain-openfort. It calls Openfort's POST /v2/accounts/backend/{accountId}/sign endpoint with an ES256 x-wallet-auth JWT and resolves the wallet's Solana address at initialization:

Because it satisfies the standard signer interface, it works anywhere a Solana signer is accepted — including x402 and MPP client paths.

pay.sh: the CLI path, and an honest status note

pay is Solana Foundation's CLI for agentic payments. It wraps another command, detects a 402 challenge, prepares and signs the stablecoin transaction, and retries — so an agent session gets paid API access without any protocol code of its own:

An open pull request, #423, adds Openfort backend wallets as a keystore backend so pay can sign remotely instead of holding a local keypair. It is still open as of September 13, 2026 and has not been merged, so a released pay binary cannot use it. The underlying signer it depends on is merged and published — that is the @solana/keychain-openfort package above — but the CLI wiring is not. Treat the CLI path as pending, not available.

Provider support for agent-payment rails

Verified on September 13, 2026 by inspecting each vendor's published repositories, SDK packages and documentation. A blank cell means no first-party support was found at that date — not that support is impossible, and not that a vendor's wallet cannot be used with the protocol through generic signing. Vendors are listed alphabetically.

Two caveats on reading this table. Turnkey's row is blank because we could not complete the check, not because we confirmed an absence; treat it as unknown. And "Yes" measures published first-party support, not quality or production-readiness — Coinbase's row and Alchemy's row are both "Yes" and are not remotely the same thing.

The AP2 column being empty across every wallet vendor is the real finding here. AP2 targets merchants, issuers and payment processors rather than wallet infrastructure, so its absence from this table is a statement about scope, not about adoption.

Choosing between them

• Metering an API for machine clients, including agents you do not control. x402. It has the governance, the transports and the facilitator ecosystem, and exact and upto cover most metering shapes.
• Settling on Solana, or already in the Solana toolchain. Either x402 or MPP; pay supports both. MPP's Token-2022 confidential-transfer support is the differentiator if amounts need to be private.
• A merchant, bank or processor needs to know who authorized a purchase. AP2, layered over whichever settlement rail you use. This is a liability question, and no settlement protocol answers it.
• Both ends of the transaction are yours. Plain MCP tool-calling with a policy-bounded wallet. Adopt a protocol when you need to transact with someone you have not integrated with.

Whichever you pick, the wallet controls underneath matter more than the protocol choice — those are the part that stops an agent from spending what it should not, and none of these protocols provide them.

Related guides

• Best AI agent wallets for developers — the vendor-by-vendor comparison
• MPP, x402, ACP & AP2 compared — the four-protocol survey, including ACP
• Inside x402: enabling payments with HTTP 402 — the protocol walkthrough
• Machine payments: when software pays software — the machine-to-machine view
• Agent permissions, identity and compliance — the controls layer
• Best embedded wallets for stablecoin payments — wallets tuned for USDC/USDT