x402 — HTTP 402, the API-native option
x402 uses the HTTP 402 status code so any web API can charge per request. Its strength is that it rides existing HTTP — no new transport — and is machine-readable, so an agent can pay any x402 server without a bespoke integration. It commonly settles in USDC on chains like Base, and can also carry faster off-chain credit schemes. Best for: paying for API calls and data.
AP2 — agent-to-agent commerce mandates
AP2 (an agent-payments protocol associated with Google's agent-commerce work) focuses on verifiable "mandates" — cryptographic authorizations that let an agent transact on a user's behalf within explicit limits. Its strength is the authorization model for delegated spending. Best for: agents acting for a human/principal with auditable spending authority.
L402 — Lightning-native payments
L402 (formerly LSAT) pairs HTTP 402 with Bitcoin Lightning payments and macaroon-based tokens. Its strength is tiny, fast Lightning micropayments. Trade-off: it ties you to the Lightning ecosystem and Bitcoin. Best for: very small payments where Lightning liquidity is available.
Raw stablecoin transfer — no protocol, just USDC
You can skip a payment "protocol" entirely and just send a stablecoin transfer (e.g. USDC via EIP-3009 "transfer with authorization"). Strength: maximal simplicity and on-chain finality. Trade-off: no standard discovery or 402 handshake, so each integration is bespoke. Best for: known, pre-arranged agent-to-agent transfers.
How to choose
If you are charging for API calls and want agents to discover and pay automatically, x402 is the natural fit. If you need a human-delegated spending-authority model, look at AP2. If you live in the Lightning/Bitcoin world and need sub-cent payments, L402. If two parties already know each other and just need to move value, a raw stablecoin transfer is simplest. Many real systems combine them — e.g. an x402 server that settles in USDC and also offers a faster credit scheme.