- x402 is a draft HTTP extension that lets any endpoint return a 402 Payment Required status with a USDC payment address, amount, and target chain, so a caller pays and retries without a human in the loop.
- Stripe and Coinbase are the two highest-profile x402 backers, but the space already includes developer-focused facilitators, agent wallet toolkits, and stablecoin infrastructure layers that handle settlement differently.
- Provider choice determines which chains you can settle on, whether you need a custodial wallet or can use self-custody, and how fees stack at sub-cent transaction sizes.
- The protocol is not production-ready for every use case, but several providers are already running pay-per-request APIs and metered agent billing in limited production today.
- Picking the wrong x402 payment provider now means re-instrumenting every endpoint later; the facilitator layer is where lock-in actually lives, not the protocol itself.
The x402 protocol turns any HTTP endpoint into a machine-payable resource by reviving the long-dormant 402 status code. A server returns a 402 with payment details encoded in the response header, the calling agent or SDK pays in USDC on a supported chain, and the server verifies the transaction and serves the response. No API keys, no invoices, no subscription tiers. The x402 payment providers listed here differ on chain support, fee structures, custodial model, and how much plumbing they abstract away from the developer.
What Is the x402 Protocol and Why Does Provider Choice Matter?
The x402 protocol was formally proposed by Coinbase in 2025 as an open standard for HTTP-native payments. At its core, it is a thin payment negotiation layer that rides on top of existing HTTP infrastructure. A client makes a request, receives a 402 with a X-Payment-Required header containing a payment payload, signs and broadcasts a USDC transaction on the specified chain, attaches proof in the X-Payment header, and re-sends the request.
The protocol spec itself is chain-agnostic in theory, but the current reference implementation from Coinbase targets Base, which is an Ethereum Layer 2. That detail matters because Base transaction fees are a fraction of Ethereum mainnet costs, making sub-dollar micropayments economically viable. A $0.001 per-request pricing model breaks down immediately if each settlement costs $2 in gas.
Provider choice shapes three concrete things. First, which chains and stablecoins settle your revenue. Second, whether your server-side facilitator is custodial (the provider holds funds until sweep) or non-custodial (payment goes directly to your wallet). Third, how much of the verification and webhook logic you write yourself versus delegate. For a deeper look at how stablecoin settlement infrastructure fits into a broader payment stack, the best stablecoin infrastructure providers comparison on FintechSpecs covers the non-x402 layer below these facilitators.
The FintechSpecs x402 Provider Selection Framework
Before comparing individual providers, it helps to run every candidate through the same four checks. This is the FintechSpecs x402 Provider Selection Framework , a structured evaluation built specifically for teams choosing a facilitator before the market has standardized. Apply it early, because the differences between providers are not obvious from SDK documentation alone.
Settlement path: Does the payment go directly to a wallet you control, or does it pass through the provider’s custodial layer first? For revenue-bearing endpoints, custodial settlement means you have counterparty exposure to a company that may still be pre-revenue itself.
Fee floor at the intended price point: If you plan to charge $0.002 per request, what is the all-in cost per transaction including gas, facilitator fee, and any spread? On Base with USDC, Basescan and the L2Fees tracker both show gas costs running well under $0.01 per transaction for simple ERC-20 transfers, though fees fluctuate with network demand. Run the math for your target price point before assuming the economics work.
Verification latency: x402 works synchronously in its reference form: the server waits for transaction confirmation before serving the response. On Base with fast block times, this is usually under two seconds, but facilitators that batch verification or add their own confirmation layers can add meaningful latency to a pay-per-request API. Ask for confirmation time guarantees or test directly.
Abuse surface: A public HTTP endpoint that returns real data in exchange for an on-chain payment is a target for replay attacks (reusing a valid payment proof), underpayment attacks (sending slightly less than required), and chain spoofing (claiming a different chain). Check whether the facilitator handles nonce enforcement and exact-amount verification, or whether you are writing that logic yourself.
How Do x402-Compatible Providers Actually Compare?
| Provider | Primary Chain | Stablecoin | Custodial? | Open Source SDK? | Best For |
|---|---|---|---|---|---|
| Coinbase x402 | Base | USDC | No (direct wallet) | Yes (reference impl) | Teams already on Coinbase Developer Platform |
| Stripe (x402 on Base) | Base | USDC | Custodial option | Partial (via Stripe SDK) | Teams using Stripe billing who want a hybrid model |
| Crossmint | Multi-chain | USDC | Yes (Crossmint wallet) | Yes | Agent wallet provisioning at scale |
| Payman AI | Solana, Base | USDC | Yes (Payman wallet) | Yes | AI agent-to-agent payment flows |
| Privy | Base, Ethereum | USDC | Embedded (delegated) | Yes | Products where end-users need embedded wallets |
| Alchemy | Base, Ethereum, Polygon | USDC, USDT | No (self-custody via AA) | Yes | Teams wanting account abstraction and gas sponsorship |
| CDP (Coinbase Developer Platform) AgentKit | Base | USDC | No | Yes | LangChain/AI agent frameworks needing wallet primitives |
Which x402 Payment Providers Are Shipping Support Today?
1. Coinbase x402 Reference Implementation
Coinbase published the x402 specification and the first open-source reference implementation on GitHub in 2025. The facilitator package handles 402 response generation on the server side, and a client-side package manages payment signing and header injection. Settlement goes directly to a developer-controlled wallet address on Base, with no custodial intermediary holding funds.
The reference implementation is the most protocol-accurate option available, but it is also the most bare-metal. You write your own business logic for rate limiting, per-user accounting, and abuse prevention. For teams running pay-per-request APIs where each caller is an autonomous agent rather than a human, that is often acceptable. Developers building on the AI agent payment infrastructure layer will find AgentKit and the x402 facilitator designed to work together out of the box.
Because the reference implementation targets Base exclusively in its current form, teams needing Solana or Ethereum mainnet settlement will need to adapt the facilitator or use a different provider.
2. Stripe (x402 on Base)
Stripe announced support for stablecoin payments including USDC on Base in 2025, and its roadmap includes x402 compatibility as part of a broader push toward programmable and machine-readable payment flows. Stripe’s implementation sits at an interesting intersection: it can combine traditional fiat billing with on-chain settlement, letting a product accept both a Stripe subscription and an x402 per-request payment from the same codebase.
The practical advantage here is for teams that already run Stripe for their human-facing billing and want to add a machine-payable layer without fragmenting their reconciliation. Stripe’s existing dashboard, webhooks, and reporting apply to the stablecoin flows. The tradeoff is that Stripe’s x402 path goes through Stripe’s infrastructure rather than settling directly to a self-custody wallet, which adds a layer of counterparty dependency. For teams evaluating the broader Stripe billing stack against alternatives, the Stripe billing alternatives for usage-based pricing article covers where Stripe’s model falls short at extreme granularity.
Stripe does not publicly disclose per-transaction fees specific to its x402 or stablecoin flows on its public pricing page, so teams should confirm pricing directly with Stripe before building on this path.
3. Crossmint
Crossmint is primarily known as an NFT and wallet infrastructure provider, but its managed wallet API makes it a practical x402 facilitator for teams that need to provision wallets at scale for AI agents or end-users. When each agent in your system needs its own wallet to make x402 payments autonomously, Crossmint’s API lets you spin up wallets programmatically without asking each agent to manage private keys.
The custodial model here is its biggest distinguishing characteristic. Crossmint holds private keys on behalf of your agents, which simplifies key management but introduces a counterparty. For agent-to-API billing where the amounts per transaction are small and the agent population is large, that tradeoff is often worth it. Multi-chain support across Base, Ethereum, Solana, and others gives Crossmint more settlement flexibility than providers locked to Base.
4. Payman AI
Payman AI is purpose-built for AI agent payment flows, including both x402-style pay-per-request patterns and agent-to-agent payment routing. It offers a managed wallet layer where agents can hold balances, pay external APIs, and receive payments, with USDC on Solana and Base as the primary settlement rails.
The distinguishing factor for Payman is the orchestration layer it adds on top of raw x402 mechanics. Rather than requiring a developer to wire up facilitator logic endpoint by endpoint, Payman provides a unified interface for managing agent budgets, setting spending limits per task, and auditing what each agent paid for. For multi-agent systems where one orchestrator spins up subagents that each make paid API calls, this kind of budget governance matters.
Payman does not publicly disclose per-transaction pricing on its public-facing site, and the product is in active development. Teams should evaluate it as an early-production option rather than a fully stabilized platform.
5. Privy
Privy approaches x402 compatibility from the embedded wallet angle. Its core product provisions wallets for end-users inside consumer or B2B applications without requiring users to install a browser extension or manage seed phrases. When a product’s paying user is a human who needs a wallet to fund per-request API access, Privy’s embedded wallet fits naturally into that flow.
This makes Privy less relevant for pure machine-to-machine x402 scenarios and more relevant for developer tools that expose pay-per-call endpoints to human developers who should not need to think about wallets at all. The experience from the caller’s side can be made nearly invisible: Privy handles wallet creation, key storage via delegated access, and transaction signing under the hood. Support for Base and Ethereum covers the chains where most x402 activity currently runs.
6. Alchemy
Alchemy is not an x402 facilitator in the narrow sense, but its account abstraction infrastructure is directly relevant to any team building on x402. Account abstraction via ERC-4337 lets a smart contract wallet sign transactions according to custom logic, including paying for gas in USDC rather than ETH. When you deploy an AI agent that needs to make x402 payments on Base, the gas cost question comes up immediately. Alchemy’s gas sponsorship through its Paymaster product lets you subsidize gas for callers, which removes a major friction point in asking agents or users to hold ETH just to pay for transaction fees.
Alchemy’s infrastructure also covers multiple chains, USDC and USDT support, and a node infrastructure layer that most x402 facilitators depend on indirectly anyway. Teams building custom x402 facilitators rather than using a packaged solution will likely build on Alchemy’s RPC infrastructure underneath. Alchemy does not publicly list x402-specific pricing; its Node and Account Kit products are available with a free tier and paid plans, with details on its public pricing page.
7. Coinbase Developer Platform AgentKit
CDP AgentKit is a toolkit from Coinbase specifically designed to give AI agents built on frameworks like LangChain and LangGraph access to on-chain financial primitives, including x402 payment capabilities. It wraps the x402 client logic, wallet creation, and USDC transfers into tool-call-compatible functions that a language model can invoke directly.
For teams building AI agents in Python or TypeScript who want to expose those agents to x402-gated APIs, AgentKit is the most direct integration path. The agent framework calls a pay_for_resource tool, AgentKit handles the HTTP 402 negotiation and the USDC transfer on Base, and the agent receives the response. No custom facilitator code needed.
The constraint is that AgentKit runs on Base and requires a Coinbase Developer Platform account. Teams that want Solana settlement or chain flexibility will need to look at Payman or Crossmint instead.
Is x402 Protocol Production-Ready for Real API Monetization?
The honest answer is: it depends on what production means for your use case. If production means “runs without human intervention at low volumes with acceptable tail latency,” then yes, the Coinbase reference implementation running on Base is there today. Public developer community activity on GitHub and the x402 specification repository shows teams shipping x402-gated endpoints , primarily API tooling companies running pay-per-request demos and limited production deployments , though no comprehensive public registry of live x402 endpoints exists yet.
If production means “handles 10,000 requests per second with SLA guarantees, full accounting, and dispute resolution,” then no provider in this list is fully there. The protocol is a draft, the tooling is early, and the facilitator market is fragmented.
The comparison to early Stripe is instructive without being naive. Stripe launched with a narrow API that handled a fraction of what it does now, and teams that built on it early captured structural advantages in their payment stack. The x402 adoption curve is likely steeper because the customer base , AI agents making API calls autonomously , is growing much faster than the human developer base grew in 2011. For a broader view of how machine payment standards fit alongside agent communication protocols, cross-reference the agent payment infrastructure overview which covers ACP, AP2P, and x402 in relation to each other.
How Should Developers Price a Pay-Per-Request API on x402?
Consider a team building a financial data API that returns one quarter of earnings data per request. With traditional billing, the options are a monthly subscription (undermonetizes high-frequency users), a Stripe metered billing setup (adds invoice latency and minimum charges), or credits purchased upfront (requires user intent before value is delivered).
With x402, you set a per-request price in USDC directly in the 402 response. Say you set $0.005 per call. A research agent making 500 calls in an afternoon pays $2.50, settled to your wallet in real time, without a human approving anything. The same agent could call the API once, decide the data quality is insufficient, and stop at $0.005 spent. No subscription churn. No refund request. The economic unit matches the value unit.
The pricing floor is determined by the all-in transaction cost on your chosen chain. On Base with USDC, L2Fees.info and Basescan both show ERC-20 transfer costs well under $0.01 under normal network conditions, making sub-cent pricing economically viable. Verify current costs before publishing a price , Base fees can spike during congestion. On Ethereum mainnet, the economics do not work for micropayments at all.
For teams thinking about how x402 per-request pricing interacts with their existing SaaS billing architecture, the broader pricing models in fintech SaaS article covers where consumption-based models create margin pressure and where they expand it.
What Are the Compliance and Custody Considerations for x402 Payments?
Receiving USDC payments directly to a wallet is not a regulated money transmission activity in most interpretations under current US law, but this area is actively evolving. The GENIUS Act and related federal stablecoin legislation moving through Congress in 2025 and 2026 will affect which entities can hold stablecoin balances as a business function. If your x402 endpoint generates meaningful revenue, get legal clarity on whether your business needs a money transmitter license or can rely on an exemption.
Custodial facilitators like Crossmint and Payman hold funds on your behalf, which potentially implicates their licensing status rather than yours, but that is not a clean answer and it depends on the structure. The GENIUS Act compliance checklist covers the stablecoin-specific regulatory surface area that x402 providers and their customers will need to address.
Tax treatment of USDC received as payment for services is clearer: it is ordinary income at the USD value at time of receipt, reportable in the same way as any other service revenue. The complication is that on-chain payment data does not automatically flow into accounting systems. Teams using Stripe’s x402 path benefit from Stripe’s existing reporting infrastructure. Teams using direct-to-wallet settlement will need to pipe on-chain transaction data into their bookkeeping.
Frequently Asked Questions
What chains does x402 currently support?
The Coinbase reference implementation targets Base, which is an Ethereum Layer 2. Base is currently the primary chain for x402 activity because its low transaction fees make micropayments viable. Alchemy supports Base, Ethereum mainnet, and Polygon through its account abstraction infrastructure. Payman AI supports both Solana and Base. The x402 protocol specification is technically chain-agnostic, but most production-ready tooling assumes Base and USDC as the default settlement path.
Can an AI agent make x402 payments without a human approving each transaction?
Yes. That is the core design intent. An AI agent with access to a funded wallet, whether provisioned through Coinbase AgentKit, Crossmint, or Payman, can encounter a 402 response, evaluate the payment terms, sign and broadcast the transaction, and retry the request without any human in the loop. Budget controls and spending limits are the developer’s responsibility and need to be set at the agent orchestration layer, not inside the x402 protocol itself.
Is x402 the same as the original HTTP 402 status code?
No. The original HTTP 402 status code was reserved in 1991 in the HTTP/1.0 specification for future use in digital payment systems but was never formally standardized. Coinbase’s x402 proposal is a practical implementation that uses the 402 status code and defines the header schema, payment payload format, and verification flow needed to make it functional. It is a draft standard rather than an RFC-ratified specification, which means the implementation details can still change.
How does x402 compare to traditional metered API billing with Stripe?
Traditional metered billing with Stripe requires a customer account, a stored payment method, monthly invoice cycles with minimum charges, and human review at various friction points. x402 removes all of that for machine callers. A new API client can make a paid request in its first HTTP call with no prior account setup. The tradeoff is that x402 requires the caller to hold USDC in a wallet, which adds a setup cost for human developers who are not already crypto-native. For a mixed audience of humans and agents, running both systems in parallel is the common pattern today.
What happens if an x402 payment is sent but the server never delivers the response?
The protocol does not include a built-in escrow or dispute mechanism in its current draft form. If a server accepts payment proof and then fails to return the expected response, the caller has no on-protocol recourse. This is one of the genuine reliability gaps in the current spec. Facilitators like Payman and Crossmint add their own application-layer protections, but teams using the bare Coinbase reference implementation should consider what their error handling looks like for failed deliveries before going to production.
Do I need to be on Coinbase’s platform to use x402?
No. The x402 specification is open, and the reference implementation is published as open-source software. Coinbase Developer Platform and AgentKit are Coinbase products that integrate x402 as a feature, but the underlying facilitator code can be run independently. Providers like Crossmint, Payman, Privy, and Alchemy all offer x402-compatible tooling without requiring a Coinbase account. The chain requirement is Base for most current implementations, not a Coinbase account.
What is the minimum viable x402 implementation for a solo developer?
A solo developer can run a working x402-gated endpoint using the Coinbase open-source facilitator package, a Base wallet address, and about 50 lines of Node.js or Python middleware. The facilitator package handles 402 response generation and payment verification. The developer provides a wallet address for settlement, sets a price per request in USDC, and wraps the relevant routes. No provider account required beyond a Base-compatible wallet. The open-source repository includes working examples for Express, FastAPI, and several common frameworks.
Which x402 provider is best for an AI agent that needs to pay third-party APIs?
Coinbase AgentKit is the most direct option for agents built on LangChain or similar frameworks, because the x402 payment logic is exposed as a tool call the model can invoke natively. Payman AI is better for multi-agent systems where you need budget governance across multiple agent instances. Crossmint is the better choice when you need to provision wallets for a large number of agents programmatically at scale, particularly if those agents run on multiple chains. The right choice depends on whether your bottleneck is agent framework integration, budget control, or wallet provisioning velocity.
The Bottom Line on x402 Provider Selection
The x402 payment provider market is at the stage where picking any major provider gets you a working implementation, but the differences between them compound over time. Coinbase’s reference implementation gives you the most protocol fidelity and direct settlement, at the cost of writing more infrastructure yourself. Stripe’s x402 path gives you familiar tooling and unified reconciliation, with less settlement control. The agent-native providers , AgentKit, Payman, and Crossmint , abstract away wallet management at the cost of varying degrees of custodial dependency.
The decision that matters most right now is not which provider has the cleanest SDK. It is whether your endpoint’s paying callers are humans who will need an embedded wallet experience, or autonomous agents that just need a funded address and a spending budget. Those two architectures pull toward different providers, and the choice shapes everything from your UX to your compliance obligations.
The teams that ship a pay-per-request x402 endpoint this year, even at low volume, will have real production data on fee economics, abuse patterns, and agent behavior before the market matures. That operational knowledge is not something you can catch up on by waiting. Pick the provider whose custody model matches your risk tolerance, verify the fee math for your target price point using current data from L2Fees.info or Basescan, and ship the endpoint.
