Technical Deep Dive

From Detection To Settlement: Using PEAC To Turn AI Traffic Into Revenue And Compliance

How Originary and PEAC Protocol turn AI bot detection into an AI paywall using HTTP 402, x402 and Stripe - with signed receipts for billing, audit and compliance.

Jithin Raj & Originary Team|18 min read

In This Article

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

2HTTP 402 and the rise of the AI paywall

3The PEAC flow: from detection to 402 to receipt

4Concrete flows across x402 and Stripe

5What actually ends up in a PEAC-Receipt

6How this ties back to our roadmap and vision

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.

At Originary, PEAC Protocol is our answer to the next step in that story:

You detect AI bot traffic
You apply an AI paywall with HTTP 402
You settle payments over x402 or Stripe
You get a signed PEAC-Receipt for every access event, ready for billing, audit and disputes

From “is this a bot” to “this bot paid under these terms”

In the previous piece on AI bot detection 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 dispute

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

Detection tells you “there is an AI here”. PEAC tells you “this AI agreed to these terms, paid in this way, and here is the signed evidence”.

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 as “reserved for future use”. There was no standard way to use it, so most products ignored it. That is changing:

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 ship 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 roadmap is explicit: the protocol is a universal proof layer that completes existing payment rails rather than competes with them.

PEAC 0.9.12Generic 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.13Economic layer

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

PEAC 0.9.14Reporting and standards hooks

Compliance reports built on top of receipts
Internet Draft v00 for open standards process

Integrate PEAC once. Use whichever AI payment rails you want behind the scenes. Always get the same kind of signed PEAC-Receipt back.

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

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

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 receipts, and which public keys to trust.

Evaluate

The PEAC kernel merges your AIPREF policy, resource level rules, and any caller identity into a decision: allow, allow with payment, or deny.

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.

Settle on the chosen rail

The AI agent uses the x402 or Stripe adapter flow to pay and obtain a proof.

Prove with PEAC-Receipt

When the client retries, the PEAC kernel verifies the payment proof, recomputes the policy hash, issues a signed receipt, and sends the resource back with a PEAC-Receipt header.

Receipts 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.

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 receipts.

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.

Note: The exact header used to relay Stripe payment intent IDs may change as we tighten the adapter spec, but the normalized payment block shape and use of PEAC-Receipt remain stable across versions.

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 receipt 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..."
  }
}

policy_hash + aipref_snapshotTell you exactly what rules were in force when this AI paywall was applied

resourceTies things to a concrete path and ETag

paymentUniform across x402 and Stripe - only the rail and reference semantics differ

proofBinds 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.

How this ties back to our roadmap and vision

Within the 0.9.12 to 0.9.21 window, we have set some clear constraints:

Stay on 0.9.x until we earn 1.0 through an IETF draft and 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 receipts when present, and make payment optional but normalized across x402 and Stripe

Our performance and security targets are explicit:

< 10 ms

Sign p95

< 5 ms

Verify p95

1k+ receipts/sec

Throughput

OWASP clean

Security

Make PEAC the universal proof layer for AI interactions, so that any rail that can clear a payment can plug into AI paywalls and still produce verifiable, portable receipts.

For Originary, this means:

AI bot detection 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, legal and external partners

If you are thinking about how to charge AI agents for access, or how to show regulators 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.

Ready to monetize AI traffic with verifiable receipts?

Learn how Originary and PEAC Protocol turn AI detection into AI paywalls with x402 and Stripe support.

View Documentation Talk to Us