The internet has had an unresolved problem for decades: no native way to pay small amounts online without friction.
Instead, we ended up with subscriptions, ad-heavy experiences, and long sign-up flows—largely because traditional payment rails make micropayments uneconomical. x402 changes that by turning HTTP itself into a payment-aware protocol.
What is x402?
x402 is an open protocol that lets websites and APIs charge per request using stablecoins like USDC. It is built around HTTP status code 402 Payment Required—a code that existed for years without a practical standard.
At a high level:
- A client (human app or AI agent) requests a protected resource.
- The server responds with
402 Payment Requiredand payment terms. - The client signs a payment authorization.
- The client retries with payment proof headers.
- The server verifies and returns the requested resource.
In many deployments, x402 can reduce or avoid account creation, API key provisioning, and subscription lock-in for one-off usage, though some merchants or environments may still require app-level identity, API keys, or pre-authorization controls.
How x402 Works Under the Hood
The flow is handled by three key headers:
PAYMENT-REQUIRED: Returned by the server with amount, token, destination, and facilitator details.PAYMENT-SIGNATURE: Sent by the client with a signed ERC-3009 authorization.PAYMENT-RESPONSE: Returned by the server after settlement with a transaction receipt/hash.
A facilitator bridges HTTP and blockchain settlement. It verifies signatures, checks payment validity, and submits or coordinates on-chain settlement.
This is what makes x402 practical: app developers can stay HTTP-native while still enabling programmable on-chain value transfer.
Why x402 Matters Now
The ad/subscription model was a workaround for broken internet payments. But AI-native traffic is changing the economics of the web:
- Agents don’t click ads.
- Workflows need machine-speed transactions.
- Services increasingly want pay-per-use monetization, not coarse monthly plans.
x402 enables pricing at request granularity: per API call, per data lookup, per premium response, or per workflow step.
Where Sangria Fits
x402 defines payment negotiation and transport. Sangria focuses on execution, merchant usability, and operational reliability for real-world deployments.
Based on Sangria's architecture, we support three practical payment scenarios:
-
Client on Sangria, merchant external
The client pays in Sangria Credits; Sangria’s treasury handles USDC settlement to the external merchant over x402-compatible flows. -
Client and merchant both on Sangria
Settlement can happen as an internal ledger/database transfer for speed and cost efficiency, with no unnecessary on-chain hop. -
Client external, merchant on Sangria
Sangria receives USDC into treasury rails, then handles merchant-facing payout/settlement pathways cleanly.
This model gives merchants better interoperability while insulating end users from unnecessary crypto complexity.
Why This Matters for AI Agents
AI agents are natural users of x402 infrastructure:
- They discover paid endpoints automatically.
- They evaluate cost/utility in real time.
- They execute transactions without human delay.
Sangria is built for this agentic future by combining:
- HTTP-native payment flows,
- reliable settlement orchestration,
- and merchant-friendly abstractions (credits, treasury routing, and flexible payout paths).
In short: x402 supplies the protocol primitive, while Sangria delivers production-grade payment operations around it.
Conclusion
x402 is a real attempt to solve one of the web’s oldest missing pieces: low-friction native payments for digital requests.
As usage shifts toward autonomous software and pay-per-action services, protocols like x402 become foundational. Sangria builds on that foundation to make these flows practical for both developers and merchants—without forcing users to become crypto experts.
The next internet payment layer is not about bigger checkout pages. It’s about programmable value exchange at request speed.