What is the x402 protocol?

x402 is an HTTP-native payment protocol that revives the dormant 402 Payment Required status code. When an agent hits a paywalled endpoint, the server returns a 402 with machine-readable payment instructions. The agent pays inline — no redirects, no human intervention. It's designed specifically for autonomous, machine-to-machine transactions.

Stripe ACP (Agent Commerce Protocol) is Stripe's framework for letting AI agents authenticate, authorize, and complete purchases through Stripe's existing merchant network. It piggybacks on Stripe's infrastructure and is aimed at agents buying goods and services from Stripe-connected merchants rather than paying for raw API access.

Google AP2 (Agent Payment Protocol v2) is Google's specification for agent-initiated payments within its ecosystem. It focuses on structured authorization flows where a human or orchestrating system grants a scoped spending mandate to an agent before any transaction occurs. It's tightly coupled to Google Pay and Google identity infrastructure.

Can an AI agent use more than one payment protocol?

Yes — and in practice most production agents will need to. An agent might use x402 to pay for a data API mid-task, Stripe ACP to purchase a SaaS subscription, and AP2 to complete a checkout via Google Pay. The challenge is managing credentials and spending limits across all three without losing visibility or control.

How does ATXP fit into agent payment protocols?

ATXP sits above the protocol layer. It gives each agent its own payment identity — handle, IOU balance, and spending cap — that works across x402, Stripe ACP, and AP2. Instead of wiring protocol credentials directly into agent code, you route payments through ATXP and get unified revocation, per-agent limits, and a single audit trail regardless of which protocol fires.

x402 vs Stripe ACP vs Google AP2: Agent Payment Protocols Compared

You’re building an agent that needs to pay for things — API calls, data subscriptions, checkout flows — and you’ve got three protocol names in your notes: x402, Stripe ACP, and Google AP2. They’re not interchangeable, and picking the wrong one for a given use case will cost you in rework.

Quick answer: x402 handles inline HTTP micropayments between machines. Stripe ACP targets agent-driven commerce through Stripe’s merchant network. Google AP2 governs scoped authorization for agent-initiated payments within Google’s ecosystem. Most production agents will touch more than one. The right choice depends on what the agent is paying for, not just what stack you’re on.

What Each Protocol Was Actually Built to Solve

Each protocol targets a distinct payment surface. x402 is about paying for resources — API calls, data endpoints, compute — at the HTTP layer without human involvement. Stripe ACP is about agents completing commercial transactions on behalf of users through merchants already on Stripe. Google AP2 is about delegated authorization — a human or orchestrator scoping what an agent is allowed to spend before the task starts.

These aren’t competing answers to the same question. They’re answers to different questions that happen to involve AI agents and money.

x402: Payments at the HTTP Layer

x402 works by making payment a first-class HTTP primitive. A server returns 402 Payment Required with a machine-readable body — amount, accepted token types, payment address. A compliant client (your agent) pays inline and retries. The whole exchange happens inside the HTTP lifecycle, typically in under a second.

This is the right protocol when:

You’re paying for API access or raw data endpoints
Transactions are small — cents or fractions of cents
No human is in the loop and latency matters
You’re building in a crypto-native or stablecoin environment

The tradeoff: x402 adoption is still thin outside crypto-adjacent infrastructure. If the service you’re hitting doesn’t return a well-formed 402, the protocol doesn’t help. Coinbase has been the loudest backer; broader merchant support is limited as of mid-2026.

Property	x402
Payment surface	HTTP endpoints, APIs
Transaction size	Micropayments (sub-$1)
Settlement layer	On-chain / stablecoins
Human-in-loop	No
Merchant coverage	Low — crypto-native ecosystem

Stripe ACP: Agent Commerce Through Existing Merchants

Stripe ACP lets agents act as purchasing entities within Stripe’s commerce infrastructure. Instead of building new payment rails, it extends Stripe’s existing checkout and authorization flows to handle non-human initiators. An agent can browse, select, and purchase from any Stripe-connected merchant using ACP without a human clicking “confirm.”

This is the right protocol when:

Your agent is buying SaaS subscriptions, services, or physical goods
The merchant already runs on Stripe (a large but finite set)
You need card-network-grade fraud protection and receipts
Your users expect familiar Stripe billing semantics

The tradeoff: ACP inherits Stripe’s fee structure and is anchored to fiat rails. It’s not designed for sub-cent API micropayments. And if your agent needs to pay a vendor not on Stripe, you’re out of scope.

Property	Stripe ACP
Payment surface	E-commerce, SaaS, services
Transaction size	Standard purchase amounts
Settlement layer	Fiat (card networks, bank transfer)
Human-in-loop	Optional — configurable
Merchant coverage	High — within Stripe ecosystem

Google AP2: Scoped Authorization Before the Task Starts

Google AP2 defines how spending authority gets delegated to an agent before any money moves. The protocol focuses on the authorization handshake — a structured mandate that specifies merchant categories, spending ceilings, and time windows. The agent then acts within those bounds using Google Pay infrastructure.

This is the right protocol when:

Your agent operates inside Google Workspace or Assistant workflows
You need explicit, auditable pre-authorization that satisfies compliance requirements
The transaction endpoints are Google Pay-compatible merchants
User trust and consent traceability are non-negotiable

The tradeoff: AP2 is tightly coupled to Google’s identity and payments stack. Portability outside that ecosystem is limited. It also skews toward pre-authorized bounded spending rather than real-time reactive payments.

Property	Google AP2
Payment surface	Google Pay merchants, Google ecosystem
Transaction size	Variable — mandate-defined ceiling
Settlement layer	Fiat (Google Pay rails)
Human-in-loop	Yes — pre-authorization required
Merchant coverage	High — within Google ecosystem

If you’re building agents that need payment identities across all three protocols — not just one — ATXP gives each agent its own handle, IOU balance, and spending cap with a single integration.

Side-by-Side: Agent Payment Protocol Comparison

	x402	Stripe ACP	Google AP2
Best for	API/data micropayments	E-commerce purchases	Pre-authorized task spending
Settlement	On-chain / stablecoins	Fiat	Fiat
Human approval	None	Optional	Required upfront
Latency	Sub-second	Seconds	Pre-task (near-zero at runtime)
Ecosystem lock-in	Low	Stripe merchants	Google ecosystem
Micropayment support	Yes	No	No
Audit trail	On-chain	Stripe dashboard	Google Pay console

Why Most Agents Will Need More Than One

A real-world agent task frequently crosses protocol boundaries in a single run. Consider a research-and-purchase agent: it calls a paywalled data API (x402), subscribes to a SaaS tool for the task duration (Stripe ACP), and completes a checkout for a physical component through a Google Pay merchant (AP2). Three protocols, one agent, one task.

The dangerous pattern here is wiring each protocol’s credentials directly into your agent’s code. That approach means:

No unified spending cap — each credential has its own limit, or none
No single revocation point — compromising the agent means hunting down three sets of credentials
No consolidated audit trail — spend is scattered across three dashboards

This is the blast radius problem. An agent with unconstrained multi-protocol access and credentials embedded in its runtime is a wide-open risk surface.

The Infrastructure Layer You Actually Need

Protocol support and payment identity are two different problems. x402, Stripe ACP, and AP2 define how payments flow across specific networks. They don’t define who the paying agent is, how much it’s allowed to spend, or how you shut it down when something goes wrong.

That’s the layer ATXP provides. Each agent gets its own payment handle, a balance in ATXP credits (not a generic IOU token), and a spending cap you set at provisioning. When the agent hits x402, pays via Stripe ACP, or delegates through AP2, those transactions route through its ATXP identity. One cap. One revocation switch. One audit log.

Give your agents payment identities that work across every protocol — start at atxp.ai.