How do AI agents pay for things?

An AI agent pays by signing a transaction from a wallet it controls, most often settling in a stablecoin like USDC so it can pay small amounts per request. A payment standard — x402, Google's AP2, or Visa's TAP — defines how the agent proves it's authorized to buy before the funds move. Responsible setups bound that wallet with spend limits and scoped permissions.

Why do AI agents pay in stablecoins instead of dollars or cards?

Stablecoins like USDC keep the amount predictable and settle on low-fee chains, which makes per-request micropayments — fractions of a cent, thousands of times — economically viable. Cards and bank rails carry per-transaction overhead and require accounts, which doesn't fit machine-to-machine spending. That said, standards like AP2 and Visa's TAP are bridging agents back into card rails too, so it isn't strictly either-or.

What's the difference between x402, Google AP2, and Visa TAP?

They solve different parts of the problem. x402 is an open, crypto-native rail for paying per HTTP request in stablecoins. Google's AP2 is an authorization framework using signed mandates (verifiable credentials) across cards and crypto. Visa's TAP adds cryptographic agent identity onto existing card rails. They may end up layered rather than mutually exclusive — but for now they're competing standards with no settled winner.

Is there a single standard for AI agent payments yet?

No. As of 2026 there are at least three serious contenders — x402, Google's AP2, and Visa's Trusted Agent Protocol — each backed by major players and optimized for a different job. Anyone calling one "the standard" is making a claim the market hasn't confirmed. Building on one today means accepting some lock-in, so weigh which ecosystem fits your agent before wiring it in.

Is it safe to let an agent pay autonomously?

The payment standard defines how money moves, not how to bound risk — that's on the wallet setup. An agent paying on its own should use spend limits, scoped permissions, and policy-controlled signing so a single bug or prompt injection can't drain it. Treat any "safe" or "verified" framing as a claim until the wallet controls and on-chain behavior show it. See how agents use wallets.

← Back to wiki

How Do AI Agents Pay?

Last updated 2026-06-24

AI agents pay by signing transactions from their own wallet — usually in stablecoins for per-request micropayments — through one of several competing standards (x402, Google's AP2, Visa's Trusted Agent Protocol) that define how an agent proves what it's allowed to buy and settles the bill.

Key takeaways

▸Agents pay by signing from their own [wallet](/wiki/how-agents-use-wallets) — the defining trait of an [onchain agent](/wiki/what-are-onchain-agents), not a chatbot that describes crypto.
▸**Stablecoins** (USDC) are the common settlement asset because predictable value plus low fees make sub-cent **micropayments** practical per API call.
▸Three standards are competing, not converging: **x402** (open, per-request), **Google AP2** (signed mandates across payment types), and **Visa TAP** (agent identity for card rails).
▸Each solves a different problem: x402 optimizes for permissionless machine-to-machine micropayments; AP2 and TAP optimize for authorization, identity, and fitting agents into existing commerce.
▸Which standard wins is unsettled — building on one today is a bet. Treat "the standard for agent payments" claims as claimed, not shown, and check the [Sato Score](/sato-score) for transparency signals.

An AI agent pays by signing a transaction from a wallet it controls, most often settling in a stablecoin like USDC so it can pay tiny amounts per request instead of holding a credit card or a monthly subscription. Strip away the branding and every approach has the same three parts: a wallet that can sign safely, a unit of value to send (usually a stablecoin), and a standard that defines how the agent proves *what it's authorized to buy* before the money moves.

That last part is where the fight is. There is no single agreed way for agents to pay yet — instead there's a three-way contest between x402 (open, crypto-native, pay-per-HTTP-request), Google's Agent Payments Protocol (AP2) (signed mandates across cards and crypto), and Visa's Trusted Agent Protocol (TAP) (agent identity layered onto existing card rails). This page maps the landscape: the building blocks first, then each standard and its primary source, then how to read a race that isn't over. For the deep dive on one contender, see what is x402.

Why It Matters

An agent that can reason but can't pay has to stop and ask a human to sign up, enter a card, and manage an API key for every service it touches — which breaks autonomy at the most basic level. Payments are the rail that turns an agent from a tool that *suggests* actions into one that *transacts*: buying data, compute, or another agent's output on demand, and getting paid for its own. For a builder, the choice of payment standard is load-bearing — it decides which providers your agent can buy from, how authorization and spend limits work, and how much you're locked to one ecosystem. Picking wrong is expensive to unwind, so it's worth understanding the field before you wire one in. See the [payments use case](/use-cases/payments) for where this plugs into a real stack.

How It Works

▸The agent holds a **wallet** with scoped permissions and spend limits — often a policy-controlled signer or embedded wallet rather than a raw private key (see [how agents use wallets](/wiki/how-agents-use-wallets)).
▸When it needs to buy something, the agent discovers the price and the seller's terms — over an HTTP response, a merchant endpoint, or a payment mandate, depending on the standard.
▸The agent proves it's **authorized** to make the purchase: signing a payment authorization (x402), presenting a signed mandate (AP2), or attaching a signed identity to the request (TAP).
▸Settlement happens in the chosen asset — a stablecoin transfer onchain for crypto-native flows, or a card/bank rail for the card-network approaches.
▸A verifier (a facilitator, a payment processor, or the merchant) checks the proof and the funds before releasing the goods or service.
▸The agent gets the result and moves on — metered per request, so it pays only for what it actually used.

Key Components

•A policy-controlled wallet that can sign payments with spend limits
•A settlement asset — usually a stablecoin (USDC) for crypto-native flows
•An authorization layer (signed payment, mandate, or agent identity)
•A payment standard that defines the request-and-pay handshake
•A verifier or facilitator that checks the proof before settling
•A settlement rail (a low-fee chain like Base or Solana, or a card network)
•Guardrails: spend caps, scoped permissions, human-approval for big spends

The building blocks: wallets, stablecoins, micropayments

Before any standard, three primitives make agent payments work at all.

▸Wallets. An agent pays by controlling keys. Production setups almost never hand an agent a raw private key — they use embedded wallets or policy-controlled signers with spend limits and scoped permissions, frequently built on account abstraction (ERC-4337). The wallet is the part that decides whether a bad instruction can drain the account. Full detail on how agents use wallets.
▸Stablecoins. Agents settle in stablecoins like USDC because the value is predictable — a $0.01 call costs $0.01, not "$0.01 worth of a token that moved 8% mid-request." That predictability is what makes machine-to-machine pricing legible.
▸Micropayments. The killer use isn't buying a $40 product; it's paying a fraction of a cent per API call, thousands of times. That only works when the settlement fee is also tiny, which is why crypto-native flows run on low-fee chains like Base and Solana.

Put together: a wallet that can sign, a stablecoin to send, and fees low enough that paying per request makes economic sense. The standards layer sits on top, defining how the agent proves it's *allowed* to spend.

x402: pay-per-request over HTTP (open, crypto-native)

x402 revives the long-dormant HTTP `402 Payment Required` status code and wires it to onchain settlement. An agent requests a priced endpoint; the server answers 402 with machine-readable terms (amount, token, chain, address); the agent's wallet signs a USDC payment and retries; a facilitator verifies and settles before the content is served. No account, no API key, no human per call.

The clearest live example: 0x opened its Swap API to AI agents at $0.01 per request in USDC over x402, built on Alchemy's AgentPay (The Defiant). The standard and reference implementation are documented at x402.org, and Alchemy walks through the mechanics. Per SatoHub's evidence rule: integrations like 0x are *shown*; broad "x402 is everywhere" volume claims are still mostly self-reported, so treat them as *claimed* until the on-chain data backs them. Deep dive on the x402 resource page and the what is x402 explainer.

Google's AP2: signed mandates across cards and crypto

Where x402 is a per-request rail, Google's Agent Payments Protocol (AP2) is an authorization framework. Announced September 2025 with 60+ launch partners including Mastercard, PayPal, Coinbase, and American Express, AP2 is an open spec for proving that an agent has a user's permission to transact (Google Cloud).

Its core idea is the Mandate — a cryptographically signed, tamper-evident contract carried as a W3C Verifiable Credential. AP2 defines three: an Intent Mandate (what the user authorized), a Cart Mandate (the specific items and price), and a Payment Mandate (the actual charge). Critically, AP2 treats stablecoins as a first-class payment type alongside cards and bank transfers — so it's not crypto-versus-cards, it's a wrapper that spans both. The full specification lives in Google's public repo at github.com/google-agentic-commerce/AP2. Track it on the AP2 resource page. The thing AP2 optimizes for that x402 doesn't: a verifiable chain of *who authorized what*, which matters when a charge is disputed.

Visa's Trusted Agent Protocol: identity for existing rails

Visa's Trusted Agent Protocol (TAP), announced October 2025 with Cloudflare and a dozen launch partners including Coinbase, Stripe, Shopify, and Microsoft, comes at the problem from the card network's side (Visa).

TAP doesn't try to replace the payment rail — it adds an identity layer so a merchant can answer one question cryptographically: *is this AI agent legitimate?* It does this by signing an agent's identity into HTTP request headers, built on the HTTP Message Signatures standard and aligned with Web Bot Auth, so merchants can establish trust with minimal changes to existing checkout pages. The framing is telling: Visa cites a roughly 4,700% surge in AI-driven traffic to U.S. retail sites as the reason merchants need to tell trusted agents from bots. The spec and integration docs are on Visa Developer. Track it on the TAP resource page. TAP's bet: agents will mostly transact over rails that already exist, and the missing piece is identity, not a new settlement layer.

How the standards differ — and why it's not settled

These three aren't doing the same job, which is why "who wins" is the wrong question.

x402 answers *how does a machine pay another machine, permissionlessly, per request?* — stablecoins over HTTP, no account.
AP2 answers *how does an agent prove a human authorized this purchase across any payment type?* — signed mandates as verifiable credentials.
TAP answers *how does a merchant know an agent hitting its checkout is trustworthy?* — signed agent identity on existing card rails.

They may end up layered rather than rivals: an agent could carry an AP2 mandate, present a TAP identity to a merchant, and settle a micropayment over x402, all in one flow. But the ecosystems, partners, and incentives differ, so for now a builder picks a primary path and accepts the lock-in. The honest read: this is an unsettled standards race with deep-pocketed backers on every side, and anyone claiming a clear winner is selling something. Whatever settles, the agent still needs a wallet that can sign within limits — that part doesn't change. Browse the directory for the tools building on each.

Examples

▸An agent paying $0.01 per request in USDC for swap quotes over x402, no API key (0x Swap API on Alchemy AgentPay).
▸A shopping agent carrying an AP2 Cart Mandate that cryptographically proves the user approved a specific basket and price before checkout.
▸An agent presenting a Visa TAP-signed identity in its HTTP headers so a Shopify merchant can confirm it's a trusted agent, not a scraper bot.
▸A data agent paying a few cents per call to a metered market-data endpoint instead of buying a monthly seat.
▸A treasury agent settling small inter-agent payments in stablecoins on Base, where low fees make sub-cent transfers viable.

Risks & Limitations

⚠Standards risk: x402, AP2, and TAP are competing, and which becomes dominant is unsettled — committing to one is a bet, not a sure thing.
⚠Adoption is early; partner lists and launch announcements are shown, but real payment volume through any standard is mostly self-reported, so treat scale claims as claimed.
⚠Wallet and key exposure: an agent paying autonomously needs tight spend limits and scoped permissions, or a bug or prompt injection can drain funds per call.
⚠Authorization gaps: a payment standard defines how money moves, not whether the agent should have spent it — that judgment, and the guardrails around it, are still on the builder.

Frequently Asked Questions

How do AI agents pay for things?: An AI agent pays by signing a transaction from a wallet it controls, most often settling in a stablecoin like USDC so it can pay small amounts per request. A payment standard — x402, Google's AP2, or Visa's TAP — defines how the agent proves it's authorized to buy before the funds move. Responsible setups bound that wallet with spend limits and scoped permissions.
Why do AI agents pay in stablecoins instead of dollars or cards?: Stablecoins like USDC keep the amount predictable and settle on low-fee chains, which makes per-request micropayments — fractions of a cent, thousands of times — economically viable. Cards and bank rails carry per-transaction overhead and require accounts, which doesn't fit machine-to-machine spending. That said, standards like AP2 and Visa's TAP are bridging agents back into card rails too, so it isn't strictly either-or.
What's the difference between x402, Google AP2, and Visa TAP?: They solve different parts of the problem. x402 is an open, crypto-native rail for paying per HTTP request in stablecoins. Google's AP2 is an authorization framework using signed mandates (verifiable credentials) across cards and crypto. Visa's TAP adds cryptographic agent *identity* onto existing card rails. They may end up layered rather than mutually exclusive — but for now they're competing standards with no settled winner.
Is there a single standard for AI agent payments yet?: No. As of 2026 there are at least three serious contenders — x402, Google's AP2, and Visa's Trusted Agent Protocol — each backed by major players and optimized for a different job. Anyone calling one "the standard" is making a claim the market hasn't confirmed. Building on one today means accepting some lock-in, so weigh which ecosystem fits your agent before wiring it in.
Is it safe to let an agent pay autonomously?: The payment standard defines how money moves, not how to bound risk — that's on the wallet setup. An agent paying on its own should use spend limits, scoped permissions, and policy-controlled signing so a single bug or prompt injection can't drain it. Treat any "safe" or "verified" framing as a claim until the wallet controls and on-chain behavior show it. See how agents use wallets.

Sources

Related Resources

x402

Early

Tool/Service

Open payment protocol enabling agents and apps to pay for APIs over HTTP using stablecoins.

BaseEthereumMultichain

Active★ 94

Agent Payments Protocol (AP2)

Active

Tool/ServiceVerified

Open protocol from Google for secure agent-led payments across traditional and crypto rails, with a crypto-native x402 extension built with Coinbase, Ethereum Foundation, and MetaMask.

EthereumBaseMultichain

Recent★ 2.9k

Visa Trusted Agent Protocol (TAP)

Active

Tool/ServiceVerified

Visa protocol that lets merchants authenticate trusted AI shopping agents via cryptographic signatures, with x402 interoperability into traditional payment rails.

Unknown

Alchemy

Active

Tool/Service

A blockchain developer platform providing node infrastructure plus NFT, Token, and Transfers APIs and SDKs across many chains.

EthereumBaseSolanaArbitrum

Active

Related Wiki Pages

Spotted an error or something outdated?Submit a correction →

Join the Sato Hub Briefing

One email a week — the agents, tools, and infrastructure that actually shipped, and why they matter.