Your agent is mid-task. It needs a piece of paid data, a model call, or an API it doesn't already have a key for. A year ago that's where it stopped: a paywall, and a human asked to go sign up, grab a key, and paste it back in. In 2026 you can let an autonomous agent handle that moment itself. AI agents pay for APIs by answering an HTTP 402 Payment Required challenge and settling in USDC from a wallet the operator controls — no checkout page, no human approving each charge.
That capability is agentic payments. The protocols are live. This is a builder's guide to how it actually works: what "getting past a paywall" really means for an agent, the HTTP 402 challenge, how an agent holds money in a Circle Agent Wallet, how a single call turns into a settled payment, and how you keep an autonomous spender inside hard spending caps.
Can an autonomous agent bypass a paywall?
Not by sneaking around it. The honest answer is better: it pays the paywall, automatically. There are two kinds of paywall on today's internet, and the distinction is the first thing to internalize:
- Human paywalls — subscription and login walls in front of content, built for people with accounts and browsers. Agents should not circumvent these, and SELAT does not.
- Machine-payable paywalls —
HTTP 402 Payment Requiredchallenges in front of APIs, data, and services, designed from the start to be paid by software at request time.
For the second kind, "bypassing the paywall" just means paying it in-flight: the agent hits the wall, reads the price, pays it, and retries with proof of payment. Nothing is circumvented. The merchant gets paid, the agent gets the resource, and the task keeps moving with no human in the loop. The rest of this guide is how to set that up.
What are agentic payments?
Agentic payments are payments initiated and settled by software agents rather than people. When an AI agent needs data, compute, or an API call mid-task, it pays for that resource autonomously.
That breaks every assumption built into human payments:
- Machine-to-machine. No browser, no human in the loop per transaction.
- High-frequency, low-value. Many micropayments, not occasional big ones. Published x402 catalogs often quote well under a dollar per call; treat live
402quotes as the price, not a blog range. - Policy-bounded. Spending caps and per-call budgets stand in for human judgment.
- Identity is a wallet. The agent authenticates and pays with a wallet and signer, not an account password.
Cards, invoices, and monthly billing simply don't fit a thing that wants to make dozens of small payments to many different merchants in one task.
How does an HTTP 402 paywall work?
The whole system rests on a status code reserved since HTTP/1.1 and left unused for decades: HTTP 402 Payment Required. The flow is simple:
- Your agent requests a resource.
- The server replies
402with a payment instruction instead of the data. - The agent pays.
- The agent retries with proof of payment, and the server returns the resource.
No subscription, no account, no prior relationship. Pay-per-call. Settlement time depends on the rail (on-chain USDC versus a session or card method); the important property is that payment is part of the HTTP exchange, not a separate checkout.
How does an agent hold and spend money?
An agent pays from a wallet, not a credit card. In practice that means a self-custody Circle Agent Wallet funded with USDC. The operator funds Circle Gateway; the agent's signer authorizes payments; you stay in control of the funds. SELAT never holds keys or funds.
The important part for anyone nervous about handing money to an autonomous process: spending limits are enforced, not suggested. A well-built setup writes hard caps — per-transaction, daily, weekly, monthly — that the agent literally cannot exceed, plus a per-call price cap so any quote above your ceiling is rejected before it's ever signed. The agent operates freely inside the box; it can't spend its way out of it.
Why isn't there one payment rail?
Here's where it gets messy. HTTP 402 standardized the challenge — "you must pay" — but not what happens below it. Different merchants settle over different rails:
- x402 — the open standard from Coinbase, now stewarded by the x402 Foundation under the Linux Foundation. Primarily USDC on-chain (Base and Solana are the two most-used settlement networks; other chains exist).
- MPP — the Machine Payments Protocol, co-authored by Stripe and Tempo. Multi-rail: Tempo stablecoins, Stripe cards, and extensible custom methods. See x402 vs MPP.
- Circle Gateway — batched, gas-free USDC settlement used for high-frequency nanopayments, often with x402-compatible services. It is a settlement layer, not a third HTTP-402 dialect.
- Adjacent commerce protocols (ACP, UCP, AP2) and agent-to-agent messaging (A2A) keep shipping around the same problem.
Each payment rail has its own signing shape, its own credentials, its own liquidity. An agent that wants to pay any merchant has to re-implement all of them — and re-implement the next one when it lands. That's the integration tax, and it's the real reason "agents can pay" hasn't yet meant "agents can pay anywhere."
How does SELAT make it one call?
SELAT collapses that mess into a single runtime path. Discover a paid capability, fund Circle Gateway, and pay USDC from the user's Circle Agent Wallet. You sign one shape; SELAT handles discovery, rail detection, and settlement. SELAT never holds keys or funds.
A full intent-to-result run looks like this from the terminal:
selat run "search the web for recent papers on agentic payments"
selat run spends unless you pass --dry-run. Under the hood, SELAT:
- Discovers candidate services across federated catalogs and ranks them by how well they match your intent.
- Prices the chosen service and probes its
402challenge. - Detects the rail and pays — from the Circle Agent Wallet, directly when it can, or routed when it must.
- Returns the upstream response, ready to pipe back into the agent's reasoning loop.
You never branch on protocol. You never hold a key per merchant. Hosted discovery at https://catalog.selat.ai/mcp is search and quotes only — it cannot spend. Spend stays on the local runner.
How do you get started?
If you're building a skill that needs to transact, the fastest path is the CLI: selat init (Circle Agent Wallet), selat fund (Circle Gateway), set spending policy, then selat run — or selat run --dry-run to quote without paying. Plugins install into Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, and Hermes; start from llms.txt.
One thing worth internalizing early: a single paid call is the unit of the protocol, not of the work. Real agent tasks run as skills — multi-step workflows that chain several paid endpoints, often across different rails, in one execution. That is cross-rail composition: every endpoint the skill calls is paid merchant-direct, at its live quote, on its own rail, and every one of those calls draws on the same self-custody balance, under the same caps, reconciling into the same ledger. Agentic payments are the verb; this — every call in a run settled from one balance — is what you're actually building toward.
The takeaway for builders: agentic payments aren't a someday feature — they're a thing your agent can do today, as long as you don't make it learn every rail by hand. Let it sign once, cap it hard, and route the rest. For the problem-side view of the same territory, see why AI agents break the moment a task needs payment.
FAQ
How do AI agents pay for APIs?
They request the resource, receive HTTP 402 Payment Required with a payment instruction, settle (commonly USDC), and retry with proof of payment. No API key, no checkout page, no human per charge.
Can AI agents bypass paywalls automatically?
They pay them automatically, which is the version that actually works. An HTTP 402 paywall is machine-payable by design: challenge, pay, retry, data. Human subscription and login paywalls are a different thing, and SELAT does not circumvent them.
How do I let an agent spend autonomously without losing control?
Set hard caps before the first paid call: per-transaction, per-session, daily, weekly, and monthly limits, enforced in the settlement path rather than in a prompt. Quote first with selat run --dry-run, and treat the caps and each live quote as the approval boundary.
What is HTTP 402 Payment Required?
A status code reserved in HTTP for "payment required" and unused for decades. x402 and MPP both use it as the challenge: the server withholds the resource until the client pays.
What is a Circle Agent Wallet in this flow?
The self-custody wallet the operator funds. USDC is deposited into Circle Gateway; payments are signed from that wallet. SELAT never holds the keys or the funds.
Does selat run spend money?
Yes. selat run discovers, quotes, then pays. Pass --dry-run to quote without paying. The hosted discovery MCP cannot move funds.