How AI Agents Pay for APIs: A Builder's Guide to Agentic Payments

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 and asked you to go sign up, grab a key, and paste it back in. In 2026, it doesn't have to. The agent can discover the service, pay for it, and finish the job — no checkout page, no human approving the charge.

That capability is agentic payments, and it's already running at scale. This is a builder's guide to how it actually works: the protocol underneath it, how an agent holds money, how a single call turns into a settled payment, and how you keep an autonomous spender inside hard limits.

What "agentic payments" actually means

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 sub-cent to few-cent payments, not occasional big ones. Typical calls run roughly $0.001–$0.05 in USDC.
• 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 fifty two-cent payments to forty different merchants in one task.

The building block: HTTP 402

The whole system rests on a status code that sat unused for two decades: HTTP 402 Payment Required. The flow is simple:

1. Your agent requests a resource.
2. The server replies 402 with a payment instruction instead of the data.
3. The agent pays.
4. The agent retries with proof of payment, and the server returns the resource.

No subscription, no account, no prior relationship. Pay-per-call, settled in seconds. (For the protocol-level detail, see the HTTP 402 primer.)

How an agent holds and spends money

An agent pays from a wallet, not a credit card. In practice that means a non-custodial smart wallet funded with stablecoins (commonly USDC). The agent's signer authorizes payments; you stay in control of the 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.

The catch builders hit: there isn't one 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 under the Linux Foundation), USDC-settled on Base and Solana.
• MPP — the Machine Payments Protocol from Stripe and Tempo, multi-rail, settling tempo-native.
• Circle Gateway-batched — batched stablecoin settlement for merchants on Circle's network.
• …and more shipping every quarter (ACP, UCP, AP2, A2A).

Each 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 SELAT makes it one call

SELAT collapses that mess into a single runtime path. Your agent funds one wallet and signs one shape; the SELAT Router handles discovery, credential translation, and settlement across every rail behind the scenes.

A full intent-to-result run looks like this from the terminal:

selat run "search the web for recent papers on agentic payments"

Under the hood, SELAT:

1. Discovers candidate services across federated catalogs and ranks them by how well they match your intent.
2. Prices the chosen service and probes its 402 challenge.
3. Detects the rail automatically and pays — directly when it can, or routed through the Router (which translates rails on the outbound leg) when it must.
4. 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. The four things SELAT does — runtime access, federated discovery, credential translation, settlement orchestration — are exactly the four things that otherwise land on your plate.

Getting started

If you're building a skill that needs to transact, the fastest path is the CLI: install, fund a sandbox wallet, set your spending policy, and send a settled test payment in one session. The SELAT CLI quickstart walks through init → fund → run, and the agentic payments primer covers the concepts in depth.

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. The pattern that makes it sane is skill settlement: 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. If agentic payments are the verb, the settled skill is the noun — and it's the artifact you're actually building toward.

The takeaway for builders: agentic payments aren't a someday feature anymore — they're a thing your agent can do today, in minutes, safely, as long as you don't make it learn every rail by hand. Let it sign once, cap it hard, and route the rest.