Building agentic and programmatic payments with x402 and Privy
How to enable instant, automatic stablecoin payments over HTTP with Privy embedded wallets.
Madeleine Charity
|Nov 13, 2025
Want to try x402 immediately? Check out our recipe here.
In the original HTTP spec from 1997, there was a mysterious status code: “402 Payment Required.”
It was included as a placeholder, and hinted that one day, the web might need a way to pay for things. Yet, for nearly 30 years, 402 sat unused and unimplemented. The Internet thus evolved without built-in payments, a gap many have since called the “original sin of the web.”
x402 is a revival of that idea. The “x” refers to an HTTP extension, and 402 is the status code it brings back to life. Developed by Coinbase, x402 is a modern extension of the old HTTP 402 payment code.
It finally gives developers a simple, standardized way to say, “This resource costs money and here’s how to pay for it.”
With stablecoin settlement built in, the payment clears instantly, no checkout flow required. That makes entirely new pricing models viable: instead of subscriptions or ad-based monetization, developers can charge per request, per inference, or per piece of content, thus matching revenue directly to usage.
At the same time, x402 provides a consistent payment handshake across APIs and agents, establishing a universal language for machine-to-machine payments.
How does x402 work?
x402 is a new extension to HTTP that lets clients include payment in their requests in a standardized way. Instead of redirecting users to a checkout page or requiring prepaid credits, the server can simply respond with: "402 Payment Required. Here’s the amount, the asset, the recipient, and the time window. Retry with a payment attached.”
With that, the flow is straightforward:
Seller request a resource (an API endpoint, a model inference, a piece of content)
The server replies with a 402. This response includes all the details needed to make a payment, such as how much USDC, where it should go, and how long the payment requirements are valid.
The buyer’s wallet creates a one-time authorization. Instead of sending funds immediately, the wallet signs a permission that says, “I allow up to this amount to be pulled to this address, within this time window.”
Buyer resends the request with an
X-PAYMENTheader, a special HTTP header that carries the signed payment authorization.The server asks a facilitator to verify the payment. The facilitator checks the signature, submits the authorization onchain, pays gas, and returns a transaction hash as proof.
If the payment settles, the server returns the content. Buyer gets a normal
200 OK, the standard HTTP signal that the request completed successfully, along with an optional payment receipt.
In practice, x402 turns payments into a simple, repeatable pattern: “request → receive payment requirements → authorize payment → retry → receive content.”
Because x402 rides on normal HTTP, it works seamlessly with any API, any agent, and any embedded wallet that supports stablecoins, including Privy’s.
What you can build with x402
x402 makes payments part of the request cycle itself, unlocking new application patterns that weren’t practical before. Because a payment can happen automatically during a normal HTTP request, developers can build new transactional experiences that feel native and seamless.
1. AI agents paying each other
Agents can pay for data, model calls, or routing services on the fly, with no credits or billing setup required. Payments become just another step in the workflow, letting agents operate fully autonomously.
2. Usage-based API pricing
Charge per inference, per image, per query, or per request. This removes the need for subscriptions or prepaid credits and lets developers charge based on actual usage, not guesses or monthly minimums. It is particularly ideal for AI workloads where demand is spiky and unpredictable. Users can simply “request → pay → continue,” and the billing always matches real consumption.
3. Machine-payable content
Enable per-article reads, per-video access, or metered downloads without accounts, paywalls, or checkout flows. Content becomes unlocked the moment a payment is attached to the request. This makes it possible to monetize small pieces of content that are too light for subscriptions, while keeping the experience frictionless for both humans and agents.
4. Middleware and aggregator services
Services that forward or process requests, like model routers, API gateways, or traffic relays, can charge per request they handle, with payment attached to the forwarded call. This lets them bill in real time without subscriptions, credits, or separate billing systems.
5. Zero-balance user experiences
Settlement is handled by the facilitator, which may abstract gas or onchain details depending on how it’s implemented. This enables a “wallets that just work” experience, with payments feeling invisible and effortless.
All of this works without browser extensions, seed phrases, popups, or user friction, making x402 a natural fit for embedded wallets like Privy.
Using x402 with Privy
Privy makes it easy for your users to authorize x402 payments with their embedded wallets.
This payment authorization can be seamlessly submitted to a facilitator for verification and settlement, giving you the fastest path to experiment with programmatic payments while keeping your users fully inside your app and your Privy wallet architecture.
Why Privy for x402?
Privy is a natural fit for x402 because it gives you:
Embedded wallets: Every user gets a wallet without extra onboarding or browser extensions.
User-owned, secure authorization: All payments are explicitly authorized by the user.
Drop-in SDK: Add per-request payments to any endpoint with a small hook, not a billing system
This lets you introduce “request → pay → continue” flows to your app in minutes.
How the Privy x402 hook works
The Privy recipe wraps the x402 flow so you don’t have to manage typed data, nonces, validity windows, or header construction yourself. The hook detects when a request requires payment, handles the signing with the user’s embedded wallet, and resubmits the request with the correct X-PAYMENT header.
In practice, you don’t need to understand x402 to use it. You add a single line of code to tell Privy which wallet to use and how much you’re willing to pay before making an API call. Privy takes care of detecting the 402 response, generating the typed-data authorization, and retrying the request with the right header. The full implementation and code sample are available in our recipe.
Testing x402
You can try x402 today using:
Coinbase’s hosted facilitator (USDC on Base, no fees)
Base Sepolia for development
Testnet USDC from Circle’s faucet
While testing uses a faucet, real production flows can rely on Privy’s onramps and funding hooks, making it seamless to move USDC into a wallet and then authorize payments with x402.
This setup lets you deploy real programmatic payments using a third-party facilitator, without deploying any infrastructure or settlement logic yourself.
Looking ahead
This recipe is a simple client-side integration that works directly with any facilitator and makes it easy to experiment with programmatic payments today.
As the x402 ecosystem evolves, there are several interesting directions the space could grow into, both on the technical side and in terms of new use cases:
Programmable spend controls
x402 pairs naturally with programmable spend and authorization controls, an area where Privy’s policy engine can add real safety and guardrails. For example, developers could imagine setting per-domain spend limits, agent-specific permissions, or workflow-level approvals that run entirely off-chain.
This becomes especially important when transacting on your users behalf while they are offline. A developer could create a session signer that allows an agent to issue x402 payments on the backend without requiring interactive user consent each time. With the right policies enforced on that session signer, you can ensure those automated payments stay within strict boundaries, which prevents runaway spend or unexpected authorizations while still enabling fully autonomous agent behavior.
Richer agent-to-agent economies
With reliable, automated payments, agents could begin coordinating more complex tasks: paying data providers, settling with model routers, or participating in micro-markets for compute and bandwidth.
Privy is exploring x402 early because we see programmatic payments becoming a first-class part of how apps, agents, and APIs interact. Our goal is to make sure developers can tap into that shift with wallet infrastructure that feels simple, reliable, and built for real production use.
Get started with programmatic payments today using our x402 recipe. Have a use case in mind? We’d love to hear what you’re building.
