1. Introduction: Why x402 Matters

On today’s internet, making payments — especially micropayments or automated payments driven by AI agents — is riddled with friction. Traditional payment methods are expensive, slow to settle, and burdened with complex flows that require account registration, credit card binding, and manual authorization. This has become a massive obstacle to the growth of the AI-driven automated economy.

x402 was created to solve these pain points. You might think x402 sounds like the most boring technology you’ll ever encounter, but the possibilities it unlocks are where things get truly exciting. It cleverly revives the long-reserved, nearly forgotten 402 Payment Required status code from the 1997 HTTP/1.1 specification. This isn’t an entirely new idea — industry pioneers like Marc Andreessen and Brian Armstrong have tried to build native payments into the internet’s foundation layer — but only now have the enabling technologies (like stablecoins) and the demand (like AI agents) truly matured. At its core, x402 is “an open standard for internet native payments.” It aims to make money flow as seamlessly, instantly, and cheaply as data does. This guide breaks down x402’s core payment flow step by step, giving you a clear and solid technical understanding.

Before diving into the specific steps, let’s meet the four key participants in the x402 ecosystem.

2. Core Concepts: The Four Key Roles

A complete x402 payment interaction involves four core entities working together, each playing an indispensable role.

Client: An entity wanting to pay for a resource — for example, an AI agent or a web application.

Resource Server: An HTTP server that provides protected resources (such as APIs, web content, or files) and requires payment before granting access.

Facilitator Server: A third-party service that helps resource servers verify and settle on-chain payments, dramatically simplifying server-side integration by eliminating the need to interact directly with blockchain nodes or wallets.

Blockchain: The ultimate trust ledger, responsible for recording and confirming payment transactions, ensuring immutability and finality.

Now that we know the cast, let’s walk through a complete request lifecycle and see how these roles interact step by step to complete a payment.

3. The Core Payment Flow: A Complete x402 Interaction (12 Steps)

The entire payment flow is carefully designed as a series of standard HTTP interactions, ensuring universality and ease of integration. Notably, if the client has already cached the resource’s payment requirements, steps 1 and 2 are optional, which can further improve efficiency.

Here is the full 12-step breakdown:

  1. Client → Resource Server: Initial Request The client (e.g., an AI agent) sends a standard HTTP GET request to the resource server’s protected endpoint (e.g., /api), hoping to retrieve a resource.
  2. Resource Server → Client: 402 Payment Required Response The resource server detects that the request contains no valid payment information and rejects it. It returns a 402 Payment Required status code with a JSON body detailing the accepted payment methods, amounts, and receiving addresses.
  3. Client: Creates Payment Payload The client parses the server’s payment requirements, selects a payment method it supports, and constructs a payment payload containing signed authorization and other details.
  4. Client → Resource Server: Retry with Payment The client sends another request to the same resource endpoint. This time, it includes the payment payload from the previous step via a custom X-PAYMENT HTTP header.
  5. Resource Server → Facilitator: Request Payment Verification The resource server doesn’t handle complex on-chain verification itself. It forwards the client’s payment payload along with its own payment requirements to the facilitator server’s /verify endpoint.
  6. Facilitator → Resource Server: Verification Result The facilitator server performs cryptographic verification of the payment payload based on the specified scheme and network, then returns the result (valid or invalid) to the resource server.
  7. Resource Server: Processes the Valid Request If verification passes, the resource server begins executing the core work for the request (e.g., querying a database, generating a report). If verification fails, it returns a 402 error and the flow terminates.
  8. Resource Server → Facilitator: Request Payment Settlement After preparing the final response data, the resource server sends a request to the facilitator server’s /settle endpoint, asking it to actually settle the verified payment on the blockchain.
  9. Facilitator → Blockchain: Submit Transaction The facilitator server broadcasts the payment transaction to the appropriate blockchain network (e.g., submitting a USDC transfer to a smart contract).
  10. Blockchain: Confirms the Transaction The blockchain network processes the transaction and, once confirmed, records it on-chain, completing the final transfer of funds.
  11. Facilitator → Resource Server: Settlement Confirmation The facilitator server waits for blockchain confirmation. Once complete, it returns a success response to the resource server containing the transaction hash (txHash) and other details.
  12. Resource Server → Client: Returns the Resource Upon receiving the settlement confirmation, the resource server returns a 200 OK response to the client. The response body contains the originally requested resource, while the X-PAYMENT-RESPONSE header carries settlement details (such as the transaction hash), closing the payment loop.

Now that you understand the complete interaction flow, let’s take a closer look at the key data structures passed during these steps — the payment requirements and the payment payload.

4. Key Data Structures

Information exchange in the x402 protocol relies on two core JSON data structures.

1. The 402 Response Body: Payment Required Response

When the server returns a 402 status code, the response body contains a JSON object that tells the client how to pay.

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "string",
      "network": "string",
      "maxAmountRequired": "string",
      "resource": "string",
      "description": "string",
      "mimeType": "string",
      "outputSchema": {},
      "payTo": "string",
      "maxTimeoutSeconds": 60,
      "asset": "string",
      "extra": {}
    }
  ],
  "error": "string"
}

The table below explains the most important fields:

Field Description
accepts A list of payment requirements. The server can accept payment across multiple chains or tokens simultaneously, and the client can choose one.
maxAmountRequired The maximum amount required to access the resource, expressed in the asset’s atomic units. This is the most critical piece of information for the client when constructing its payment payload.
payTo The wallet address that will receive the payment. This is where the resource provider ultimately receives their funds.
asset The contract address of the payment asset. For example, on EVM chains this is typically the contract address of an ERC20 token like USDC.

2. The X-PAYMENT Request Header: Payment Payload

The X-PAYMENT custom HTTP header carries the payment information. Its value is the Payment Payload JSON object, which has been encoded into a Base64 string.

{
  "x402Version": 1,
  "scheme": "string",
  "network": "string",
  "payload": "<scheme dependent>"
}
  • scheme: Defines the payment logic, which is what makes x402 so flexible. For example, the exact scheme is used for one-time, exact-amount payments (like paying $0.25 to read a news article), while a theoretical upto scheme could support dynamic, usage-based pricing (like paying based on the number of tokens an LLM generates).
  • network: Specifies which blockchain the payment will be executed on. The combination of scheme and network together determines the specific implementation for payment verification and settlement.

With these technical details covered, let’s look at what x402 actually means for developers and the future of internet applications.

5. What This Means for Developers: Core Advantages Unlocked by x402

x402 isn’t just a technical specification — it gives developers powerful capabilities for building next-generation internet applications, especially AI applications.

  • Dramatically Simplified Integration Developers can add payment functionality to their services with minimal effort. In the simplest case, a single line of middleware configuration is all it takes to start accepting digital dollar payments. This is possible because the protocol abstracts away complex blockchain interactions — issues like gas fees and RPC node management are all handled by the facilitator server.
  • Enabling AI Agents and Micropayments Traditional payment systems, with their high fixed fees and friction, make sub-dollar microtransactions virtually impossible. With its low cost and instant settlement, x402 makes it practical for AI agents to autonomously pay for API calls (e.g., a few cents per request) or for users to pay per article. This unlocks entirely new business models, letting us move beyond rigid subscription plans toward truly granular, pay-per-use content and API consumption.
  • An Open and Neutral Standard x402 is an open protocol, agnostic to chains and tokens, with no dependency on any single centralized provider. Developers can freely choose the blockchain and assets that best fit their business, avoiding platform lock-in and ensuring long-term flexibility and security.

6. Summary and Next Steps

x402 is an open protocol built on top of HTTP, purpose-designed for AI and machine-native payments. By reviving the long-dormant 402 status code, it creates a unified, frictionless value layer for the internet. This isn’t just a technical upgrade — it’s about the shape of the future internet economy. According to A16Z, by 2030, agentic commerce could create a payment market worth up to $30 trillion. x402 is the infrastructure being built to meet that future.

Through this guide, you’ve gained a solid understanding of x402’s core interaction flow and key concepts. Now is the perfect time to start building. We encourage you to visit the official resources, explore sample code and deeper technical specifications, and begin your journey into internet-native payments.