HTTP has had a status code sitting unused for 30 years.

402: Payment Required.

It was reserved for a future where machines could pay for things directly. That future is here. Stripe and Coinbase are both building around x402 — a protocol that revives 402 to enable AI agents to pay for API calls in USDC, automatically, without a human in the loop.

An AI agent requests a resource. The server responds with 402. The agent pays in USDC. Access is granted. No checkout page. No credit card. No human approval.

This is what machine-to-machine payments look like.

Everyone is focused on the rails. Stripe built the payment layer. Coinbase built the protocol. A16z, Galaxy, Outlier Ventures are all writing theses about agentic payments.

But there's a step everyone is glossing over.

How does the server know the payment actually arrived?

An agent sends 0.01 USDC to your wallet on Base. Your server needs to:

1. Detect the transfer happened

2. Match it to the specific request

3. Confirm it's not a reorg

4. Wait for enough block confirmations

5. Grant access

If you build this yourself, you're looking at subscribing to USDC transfer events via ethers.js, handling edge cases like chain reorgs, managing confirmation thresholds, building retry logic for missed events. Two weeks of work, minimum — and that's if you've done it before.

If you use a payment processor, you're paying 0.5–1% per transaction. On $0.01 micropayments, that's a fee larger than the payment itself.

The verification layer for x402 doesn't exist yet. That's the gap.

The x402 protocol defines the payment flow beautifully:

Agent → GET /api/resource
Server → 402 Payment Required
        { "accepts": [{ "scheme": "exact", "network": "base", 
          "maxAmountRequired": "1000", "asset": "USDC",
          "payTo": "0xYourWallet" }] }
Agent → Pays USDC on Base
Agent → GET /api/resource (with payment proof)
Server → 200 OK

Clean. Elegant. Stateless.

But that last step — "Server verifies payment proof" — assumes your server can confirm the transfer actually happened on-chain. In practice, that means you need:

• A blockchain listener watching your wallet

• Amount matching logic (how do you distinguish two 0.01 USDC payments in the same block?)

• Confirmation waiting (Base finalizes fast, but you still need to handle reorgs)

• A webhook or callback system to notify your application

That's infrastructure. Non-trivial infrastructure.

This is exactly what PayWatcher is built for.

You create a Payment Intent before the agent pays. PayWatcher gives back a unique_amount — a slightly adjusted figure (e.g., $0.0103 instead of $0.01) that makes the payment uniquely identifiable on-chain.

bash

POST https://api.paywatcher.dev/v1/payments
{
  "amount": "0.01",
  "token": "USDC",
  "network": "base",
  "recipient": "0xYourWallet",
  "webhook_url": "https://yourapi.com/webhook/payment",
  "reference": "agent-request-abc123"
}

Response:

json

{
  "id": "pay_xyz789",
  "status": "watching",
  "unique_amount": "0.0103",
  "expires_at": "2026-03-16T15:00:00Z"
}

You give the agent unique_amount as the amount to pay. When the transfer hits Base, PayWatcher fires a webhook:

json

{
  "event": "payment.confirmed",
  "payment_id": "pay_xyz789",
  "reference": "agent-request-abc123",
  "amount": "0.0103",
  "token": "USDC",
  "network": "base",
  "tx_hash": "0xabc...def",
  "confirmed_at": "2026-03-16T14:47:22Z"
}

Your server grants access. Done.

$0.05 flat fee. No percentage. No custody. No checkout.

Agent → GET /api/resource
Server → 402 + PayWatcher unique_amount
Agent → Sends USDC to your wallet
PayWatcher → Detects transfer on Base
PayWatcher → Fires webhook to your server
Server → Grants access
Agent → GET /api/resource (authorized)
Server → 200 OK

Your server never touches the funds. PayWatcher never touches the funds. The agent pays directly to your wallet.

Percentage fees break at micropayment scale.

For high-value payments, flat fee wins decisively. For true micropayments under $0.05, neither model works well — but that's a Base gas cost problem, not a PayWatcher problem.

The sweet spot for PayWatcher is $1–$10,000+ payments where you want automatic verification without giving up 0.5–1%.

Build with PayWatcher if you:

• Accept USDC payments on Base and want automatic confirmation

• Are building x402-compatible APIs that AI agents will call

• Don't want to give up 0.5–1% per transaction

• Want webhook notifications instead of polling Basescan

• Need non-custodial verification (regulatory, preference, or principle)

Don't use PayWatcher if you:

• Need fiat on/off ramps

• Need a hosted checkout page

• Need multi-currency support

• Are transacting under $0.05 per payment (the fee exceeds the payment)

PayWatcher is live on Base. Free tier: 50 verifications/month — enough to build and test your x402 integration.

→ Get API Key → Read the Docs

Built by masemIT — we also build ChainSights, identity-first analytics for DAOs.

Questions? Reach out on Farcaster or X.