How x402 Payments Work

How x402 Payments Work: The Core Flow

Sequence diagram of how x402 payments work: the client or AI agent requests a resource; the resource server replies 402 Payment Required with payment terms; the client checks policy, budget, network and price, signs a payment authorization and retries the request with a payment signature; the server asks the facilitator to verify it; if valid the server executes the paid resource, settles through the facilitator which broadcasts to the settlement network, and returns 200 with the resource and a payment response; if invalid it returns a payment failure

The exact ordering can differ by scheme and payment-flow model. The v2 specification explicitly supports different verification/settlement orderings, but the basic business idea remains consistent: the resource should not be delivered without the required payment checks.

The Three Main Actors

11.1 Client

The client wants to buy something.

Examples:

AI agent
Browser
Mobile application
Backend server
MCP client
Data pipeline
Automated trading/risk system
Another API

The client needs:

an x402-capable payment client;
a signer/wallet;
an acceptable asset;
policy rules;
sufficient funds.

11.2 Resource Server

The resource server owns or controls the thing being sold.

It decides:

What is protected?
What does it cost?
What payment schemes are accepted?
Which networks are accepted?
Which assets are accepted?
Where should value be received?
What happens after valid payment?

11.3 Facilitator

A facilitator is an abstraction layer that can verify payment authorizations and settle them.

A simplified model:

The two facilitator operations in how x402 payments work: verify, where the resource server asks the facilitator whether an authorization is valid; and settle, where the resource server asks the facilitator to settle a valid payment and the facilitator broadcasts or executes it on the settlement network

The facilitator is optional in the architecture, but operationally useful because it removes a large amount of network-specific plumbing.

The reference design is trust-minimizing: a facilitator should not have arbitrary authority to move a payer's funds beyond what the payer has authorized.

What Actually Travels Across the Wire

For HTTP, x402 v2 uses payment information in headers.

The key conceptual headers are:

PAYMENT-REQUIRED
PAYMENT-SIGNATURE
PAYMENT-RESPONSE

A simplified payment requirement might conceptually say:

{
  "x402Version": 2,
  "resource": {
    "url": "https://example.com/api/report",
    "description": "Premium report"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "100000",
      "asset": "<token identifier>",
      "payTo": "<merchant wallet>",
      "maxTimeoutSeconds": 60
    }
  ]
}

This example is intentionally simplified.

The important fields are:

Field	Meaning
`x402Version`	Protocol version
`resource`	What the buyer is buying
`accepts`	Acceptable payment choices
`scheme`	Payment behavior
`network`	Settlement network
`amount`	Amount in the required atomic units
`asset`	Asset/currency identifier
`payTo`	Recipient
`maxTimeoutSeconds`	Valid payment window
`extensions`	Optional additional protocol capabilities

The buyer selects an acceptable payment requirement and constructs a signed PaymentPayload.

That payload provides cryptographic evidence that the buyer authorized the transaction under those terms.

If You Are Building This Commercially

If the x402 payment ultimately needs to convert into fiat or settle into ordinary operating accounts, the protocol layer may need to connect to a stablecoin payment structure and multi-currency accounts.

Key Takeaway

The payment flow is a commercial state machine: request, quote, policy decision, authorization, verification, settlement, and delivery must remain linked by identifiers and reconciliation.

This page is part of x402 Protocol Explained, the full guide to how machine-to-machine payments work.