Skip to main content
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 — no checkout page, no human approving each charge. This breaks the assumptions of human-centric payments (cards, invoices, monthly billing) and calls for rails that are programmatic, low-value-friendly, and policy-bounded.

​
Why it’s different

  • 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 large ones. Typical SELAT calls run roughly 0.001–0.001–0.05 in USDC.
  • Policy-bounded. Spending caps and per-call budgets stand in for human judgment.
  • Identity is a wallet. An agent authenticates and pays with a wallet/signer, not an account password.
The deeper problem is that existing API access assumes per-user API keys, per-service signup, and bespoke credential storage. That doesn’t compose for an autonomous agent: it can’t sign up for accounts, juggle fifty keys, or contain the fallout when one leaks. Open 402-based payment protocols replace that with pay-per-call settlement — but several rails exist, each with its own signing shape, so a naive agent would have to re-implement all of them.

​
How SELAT fits

SELAT gives agents a single path to discover, price, and pay for services over open payment protocols, so the agent says “find me a thing that does X” and gets a runnable, paid result.

​
Discover and price

SELAT’s discovery is federated across four catalogs — Circle’s x402 catalog, the Agentic Market, the MPP catalog, and Apify. An intent ranker scores candidate services by semantic keyword match, price relative to the cohort (log-scaled), and source-count credibility, with default weights of 0.65 / 0.25 / 0.10.
Payment rails are not scored by default. Discovery surfaces every payment option on the chosen endpoint and lets the payer pick the outbound protocol — so ranking stays about what the service does, not how it gets paid.

​
Pay over open rails

A 402 Payment Required challenge can be satisfied by two paid-rail protocols. Every paid call goes through the SELAT Router, which verifies the inbound Gateway-batched payment and settles the upstream leg — so the agent only ever signs one shape. The router’s outbound leg takes one of two forms:
  • Same-rail passthrough — a Gateway-capable upstream (a GatewayWalletBatched accept on the agent’s chain) is settled over x402 with no cross-protocol translation, currently quoted at par.
  • Cross-protocol — erc-3009 or tempo-native upstreams are translated by the router on the outbound leg (default ~5% markup, included in the live quote).
The two protocols are x402 (the open 402 standard, settled in USDC) and MPP (settled tempo-native). The SDK’s preferProtocol defaults to mpp, with x402 opt-in; a Gateway-capable upstream defaults to x402 same-rail passthrough, and MPP wins otherwise. See x402 and MPP on Tempo for the rail details.

​
End-to-end: intent to result

A single command takes a plain-language intent through discovery, ranking, payment, and response.
1

Express an intent

The agent (or operator) describes what it needs in natural language.
2

Discover and pick

selat run invokes the discovery ranker, picks the top match, and validates the selected execution hint — a selat-pay command for standard picks, or the skill’s prepaid-token runner for Apify picks (which take --input and support --auto-rebuy).
3

Detect the rail and pay

selat-pay probes the upstream, auto-detects the protocol, and pays — choosing the outbound protocol (routed-x402 / routed-mpp / routed-free) without any branching in the agent.
4

Return the response

The upstream’s response body prints on its own (JSON when applicable), ready to pipe into jq, a file, or back into the agent’s reasoning loop.
The same flow is available programmatically — RouterClient.fetch(url, { preferProtocol }) returns the final upstream Response. See RouterClient.

​
Identity, policy, and budgets

Wallet-as-identity in practice. Wallet creation, typed-data signing, and spending limits are delegated to Circle Agent Wallets (user-controlled 2-of-2 MPC) via the Circle CLI. Agents pay without API keys or local private keys — the skill never sees mnemonics or private keys. The SDK also supports a private-key signer or a remote signer object when in-process key handling or custom custody is preferred. USDC settlement runs over Circle Gateway. You fund on 7 EVM chains (arc, base, ethereum, optimism, arbitrum, polygon, avalanche, unichain), and the router settles each merchant on Circle Gateway, Arc, Base, Tempo, or Solana — see Chains. Funding the budget. Every deposit is gasless (the agent wallet’s transactions are gas-sponsored). selat fund makes a direct deposit that settles on the source chain; selat fund --method eco is a fast (~30-second) Eco deposit from Base that always settles into Gateway on Polygon. Hard spending caps. selat setup-policy writes Circle Agent Wallet spending limits — per-transaction, daily, weekly, and monthly (default prompts: 5 / 50 / 200 / 500 USDC). The write is gated by an email OTP, and the code describes it as “the only hard ceiling the agent literally cannot bypass.” Set caps with setup-policy before depositing more than about $20.
The Circle policy is the outer ceiling no payment can exceed. Inside it, every paid call on the CLI/payer path also needs its own per-call price cap: pass --max-amount <usd> to selat skill run. The payer enforces it fail-closed — any quote where price <= cap is false is rejected before signing — so the two caps stack rather than override each other. The SDK does not expose a per-call cap today; SDK payments are bounded only by the Circle wallet policy.

​
Next