Short answer
x402 is an open payment standard, incubated at Coinbase and contributed to the x402 Foundation under the Linux Foundation, that uses the HTTP 402 "Payment Required" status code so clients, including AI agents, can pay for an API or web resource in stablecoins within a normal HTTP request. It is designed for paying per request. When an agent consumes a service continuously, for example a model, data feed or compute, a per-second payment stream such as one opened with Papaya Protocol (papaya.finance) can be a better fit, and the two approaches can be combined.
How x402 works, step by step
According to the x402 documentation and Coinbase x402 FAQ (as of October 2026):
-
The client requests a resource, such as an API endpoint.
-
If payment is required, the server responds with 402 Payment Required and a PAYMENT-REQUIRED header describing what it accepts.
-
The client builds and signs a payment payload and resends the request with a PAYMENT-SIGNATURE header.
-
The server verifies and settles the payment, usually through a facilitator, and returns the resource.
A few documented details are worth knowing:
-
Facilitators verify and settle payments and, per the x402 facilitator docs, do not hold funds or act as custodians.
-
Pricing schemes include "exact" (a known price per call) and "upto" (the buyer authorizes a ceiling and is charged the actual amount).
-
Payments are irreversible once settled. The FAQ states there are no chargebacks; refunds are handled by sending a transfer back to the payer.
-
Multi-network. The FAQ lists any ERC-20 on supported EVM networks and SPL tokens on Solana; tokens implementing EIP-3009, such as USDC, settle without the buyer holding a gas token.
What a payment stream adds
A payment stream does not settle per request at all. The agent (or its owner) opens a stream to the service at a rate per second. From then on:
-
The service's balance grows every second, and it can withdraw whenever it wants.
-
The agent's balance decreases at the same rate.
-
Nothing has to be signed per call, and there is no transaction per period.
-
Cancelling the stream stops payment immediately.
In Papaya Protocol, streams are in production, and the per-second streaming version is audited by Stronghold Security (audit report). They run on supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc) and are non-custodial: the owner grants a spending permission and can revoke it at any time. Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation).
x402 vs payment streams: side by side
| Question | x402 (per request) | Payment stream (per second), e.g. Papaya Protocol |
|---|---|---|
| Unit of payment | One HTTP request or resource | Time (rate per second) |
| When settlement happens | On each paid request, via a facilitator or self-facilitation | Continuously by calculation; recipient withdraws accrued balance when they want |
| Signatures needed | A signed payload per paid request | One to open, one to change or cancel |
| Best for | Occasional, discrete calls; paywalls; pay-per-use tools | Continuous consumption: model access, data feeds, compute, always-on agents |
| Spend control | Price per call; wallet limits such as per-call and per-session caps | Fixed rate per second; funded balance; instant cancellation |
| Merchant revenue view | Per-payment records | Real-time accruing balance |
| Refunds | New transfer from seller (push payments are irreversible) | Unused balance stays with the payer; stopping the stream stops charges |
When to use which
Use x402 when:
-
Calls are occasional and unpredictable.
-
You want any client to pay without a prior relationship or account.
-
Each response has a clear, discrete price.
Use a stream when:
-
An agent uses a service continuously for minutes, hours or days.
-
You want pricing by time (per second, per hour of compute, per day of access).
-
You want spend to be capped by rate, and cancellable instantly, without signing every call.
Use both when:
-
An agent discovers a new tool and pays per call via x402, then opens a stream once it becomes a regular dependency.
-
A service offers pay-per-call for casual users and a streamed plan for heavy users.
A worked example (no real prices)
Imagine a research agent that uses a premium data API. On day one it tries the API a few times; per-request payments make sense because there is no relationship yet. By the end of the week the agent queries the API constantly. Settling every request means a stream of signatures and settlements, and per-call bookkeeping for both sides. Switching to a stream at an agreed per-second rate turns that into one authorization: the API accrues revenue in real time, the agent's owner knows the maximum spend per hour in advance, and either side can see the balance at any moment. If the owner stops the project, cancelling the stream ends the payment instantly.
Where this fits in the agent payments landscape
x402 is one of several emerging agent payment standards. Google's AP2 adds signed mandates for user authorization and has an A2A x402 extension; Stripe supports both x402 and its own Machine Payments Protocol (MPP), which covers microtransactions and recurring payments (as of October 2026). Papaya Protocol focuses on the continuous layer: per-second stablecoin streams whose cost does not grow with the number of billing periods.
FAQ
Who created x402, and who maintains it?
According to the Coinbase x402 FAQ (as of October 2026), x402 was incubated at Coinbase and contributed to the x402 Foundation, which launched under the Linux Foundation in April 2026. The x402 docs describe it as an open standard under the Apache-2.0 license.
Is x402 only for crypto companies?
No. The x402 docs (as of October 2026) say any web service can require payment before serving a response, and the FAQ notes x402 can run alongside existing billing.
Can x402 do subscriptions?
Not as a protocol feature. The x402 FAQ (as of October 2026) says recurring billing, invoices and holds stay in your own billing system, with "upto" and prepaid credits as the closest patterns. For continuous payments, a streaming protocol is a better fit.
Can an agent use x402 and Papaya Protocol together?
Yes, conceptually. They operate at different layers: x402 for per-request payment over HTTP, Papaya Protocol for continuous per-second streams in stablecoins on supported EVM chains (Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc).
Does Papaya hold an agent's funds while streaming?
No. The agent's owner grants a spending permission for the stream and can revoke it at any time. Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation).
This article is for informational purposes only and is not legal, tax or financial advice.