That bundling made sense in 2021. It doesn't anymore.

The New Reality: Agents Don't Need Checkout

The fastest-growing use case for stablecoin payments isn't a human buying something. It's an AI agent paying for API access.

An agent doesn't need a checkout page. It doesn't need a hosted UI. It doesn't need currency conversion. It already has USDC in a wallet. It just needs to send the payment and prove it happened.

The entire stack that payment processors offer is irrelevant. What the agent needs is one thing: verification.

"Did this transaction happen? Was the amount correct? Did it land on the right address?"

That's it.

The Hidden Cost of Bundled Processing

Most payment processors charge 0.5–1% per transaction. That sounds small until you run the numbers.

Your agent processes 10,000 API calls per month at $1.00 each. That's $10,000 in volume. At 1%, you're paying $100/month in fees — not to a bank, not for fraud protection, not for anything you actually use. Just for the privilege of using someone else's checkout flow that your agent never sees.

With a verification-only approach, that same volume costs $500. Not $100 per month — $500 total. Flat fee per verification, no percentage, no minimum.

The $0.05 per verification isn't a promotional price. It's what verification actually costs when you strip out everything else.

The Architectural Argument

There's a deeper reason to separate verification from processing, and it's the same reason you don't use a monolith for everything else: separation of concerns.

Payment processors own three things simultaneously:

1. The money flow (custody, settlement)

2. The user experience (checkout, hosted pages)

3. The verification signal ("did this payment succeed?")

When you bundle these, you get lock-in. Your payment success logic is coupled to one provider's infrastructure. Switching processors means rewriting your integration. Changing chains means waiting for the processor to support it.

When you separate verification from the rest, you own your stack. You choose your wallet infrastructure. You choose your settlement path. You choose your chains. The verification layer just watches and reports.

The x402 Signal

The x402 protocol — pioneered by Coinbase, now spreading across AI agent frameworks — makes this separation explicit at the protocol level.

x402 defines a standard for machine payments: server returns HTTP 402, client pays on-chain, client proves payment via transaction hash, server verifies. No checkout. No redirect. No hosted page.

The server's job in this flow is pure verification. And verification doesn't require a processor.

What it requires is an API that can answer: "Did this txHash represent a valid $1.00 USDC transfer to my address on Base, within the last 5 minutes?" That's a $0.05 question, not a 1% question.

What "Non-Custodial" Actually Means

Most crypto payment processors are custodial. They hold the funds between receipt and payout. That's not just a philosophical issue — it's a practical one.

When a processor holds funds:

• You're subject to their payout schedule

• You're subject to their compliance decisions

• You're exposed if they have liquidity problems

• You need to trust their accounting

When you're non-custodial:

• USDC goes directly from the sender to your wallet

• You have it immediately

• No intermediary, no delay, no exposure

PayWatcher never touches the funds. The USDC goes from sender to your deposit address. We watch the blockchain and tell you when it arrived. That's the entire product.

The Right Tool for the Right Job

Payment processors are excellent products for what they do. If you're building an e-commerce checkout where humans enter credit cards, use Stripe. If you need fiat conversion at point of sale, use the right tool for that.

But if you're building:

• An API that AI agents pay to access

• A service that accepts USDC natively

• An x402-compatible endpoint

• Anything where the "user" already has crypto and just needs to send it

…then you don't need a processor. You need verification.

And verification should be cheap, simple, and chainless.

The Practical Test

Before choosing a payment approach, ask these questions:

1. Do your users have USDC already, or do they need to buy it first?

2. Does your integration involve a human filling out a form, or a machine sending a transaction?

3. Are you paying a percentage fee on volume you could keep?

4. Are you locked to one chain because your processor doesn't support others?

If the answers push toward "machine, already has USDC, paying percentage, locked chain" — you're using the wrong tool.

Where This Goes

The stablecoin payment stack is unbundling. Settlement rails, custody, conversion, and verification are separating into specialized layers — the same way databases, caches, and queues separated from the monolith.

Verification is one of those layers. It's boring, it's infrastructure, it should cost almost nothing, and it should work on every chain.

That's what PayWatcher is.

PayWatcher is a USDC payment verification API. $0.05 per verification. Non-custodial. No checkout. Supports Base, Arbitrum, Ethereum, Optimism, and Polygon.

Request access at paywatcher.dev

This article walks through exactly how to implement x402 on your server using PayWatcher as the verification layer.

What is x402?

x402 is an extension of HTTP that brings the long-forgotten 402 Payment Required status code back to life. The flow is simple:

1. Client requests a resource

2. Server responds with HTTP 402 + a payment descriptor (amount, address, chain)

3. Client sends USDC on-chain

4. Client retries the request with the transaction hash

5. Server verifies the payment and returns the resource

The protocol was pioneered by Coinbase and is gaining adoption across AI agent frameworks including MCP servers, Coinbase AgentKit, and custom agent runtimes.

The Verification Problem

The tricky part of x402 is step 5. Your server needs to answer one question:

"Did this transaction actually happen — with the right amount, to the right address, on the right chain?"

You have two options:

Option A: Roll your own — query an RPC node directly, parse ERC-20 Transfer logs, handle confirmations, manage multi-chain RPCs. This takes days, not hours.

Option B: Delegate to PayWatcher — one API call, $0.05 flat, works across Base, Arbitrum, Ethereum, Optimism, and Polygon.

This tutorial uses Option B.

Prerequisites

• A PayWatcher account (request access at paywatcher.dev)

• Your PayWatcher API key

• Your deposit address configured in PayWatcher dashboard

• Node.js + Express (or any HTTP framework)

• The coinbase/x402 npm package (optional but recommended)

Step 1: Set Up Your Express Server

import express from "express"

const app = express()
app.use(express.json())

const PAYWATCHER_API_KEY = process.env.PAYWATCHER_API_KEY!
const DEPOSIT_ADDRESS = process.env.DEPOSIT_ADDRESS!
const RESOURCE_PRICE = "1.00" // $1.00 USDC

Step 2: Return HTTP 402 with Payment Descriptor

When a request comes in without payment, respond with a 402 and tell the client what to pay:

app.get("/api/report/:id", async (req, res) => {
  const paymentHeader = req.headers["x-payment"]

  if (!paymentHeader) {
    // No payment — return 402 with descriptor
    return res.status(402).json({
      scheme: "exact",
      network: "base",
      maxAmountRequired: "1000000", // $1.00 in USDC atomic units (6 decimals)
      resource: req.path,
      description: "Access to report",
      mimeType: "application/json",
      payTo: DEPOSIT_ADDRESS,
      maxTimeoutSeconds: 300,
      asset: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base
      extra: { name: "USDC", version: "2" }
    })
  }

  // Payment header present — verify it
  const { txHash, network } = JSON.parse(paymentHeader as string)
  const verified = await verifyWithPayWatcher(txHash, network)

  if (!verified) {
    return res.status(402).json({ error: "Payment verification failed" })
  }

  // Payment verified — return the resource
  return res.json({ data: await getReport(req.params.id) })
})

Step 3: Verify with PayWatcher

async function verifyWithPayWatcher(
  txHash: string,
  network: string
): Promise<boolean> {
  const response = await fetch("https://api.paywatcher.dev/v1/payments/verify", {
    method: "POST",
    headers: {
      "x-api-key": PAYWATCHER_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      tx_hash: txHash,
      network: network,
      amount: RESOURCE_PRICE,
      to: DEPOSIT_ADDRESS,
      tolerance_seconds: 300,
    }),
  })

  const { data } = await response.json()
  return data.verified === true
}

That's it. Three fields in, one boolean out.

Step 4: Handle retryafterseconds

PayWatcher returns a retry_after_seconds hint when a transaction is found but not yet confirmed:

async function verifyWithPayWatcher(txHash: string, network: string) {
  const response = await fetch("https://api.paywatcher.dev/v1/payments/verify", {
    method: "POST",
    headers: {
      "x-api-key": PAYWATCHER_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      tx_hash: txHash,
      network: network,
      amount: RESOURCE_PRICE,
      to: DEPOSIT_ADDRESS,
    }),
  })

  const { data } = await response.json()

  if (!data.verified && data.retry_after_seconds) {
    // Transaction found but not confirmed yet — tell the client to retry
    return {
      verified: false,
      retryAfter: data.retry_after_seconds,
      reason: data.reason,
    }
  }

  return { verified: data.verified, retryAfter: null, reason: data.reason }
}

Return a Retry-After header so the agent knows when to try again:

if (!result.verified && result.retryAfter) {
  return res
    .status(402)
    .set("Retry-After", String(result.retryAfter))
    .json({ error: "Payment pending confirmation", reason: result.reason })
}

Step 5: Use PayWatcher's x402 Descriptor (Optional)

If you want PayWatcher to generate the exact x402 descriptor for you — including the correct USDC contract address per chain and amount in atomic units — add x402: true to your payment intent:

const intentResponse = await fetch("https://api.paywatcher.dev/v1/payments", {
  method: "POST",
  headers: {
    "x-api-key": PAYWATCHER_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    amount: RESOURCE_PRICE,
    network: "base",
    x402: true,
  }),
})

const { data } = await intentResponse.json()

// Return the pre-built x402 descriptor directly
return res.status(402).json(data.x402)

This is the easiest path if you want multi-chain support without hardcoding contract addresses per network.

Complete Flow

Client                    Your Server              PayWatcher
  │                           │                        │
  │── GET /api/report/42 ────>│                        │
  │<─ 402 + descriptor ───────│                        │
  │                           │                        │
  │  [sends USDC on-chain]    │                        │
  │                           │                        │
  │── GET /api/report/42 ────>│                        │
  │   x-payment: {txHash}     │                        │
  │                           │── POST /verify ───────>│
  │                           │<─ { verified: true } ──│
  │<─ 200 + data ─────────────│                        │

Supported Chains

PayWatcher verifies USDC payments on:

Same API call, same $0.05 fee, regardless of chain.

What You Get

• No RPC infrastructure — PayWatcher handles all blockchain queries

• Multi-chain out of the box — change network in your request, nothing else

• Replay attack protection — tolerance_seconds rejects old transactions

• Confirmation guarantees — PayWatcher waits for chain-specific required confirmations before returning verified: true

• $0.05 flat — not 0.5–1% of the transaction value

Next Steps

• Get access at paywatcher.dev

• Read the full API reference in the docs

• Questions? hello@paywatcher.dev

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:

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.

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.

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.

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.

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.

You want to accept a $10,000 USDC payment. You have two options:

Option A: Integrate a payment processor like Coinbase Commerce. Set up an account, embed their checkout widget, handle their SDK. Pay $100 in fees (1%).

Option B: Build your own blockchain listener. Learn ethers.js, subscribe to USDC transfer events, handle reorgs, confirmations, edge cases. Two weeks of work, minimum.

There's no middle ground. No service that just tells you: "Yes, this specific payment arrived."

Until now.

What If Verification Was a Simple API Call?

PayWatcher is a verification layer for stablecoin payments on Base. It doesn't process payments. It doesn't touch your funds. It doesn't require a checkout flow.

You tell it what payment you expect. It watches the blockchain. When the payment arrives, you get a webhook.

That's it.

Here's the cost comparison for verifying a $10,000 USDC transfer:

The fee is the same whether you're verifying $1 or $1,000,000.

How It Works (3 Steps)

Step 1: Create a Payment Intent

Tell PayWatcher what payment you're expecting:

bash

curl -X POST https://api.paywatcher.dev/v1/payments \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": "10000.00",
    "token": "USDC",
    "network": "base",
    "recipient": "0xYourWalletAddress",
    "webhook_url": "https://yourapp.com/webhook/payment",
    "reference": "invoice-2026-001"
  }'

Response:

json

{
  "id": "pay_abc123",
  "status": "watching",
  "unique_amount": "10000.03",
  "expires_at": "2026-02-23T12:00:00Z"
}

Notice the unique_amount? PayWatcher adds a few cents to make your payment uniquely identifiable on-chain. Your customer sends $10,000.03 instead of $10,000.00 — and that tiny difference is how we match the exact transfer to your intent.

Step 2: Your Customer Sends USDC

Your customer sends USDC directly to your wallet. No checkout page, no intermediary, no redirect. Just a standard USDC transfer on Base.

You keep 100% of the payment. PayWatcher never has custody.

Step 3: Get Notified

When the transfer is confirmed on Base, PayWatcher fires a webhook:

json

{
  "event": "payment.confirmed",
  "payment_id": "pay_abc123",
  "reference": "invoice-2026-001",
  "amount": "10000.03",
  "token": "USDC",
  "network": "base",
  "tx_hash": "0xabc...def",
  "confirmed_at": "2026-02-22T10:30:00Z"
}

Your backend processes the webhook, marks the invoice as paid, and you're done. No polling, no manual checking on Basescan.

JavaScript Example

Here's a minimal Node.js integration:

javascript

// Create a payment intent
const response = await fetch('https://api.paywatcher.dev/v1/payments', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.PAYWATCHER_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    amount: '500.00',
    token: 'USDC',
    network: 'base',
    recipient: '0xYourWallet',
    webhook_url: 'https://yourapp.com/api/webhook',
    reference: `order-${orderId}`
  })
});

const payment = await response.json();
// Show payment.unique_amount to your customer

And the webhook handler:

javascript

// Express webhook endpoint
app.post('/api/webhook', (req, res) => {
  const { event, reference, amount, tx_hash } = req.body;

  if (event === 'payment.confirmed') {
    // Mark order as paid
    await db.orders.update({
      where: { reference },
      data: { status: 'paid', tx_hash }
    });
  }

  res.status(200).send('ok');
});

Test Your Integration Without Sending Real USDC

Before going live, you can verify your webhook handler works correctly using the built-in test endpoint:

bash

curl -X POST https://api.masem.at/v1/paywatcher/config/test-webhook \
  -H "x-api-key: YOUR_API_KEY"

PayWatcher sends a signed dummy payload to your configured webhook_url:

json

{
  "event": "payment.test",
  "payment_id": "test_abc123",
  "timestamp": "2026-02-17T10:00:00Z",
  "data": {
    "amount": "1.00",
    "exact_amount": "1.000000",
    "currency": "USDC",
    "chain": "base",
    "tx_hash": null,
    "confirmations": 0
  }
}

The payload is signed with HMAC-SHA256 via the x-paywatcher-signature header — same mechanism as real payments. If your handler processes payment.test correctly, it will process payment.confirmed correctly too.

No real USDC. No blockchain transaction. Full signature verification.

When to Use PayWatcher (and When Not To)

Use PayWatcher when:

• You accept USDC payments and want automatic confirmation

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

• You need a non-custodial solution (regulatory, preference, or principle)

• You want webhook notifications instead of polling Basescan

• You're building on Base

Don't use PayWatcher when:

• You need fiat on/off ramps (use Coinbase Commerce or Stripe)

• You need multi-currency checkout flows

• You want a hosted payment page (PayWatcher is API-only)

PayWatcher is verification, not processing. We don't hold, transfer, or have custody of funds.

What's Unique About This Approach?

Most crypto payment solutions are trying to be the next Stripe for crypto — full checkout flows, currency conversion, custody, settlement. That's valuable for some use cases.

But if you're already comfortable with USDC on Base, you don't need all that. You need someone to watch the blockchain and tell you when money arrived. That's a fundamentally different service, and it should be priced differently.

A flat $0.05 per verification instead of a percentage of the transaction value.

Architecture Overview

Your App                    PayWatcher                  Base Network
   │                            │                            │
   ├── POST /v1/payments ──────►│                            │
   │   (create intent)          │                            │
   │◄── { unique_amount } ──────┤                            │
   │                            │                            │
   │   Show amount to customer  │                            │
   │                            │                            │
   │                            │◄── Monitor USDC transfers ─┤
   │                            │    (event listener)        │
   │                            │                            │
   │                            │── Match transfer to intent │
   │                            │── Wait for confirmations   │
   │                            │                            │
   │◄── Webhook: confirmed ─────┤                            │
   │                            │                            │
   └── Process payment          │                            │

PayWatcher sits between your application and the blockchain. It handles the complexity of monitoring transfers, matching amounts, waiting for confirmations, and handling edge cases like reorgs — so you don't have to.

Try It

PayWatcher is live on Base. We're onboarding early testers now.

Free tier: 50 verifications/month — enough to test and validate your integration.

→ Request API Access → Read the Docs

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

Questions? Reach out on Farcaster or X.