Mario Semper

Posted on Mar 17

How AI Agents Pay for API Calls — And How to Verify They Did

#web3 #javascript #blockchain #api

The x402 protocol just made machine-to-machine payments real. Here's what the verification layer looks like.

PayWatcher · March 2026 · 4 min read

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.

The Problem Nobody Is Talking About

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:

Detect the transfer happened
Match it to the specific request
Confirm it's not a reorg
Wait for enough block confirmations
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.

What x402 Assumes You Already Have

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.

The Verification Layer

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.

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:

{
  "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:

{
  "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.

The Full x402 + PayWatcher Flow

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.

Why Flat Fee Matters for Micropayments

Percentage fees break at micropayment scale.

Payment Size	Coinbase Commerce (1%)	PayWatcher ($0.05 flat)
$0.01	$0.0001 ✓ (but min fees apply)	$0.05 ✗ too expensive
$0.10	$0.001	$0.05
$1.00	$0.01	$0.05
$10.00	$0.10	$0.05 ✓
$100.00	$1.00	$0.05 ✓
$10,000.00	$100.00	$0.05 ✓✓✓

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

Who This Is For

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)

Try It

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.

DEV Community