Agent payments: AP2 and x402 compared

AP2 and x402 cover different parts of an agent payment. AP2, the Agent Payments Protocol, produces signed evidence of what a user authorized an agent to buy. The merchant, the payment credential provider and the payment processor each check that evidence before money moves, and AP2 itself moves no money. x402 puts the payment into the request and response: the server answers with a price, the client pays in its next request, and a facilitator verifies and settles, in most current schemes on a blockchain network.

AP2 answers “did the user approve this purchase, within these limits?” x402 answers “how does this request get paid?” The two can run together, and AP2’s own samples pair them.

At a glance

	AP2	x402
Purpose	Prove user authorization for an agent purchase	Request and make a payment within one exchange
Layer	Authorization evidence inside a commerce protocol	Payment signalling and settlement carried by a transport
Parties	Shopping agent, credential provider, merchant, merchant payment processor, trusted surface	Client, resource server, facilitator
What is signed	Checkout and Payment Mandates (SD-JWT) and receipts	A payment payload, such as a token transfer authorization
Money moves over	The payment method in use; AP2 is payment-agnostic	The scheme and network, such as exact on an EVM chain
Transports	Commerce protocols such as UCP; described as an A2A extension	HTTP, MCP and A2A transport specifications
Current version	v0.2, released 28 April 2026	Protocol version 2, dated 9 December 2025 in the specification
Governance	Created by Google; being donated to the FIDO Alliance (announced 28 April 2026)	Started at Coinbase; stewarded by the x402 Foundation at the Linux Foundation (operational since 14 July 2026)

How AP2 works

Roles and the agentic boundary

AP2 v0.2 defines five roles: the shopping agent, the credential provider that supplies payment credentials, the merchant, the merchant payment processor, and the trusted surface where the user gives consent. One company may play several roles.

The specification sorts roles by whether a language model handles their communication. The shopping agent is assumed to be agentic. The trusted surface MUST NOT be. When either side of an exchange is agentic, AP2 treats the agent as a potential attacker and requires tamper-evident mandates. Every verification step must run in deterministic code, even inside a role that is otherwise agentic.

Two mandates

• Checkout Mandate. The merchant signs a JWT describing the checkout and gives it to the shopping agent. The closed Checkout Mandate is bound to that JWT by hash. The merchant verifies it and returns a Checkout Receipt.
• Payment Mandate. It is bound to the same checkout by hash, and the credential provider, the network and the merchant payment processor verify it. The processor returns a signed Payment Receipt.

Each mandate type is identified by a vct value with a version suffix, such as mandate.payment.1 or mandate.checkout.open.1, and verifiers must match it exactly. Mandates are SD-JWTs (RFC 9901, November 2025), so the agent can reveal only the claims a given verifier needs.

Human present

1. The shopping agent obtains a merchant-signed checkout JWT for the final cart.
2. It builds Checkout and Payment Mandate content and hands it to the trusted surface, where the user reviews and signs it.
3. The agent sends the Payment Mandate to the credential provider, and to the network if one is involved. After verification, the agent receives a payment credential.
4. The agent gives the merchant the Checkout Mandate and the payment credential. The merchant checks the checkout against the one it created and starts the charge through its processor.
5. The processor verifies that the payment credential is scoped to that checkout.
6. The merchant returns a Checkout Receipt. The Payment Receipt goes to the agent, the credential provider and, where relevant, the network.

Human not present

For autonomous purchases, the user approves open mandates instead of a final checkout. Open mandates carry constraints and the agent’s public key in a cnf claim, and the specification recommends the shortest expiry that lets the agent finish. Later the agent signs closed mandates with that key and presents both the open and closed mandates. Verifiers evaluate every constraint, and an unknown constraint type fails.

The Payment Mandate constraint types in v0.2 cover agent recurrence, allowed payees, allowed payment instruments, allowed payment initiation service providers, amount range, budget, reference and execution date. An agent must not present a further open mandate until it has a rejection receipt for the previous one, which stops one approval funding several checkouts. Delegating a mandate from one shopping agent to another is out of scope in v0.2, and the specification defines no revocation.

Version history and governance

The first release, v0.1 on 16 September 2025, defined Intent, Cart and Payment Mandates. v0.2 replaced them with the Checkout and Payment Mandates and their open and closed forms. When you read about AP2, check which version the text describes.

On 28 April 2026 Google released v0.2 and announced it is donating AP2 to the FIDO Alliance. The FIDO Alliance said its Payments Technical Working Group will develop agent commerce specifications, starting from AP2 and Mastercard’s Verifiable Intent. The GitHub repository still hosts the specification and samples.

How x402 works

Components

x402 has three parties: a resource server that charges for something, a client that pays, and a facilitator that verifies payments and settles them on a blockchain. Servers can use a third-party facilitator or host the verify and settle endpoints themselves. The specification separates types (the messages), logic (payment schemes per network) and representation (how each transport carries the messages).

The HTTP flow (version 2)

1. The client requests a resource.
2. The server answers 402 Payment Required with a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED header, listing the payment options it accepts.
3. The client picks an option, signs a PaymentPayload, and retries with it in the PAYMENT-SIGNATURE header.
4. The server verifies the payment, directly or through the facilitator’s /verify endpoint, and runs the request.
5. The server settles, directly or through /settle, and returns the response with a PAYMENT-RESPONSE header that holds the settlement result.

Illustrative decoded PaymentRequired object:

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": {
    "url": "https://api.freight.example/lane-analysis",
    "description": "Lane pricing analysis",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "250000",
      "asset": "0xTokenContractAddress",
      "payTo": "0xMerchantWalletAddress",
      "maxTimeoutSeconds": 60
    }
  ]
}

Networks use CAIP-2 identifiers such as eip155:8453. Amounts are strings in the asset’s smallest unit.

Flows and schemes

The default payment flow, authorization, verifies before the resource runs and settles only after it completes. Schemes may also use upfront (settle first) or escrow (hold first, then settle the final charge). In every flow, at least one check runs before the resource executes.

Schemes define how a payment is built and checked. exact moves a fixed amount once and cannot return it. upto and batch-settlement handle variable and batched charges. auth-capture authorizes a maximum and then supports capture, void and refund, which suits payments that may need to be undone. For replay protection, the reference EVM authorizations carry a unique nonce and a validity window.

Governance

x402 started at Coinbase. The Linux Foundation announced its intent to launch an x402 Foundation in April 2026, and on 14 July 2026 announced the foundation’s operational launch with Coinbase’s contribution of the protocol completed. The repository now lives under the x402-foundation organization. The specification’s version history dates protocol version 2 to 9 December 2025.

How each connects to A2A

AP2 and A2A

AP2’s documentation describes the protocol as available as an extension for A2A and for the Universal Commerce Protocol (UCP). The specification treats AP2 as a security layer inside a commerce protocol, which supplies catalog and checkout APIs.

The v0.1 release included a written A2A extension with the URI https://github.com/google-agentic-commerce/ap2/tree/v0.1: agents listed their AP2 roles in the Agent Card and passed mandates in data parts. The v0.2 documentation has no A2A extension page. The v0.2 reference samples still run each role as an A2A agent, declare the URI https://github.com/google-agentic-commerce/ap2/v1, and pass objects in data parts. Until a v0.2 extension specification appears, treat the A2A binding as sample code.

x402 and A2A

The x402 v2 A2A transport maps the payment onto a task. The server agent moves the task to input-required and puts the PaymentRequired object in message metadata under x402.payment.required, with x402.payment.status set to payment-required. The client replies on the same task with x402.payment.payload. The server reports settlement in x402.payment.receipts and completes or fails the task. Agents declare the extension https://github.com/google-a2a/a2a-x402/v0.1 in their Agent Card.

The transport’s examples use A2A v0.3 shapes: kind fields, the message/send method, lowercase states such as input-required, and the X-A2A-Extensions activation header. In A2A v1.0 the equivalents are SendMessage, TASK_STATE_INPUT_REQUIRED, ROLE_AGENT, parts without kind, and the A2A-Extensions header.

Illustrative mapping of the payment-required status to A2A v1.0 shapes (the x402 transport specification itself shows only v0.3):

{
  "id": "task-123",
  "contextId": "ctx-9f1",
  "status": {
    "state": "TASK_STATE_INPUT_REQUIRED",
    "message": {
      "messageId": "msg-402",
      "taskId": "task-123",
      "contextId": "ctx-9f1",
      "role": "ROLE_AGENT",
      "parts": [{ "text": "Payment is required for the lane analysis." }],
      "extensions": ["https://github.com/google-a2a/a2a-x402/v0.1"],
      "metadata": {
        "x402.payment.status": "payment-required",
        "x402.payment.required": {
          "x402Version": 2,
          "resource": { "url": "https://api.freight.example/lane-analysis" },
          "accepts": [
            {
              "scheme": "exact",
              "network": "eip155:8453",
              "amount": "250000",
              "asset": "0xTokenContractAddress",
              "payTo": "0xMerchantWalletAddress",
              "maxTimeoutSeconds": 600
            }
          ]
        }
      }
    }
  }
}

When to use which, or both

Situation	Fit
An agent buys from a merchant with a card or bank payment, and the merchant or issuer needs proof the user approved	AP2
An agent pays per request for an API, a dataset or another agent’s skill, from a wallet it controls	x402
An agent buys on its own within a user’s limits and settles in stablecoins	Both: AP2 mandates carry the user’s authorization and x402 carries the payment. AP2 publishes human-present and human-not-present samples that use x402
A payment may need to be adjusted or refunded later	x402’s auth-capture scheme, or the refund process of the payment method used under AP2

AP2’s FAQ describes the A2A x402 work as something it will align with AP2 over time. Expect the combination to change as both specifications move through their foundations.

Common misconceptions

• “AP2 is a payment network.” It is evidence. Cards, bank transfers, stablecoins and other methods still move the money.
• “x402 only works for crypto.” Most schemes and network bindings in the specification settle on blockchain networks. The batch-settlement scheme also has a credit-backed binding, cloudflare:402, that authenticates payment commitments with HTTP Message Signatures and settles later through the network operator. The project’s README says x402 may extend to fiat networks.
• “The x402 A2A examples are A2A 1.0.” They use v0.3 message shapes and header names.
• “A user can revoke an AP2 mandate.” v0.2 defines expiry and single-use rules but no revocation.
• “Using both means paying twice.” AP2 authorizes and records. x402 moves the funds once.

Emissar’s Settle module is planned on top of AP2 and x402, checking amounts against Mandate limits before money moves and recording each transaction. Its status is Planned.