Anchor Browser × Coinbase x402: Agents That Can Pay

TL;DR
Anchor Browser now supports Coinbase’s x402—an HTTP-native payments protocol using USDC—so agents can pay for web resources and be triggered via payment (spin up a browser agent when a valid x402 payment arrives). This removes one of the biggest access bottlenecks for autonomous agents: payments.

Why this matters

Over the last year, agents have gone from demo toys to real SaaS workloads. The limiting factor has shifted from “can the model reason?” to “can the agent access the thing it needs?”—auth, rate limits, and especially paywalls. x402 revives HTTP 402 (“Payment Required”) to let clients—human or agent—pay on demand over HTTP with stablecoins like USDC, enabling fine-grained, per-request access without accounts or custom billing rails.

What we’re shipping

• Paywall access for agents
  Anchor browser agents can complete an x402 challenge, settle payment, and retry the request to retrieve the protected resource—programmatically, at request time.

• Payment-triggered sessions
  You can expose an endpoint where a successful x402 payment spins up a new browser agent with a predefined policy (target URL, credentials vault scope, time/credit caps). This is our glue on top of the x402 flow (payment → verification → action). (Flow mechanics per x402 docs.)

How x402 works

1. Client requests a resource.

2. Server replies 402 Payment Required with payment terms.

3. Client pays (USDC) and resubmits with the payment payload/header.

4. Server verifies (locally or via the x402 Facilitator) and returns the resource.

Under the hood, Coinbase provides a managed Facilitator so you don’t need to run chain infra; the protocol is network-agnostic with published network/token support.

What this unlocks

• Metered data/API access: pay-per-document, per-API call, or per minute of computation—no keys or subscriptions.

• Agent-to-agent workflows: one agent can fund and trigger another, safely and predictably, using standard HTTP.

• Lower ops & compliance burden: Coinbase’s managed flow includes KYT/OFAC screening and reporting dashboards for sellers.

Developer experience

• One policy, many agents: define how an agent may spend (cap, allowlist of paywalled origins).

• Retry-with-payment built into agent runtime: detect 402 → authorize → retry (mirrors x402 buyer quickstart).

• Webhook/handler on your side to translate a verified payment into an agent launch (session config, secrets scope).

  
  

import os, json, requests
from eth_account import Account
from x402.clients.requests import x402_requests

ENDPOINT = "https://api.anchorbrowser.io/v1/sessions"
BODY = {}

key = os.getenv("PRIVATE_KEY") or exit("Set PRIVATE_KEY=0x...")
pre = requests.post(ENDPOINT, json=BODY, timeout=30)
if pre.status_code == 200:
    print(json.dumps(pre.json(), indent=2))
    exit()

price = int(pre.json()["accepts"][0]["maxAmountRequired"])

res = x402_requests(Account.from_key(key)).post(ENDPOINT, json=BODY, timeout=60)
print(json.dumps(res.json(), indent=2))

Follow the more detailed instructions here - Technical documentation

Getting started

• If you sell data/APIs: add x402 to your endpoints (start on testnet; promote to mainnet).

• If you run agents: enable x402 in your Anchor project and set spend policies; your agents will automatically recognize 402 challenges and pay/retry.

Looking ahead

As agents become first-class web users, identity + policy + payments will be table stakes. With x402, payments become a standard HTTP round-trip—and with Anchor, your agents get it as a native capability.