AI paywalls, HTTP 402, and portable records

AI agents can now read, write, call APIs and act on our behalf. The one thing they could not do for a long time was pay for what they use.

That gap is closing fast. New payment standards built on HTTP 402 Payment Required, like x402, are turning APIs and web resources into machine-readable paywalls that AI agents can clear automatically.

1. From "is this a bot" to "this bot paid under these terms"

In the previous piece on agent and crawler identification we focused on visibility: spotting AI agents in your traffic, using metadata, fingerprints, and access logs to understand who is calling you and why.

That is necessary, but not sufficient. If you are a publisher, API provider, SaaS platform, or data owner, the key questions are:

• Who is allowed to access which resources
• On what terms and price
• How do we prove what actually happened

Content-level AI detection tools and forensics answer "what probably happened" on the media side. They do not give you:

• A machine-readable policy that agents must follow
• A native way to charge them
• A signed record that will hold up in an audit or partner review

PEAC exists to close that gap. The protocol treats every AI access event as something that can be priced, consented, and proven.

2. HTTP 402 and the rise of the AI paywall

2.1 A dormant status code wakes up

HTTP 402 Payment Required has existed in the spec for decades, but is still documented by MDN as nonstandard and reserved for future use. There has been no agreed convention for how clients and servers exchange payment data over 402, so most products ignored it. That is changing through layered specifications such as x402 that define their own headers and bodies above the bare status code:

• x402. A chain-agnostic HTTP 402 protocol for stablecoin payments. Servers respond with 402 and a machine-readable payment challenge; clients pay and retry with proof.
• Commercial providers. From Cloudflare to Web3 infra companies, now shipping 402-based paywalls for crawlers and APIs.
• Stripe. Uses 402 Payment Required in parts of its API surface when payment issues occur, making 402 a familiar concept in card-based integrations.

In other words, HTTP 402 is becoming the native status code for AI paywalls and machine-friendly payments.

2.2 What PEAC adds on top

PEAC does not try to replace x402 or Stripe. Our direction is explicit: the protocol is a portable record layer that completes existing payment rails rather than competes with them.

PEAC 0.9.12 - Generic HTTP 402 semantics

• How resources advertise that they are 402-gated
• How policies and AI preferences (AIPREF) are discovered
• How 402 responses are described in a consistent way

PEAC 0.9.13 - Economic layer

• Normalized payment block in the record schema
• Adapters for x402 and Stripe
• Provenance and consent fields wired into records
• Verification latency budget under 5 ms p95

PEAC 0.9.14 - Reporting and standards hooks

• Compliance reports built on top of records

3. The PEAC flow: from detection to 402 to PEAC-Receipt

At a high level, every PEAC integration follows the same five-step loop:

1. Discover. The AI agent fetches /.well-known/peac.txt and learns where to fetch AIPREF, how access control works, which payment rails are supported, where to verify records, and which public keys to trust.
2. Evaluate. The PEAC kernel merges your AIPREF policy, resource-level rules, and any caller identity into a decision: allow, allow with payment, or deny.
3. Challenge with HTTP 402. If payment is required, the server returns HTTP 402 with a machine-readable description of the price and rail, plus enough information for the client to complete payment.
4. Settle on the chosen rail. The AI agent uses the x402 or Stripe adapter flow to pay and obtain a proof.
5. Prove with PEAC-Receipt. When the client retries, the PEAC kernel verifies the payment proof, recomputes the policy hash, issues a signed record, and sends the resource back with a PEAC-Receipt header.

Records always bind to policy_hash, and when an AIPREF policy exists, an aipref_snapshot is embedded so that future audits do not depend on external files. The payment block is optional and only present when a payment adapter was actually used.

4. Concrete flows across x402 and Stripe

4.1 x402: stablecoin AI paywalls over HTTP

x402 activates HTTP 402 for onchain or rollup-based stablecoin payments. Servers respond with a 402 and payment requirements; clients pay and retry with proof.

HTTP 402 x402 challenge:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "rail": "x402",
  "price": "0.05",
  "currency": "USD",
  "asset": "USDC",
  "chain": "solana-mainnet",
  "destination": "wallet-address",
  "expires_at": "2025-12-01T09:45:00Z"
}

The agent sends the required USDC transaction, retries with proof, and the x402 adapter normalizes this into the payment block with rail: "x402". AI paywalls for datasets, prompts, or APIs can now take USDC while your accounting stack only sees standardized PEAC records.

4.2 Stripe: card rails behind an AI paywall

Stripe already uses 402 in some scenarios when payment is required or fails.

HTTP 402 Stripe challenge:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "rail": "stripe",
  "price": "9.99",
  "currency": "USD",
  "payment_intent": "pi_3ZQ...",
  "client_secret": "pi_3ZQ..._secret_..."
}

The client uses Stripe Elements to complete the payment, then retries once the intent is succeeded. The Stripe adapter confirms the payment and issues a PEAC-Receipt.

5. What actually ends up in a PEAC-Receipt

To make the billing, audit and compliance story concrete, here is a simplified example of what a PEAC record for a paid AI request might look like:

Example PEAC-Receipt (simplified):

{
  "version": "0.9.13",
  "policy_hash": "b64url-sha256-of-canonical-policy",
  "aipref_snapshot": {
    "url": "https://example.com/.well-known/aipref.json",
    "hash": "b64url-sha256-of-aipref",
    "effective_at": "2025-11-01T00:00:00Z"
  },
  "resource": {
    "method": "GET",
    "path": "/api/report",
    "etag": "W/\"6e2-abc...\""
  },
  "agent": {
    "id": "agent:originary:client-123",
    "kind": "crawler"
  },
  "decision": {
    "effect": "allow",
    "reason": "paid"
  },
  "payment": {
    "rail": "x402",
    "reference": "solana-tx-123...",
    "amount": 0.05,
    "currency": "USD",
    "settled_at": "2025-12-01T09:30:21Z",
    "idempotency": "req_9b3c5..."
  },
  "issued_at": "2025-12-01T09:30:22Z",
  "proof": {
    "alg": "Ed25519",
    "kid": "peac-key-2025-09",
    "jws": "eyJhbGciOiJFZERTQSIs..."
  }
}

Key fields:

• policy_hash + aipref_snapshot - tell you exactly what rules were in force when this AI paywall was applied.
• resource - ties things to a concrete path and ETag.
• payment - uniform across x402 and Stripe; only the rail and reference semantics differ.
• proof - binds it all cryptographically so third parties can verify without talking to your servers.

For accounting, you can roll up payment.amount by resource or customer. For compliance, you can prove that specific AI calls were made under specific policies and paid in specific ways.

6. What PEAC does not do

• PEAC does not custody funds, settle payments, or replace acquirers and processors.
• PEAC does not pick the payment rail; it carries a signed record of the exchange whatever rail clears it.
• PEAC does not enforce pricing or contract terms; it records what was offered and what was accepted.
• PEAC does not become a billing system; it composes with x402, Stripe, and existing billing stacks.
• PEAC does not assert chargeback or refund finality; settlement state belongs to the rail.

7. How this ties back to our direction and vision

Earlier PEAC releases (the 0.9.12 to 0.9.21 window) set the constraints that shaped this article:

• Continue development until earning 1.0 through multiple independent implementations
• Use PEAC-Receipt as the primary HTTP field globally, without legacy header aliases
• Keep the core small and rely on adapters for payment rails and environments
• Always embed AIPREF snapshots in records when present, and make payment optional but normalized across x402 and Stripe

Specific numbers and version windows shift over time. For the current PEAC release, SLOs, and supported wire surfaces, see the PEAC Protocol overview and the downloads and SDK page.

For Originary, this means:

• Agent and crawler identification becomes the front door into a programmable AI paywall
• HTTP 402 becomes the standard control plane for AI payments
• x402 and Stripe are first-class citizens, not competing standards
• PEAC-Receipt is the common language between engineering, finance, partner reviews, and external counterparties

If you are thinking about how to charge AI agents for access, or how to show partners and auditors exactly what those agents did with your data, that is the arc we are building toward. In upcoming posts we will share concrete integration guides and reference implementations for each rail.