Key Features

  • HTTP 402 Native: Leverages the long-dormant HTTP 402 status code for payment negotiation directly in the protocol layer.
  • Scheme + Network Extensibility: Extensible across (scheme, network) pairs (e.g., exact payments on different chains) with facilitator support for verification and settlement.
  • Agent-First Design: Built for autonomous AI agents to pay for services without human intervention or OAuth flows.
  • Facilitator Architecture: Resource servers can verify and/or settle payments via facilitator endpoints (e.g., /verify and /settle) instead of implementing chain logic directly.
  • Idempotent Payments: Payment proofs are idempotent - same proof can be retried without double-spending.
  • Modernized Payment Headers: Uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE headers (v2) to carry payment metadata while keeping response bodies usable.

Use Cases

  • AI agent API access - Agents pay per-call for external APIs without pre-negotiated contracts
  • Compute marketplace - Pay-per-inference for GPU compute without subscription overhead
  • Data marketplace - Micropayments for real-time data feeds and premium content
  • Tool monetization - MCP server operators can charge per-tool-invocation
  • Cross-agent payments - A2A protocol payments for delegated task completion

Pros & Cons

Advantages
  • Sub-cent transactions enable true micropayments (pay-per-token, pay-per-call)
  • No OAuth, API keys, or billing accounts - just cryptographic payment proofs
  • HTTP-native means any web server can become payment-enabled
  • Base L2 settlement provides near-instant finality (~2 seconds)
  • Open standard - not locked to any vendor or payment processor

Disadvantages
  • Multi-network support depends on SDK/facilitator support for specific (scheme, network) pairs
  • Facilitator trust model adds centralization for low-latency use cases
  • Regulatory uncertainty around autonomous agent payments
  • Early stage - limited tooling and SDK support
  • Wallet management complexity for agent deployments

Architecture & Core Concepts

  • Payment Flow: Client requests resource → Server returns 402 with PAYMENT-REQUIRED → Client retries with PAYMENT-SIGNATURE → Server verifies (locally or via facilitator) → Server fulfills request and may return PAYMENT-RESPONSE
  • Payment Proof: Signed transaction hash + block confirmation proving USDC transfer to specified address
  • Facilitator Role: Optional intermediary that pre-verifies payments and issues bearer tokens for low-latency access
  • Price Discovery: PAYMENT-REQUIRED header can advertise one or more accepted requirements for amount, asset, scheme, and network
  • Retry Semantics: Payment proofs are idempotent - clients can safely retry failed requests with same proof

Code Examples

402 Response Headers

http 
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64-encoded PaymentRequired>
Content-Type: application/json

{"error": "Payment required", "price": "0.001 USDC"}

Payment Proof Request

http 
POST /api/inference HTTP/1.1
PAYMENT-SIGNATURE: <serialized PaymentPayload>
Content-Type: application/json

{"prompt": "Analyze this data..."}

Python Client Example

python 
from x402 import PaymentClient

client = PaymentClient(
    wallet_key="0x...",
    facilitator="https://facilitator.example.com"
)

# Automatic payment handling
response = client.get("https://api.example.com/premium-endpoint")
# Client detects 402, pays, retries automatically

Server Middleware

python 
from x402.middleware import require_payment

@app.route("/api/inference")
@require_payment(amount=0.001, currency="USDC")
def inference(request):
    # Payment already verified by middleware
    return run_inference(request.json)