> ## Documentation Index
> Fetch the complete documentation index at: https://docs.semanticpay.io/llms.txt
> Use this file to discover all available pages before exploring further.

# x402

> x402 is an open payment protocol that enables instant, programmatic stablecoin payments directly over HTTP, turning every API into a payable endpoint.

# What is x402?

x402 is an open payment protocol, [originally developed by Coinbase](https://docs.cdp.coinbase.com/x402/welcome), that enables instant, programmatic stablecoin payments directly over HTTP.

It revives the long-reserved [HTTP 402 Payment Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402) status code and gives it a concrete, blockchain-native meaning: if you want this resource, pay for it, right now, in this request.

No accounts. No API keys. No checkout flows. Just HTTP.

x402 picks up where HTTP left off. It makes payment a first-class citizen of the web, which is especially critical now that AI agents need to pay for resources programmatically.

<CardGroup cols={2}>
  <Card icon="user-slash" title="No Accounts">
    Clients don't need to register, authenticate, or manage sessions. A wallet is the only credential.
  </Card>

  <Card icon="globe" title="HTTP-Native">
    Works with existing web infrastructure. Standard headers,  status codes, and request-response.
  </Card>

  <Card icon="robot" title="Machine-Ready">
    AI agents can discover payment requirements and settle them autonomously.
  </Card>

  <Card icon="link" title="Chain-Agnostic">
    Supports multiple networks through facilitators. EVM, Solana, and more, identified by [CAIP-2 standards](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md).
  </Card>
</CardGroup>

## How it works

The x402 flow is a simple extension of HTTP. A client requests a resource, the server says "pay me," the client pays, and the server delivers.

```mermaid theme={null}
sequenceDiagram
    participant Client as Client (Buyer)
    participant Server as Resource Server
    participant Facilitator as Facilitator
    participant Chain as Blockchain

    Client->>Server: 1. GET /api/resource
    Server-->>Client: 2. 402 Payment Required + payment details
    Note over Client: 3. Sign payment with wallet
    Client->>Server: 4. GET /api/resource + X-PAYMENT header
    Server->>Facilitator: 5. POST /verify (payment payload)
    Facilitator-->>Server: 6. Valid ✓
    Note over Server: 7. Perform the task (generate response, run inference, fetch data...)
    Server->>Facilitator: 8. POST /settle (payment payload)
    Facilitator->>Chain: 9. Submit transaction
    Chain-->>Facilitator: 10. Confirmed ✓
    Facilitator-->>Server: 11. Settlement receipt
    Server-->>Client: 12. 200 OK + resource + X-PAYMENT-RESPONSE
```

### Step by step

<Steps>
  <Step title="Client requests a resource">
    The client sends a standard HTTP request.
  </Step>

  <Step title="Server responds with 402">
    If payment is required, the server returns `402 Payment Required` with a JSON body describing what to pay: amount, token, network, and the recipient address.

    ```json theme={null}
    {
      "x402Version": 1,
      "accepts": [{
        "scheme": "exact",
        "network": "eip155:9745",
        "maxAmountRequired": "1000000",
        "asset": "0xB8CE59FC3717ada4C02eaDF9682A9e934F625ebb",
        "resource": "https://api.example.com/data",
        "payTo": "0x1234...abcd"
      }]
    }
    ```
  </Step>

  <Step title="Client signs payment and resubmits">
    The client reads the requirements, constructs an ERC-3009 payment authorization, and signs it with their wallet. No tokens leave the wallet yet. It's a signed intent, not a transfer. The client retries the same request with the signed payload in the `X-PAYMENT` header.
  </Step>

  <Step title="Facilitator verifies the payment">
    The server forwards the payment payload to the facilitator's `/verify` endpoint. The facilitator checks that the signature is valid, the amount is sufficient, and the payer has enough funds. If everything checks out, it returns valid. No money has moved yet.
  </Step>

  <Step title="Server performs the task">
    Now that payment is verified, the server does the actual work (running inference, querying a database, generating a report, whatever the resource requires).
  </Step>

  <Step title="Facilitator settles the payment">
    After the task is complete, the server calls the facilitator's `/settle` endpoint. The facilitator submits the signed authorization on-chain, transferring tokens from the client to the seller. Once the blockchain confirms the transaction, the facilitator returns a settlement receipt.
  </Step>

  <Step title="Server delivers the resource">
    The server returns `200 OK` with the requested resource in the body and a settlement receipt in the `X-PAYMENT-RESPONSE` header. From the client's perspective, this is a single request-response cycle.
  </Step>
</Steps>

The key insight: **verify before doing work, settle after**. The server never spends resources on unverified requests, and the client's funds only move after the task is complete.

## The three roles

<AccordionGroup>
  <Accordion icon="user" title="Client (Buyer)">
    The entity requesting a paid resource. Can be a human application, an AI agent, or any programmatic service with a wallet. The client's only job is to read payment requirements from a `402` response, sign a payment, and resubmit.
  </Accordion>

  <Accordion icon="server" title="Resource Server (Seller)">
    The service providing the paid resource (an API, a dataset, a tool). The server defines payment requirements (amount, token, network) and returns `402` for unpaid requests. It delegates verification and settlement to a facilitator.
  </Accordion>

  <Accordion icon="handshake" title="Facilitator">
    An intermediary service that verifies payment signatures and submits transactions on-chain. The facilitator never holds funds. it executes signed authorizations. It exposes two endpoints: `/verify` (is this payment valid?) and `/settle` (submit it on-chain).

    Semantic operates a public facilitator at `https://x402.semanticpay.io` supporting USD₮0 on Plasma and Stable chains.
  </Accordion>
</AccordionGroup>

## x402 is an open standard

x402 is not proprietary to any single provider. Anyone can build a client, a resource server, or a facilitator. The protocol is defined by its HTTP semantics and payment payload format, not by a specific SDK or platform.

**Semantic operates the first USD₮-enabled x402 facilitator, bringing the world's most liquid stablecoin to the protocol**.

<Info>
  For the full protocol specification and reference implementations, visit [x402.org](https://www.x402.org) and the [x402 GitHub repository](https://github.com/coinbase/x402).
</Info>

## Next steps

<CardGroup cols={2}>
  <Card icon="wallet" href="/wdk" title="What is WDK?">
    Learn about Tether's Wallet Development Kit that powers Semantic's facilitator
  </Card>

  <Card icon="coins" href="/usdt" title="Why USD₮?">
    Understand why we chose USD₮ and stablecoin-optimized chains
  </Card>

  <Card icon="rocket" href="/client" title="Quick Setup">
    Get your first payment working in 5 minutes
  </Card>

  <Card icon="code" href="/endpoints" title="API Reference">
    Explore the facilitator endpoints
  </Card>
</CardGroup>