its not that 402 isn't used, its that there is no standard response, which makes it hard for AI agents to pay for access. x402 provides a standard response format clients can programmatically use to create a payment, either using crypto assets like stablecoins, or in future, fiat methods.

USDC is also available on Solana and there's fees there too but they're pretty infentessimal. I've sent USDC from Coinbase to my Solana wallet and haven't had to pay any fees, so I presume it's not high enough for Coinbase to bother charging anyone.

As far as addresses, yeah there's no way to avoid this. When you send cryptocurrency there's no real way to ensure that a wallet exists at the receiver's address nor that the person you want to reach is at this address, so you need to be careful that you are using the correct address. Ethereum uses ENS addresses to help deal with this.

In that way this is a lot like a wire transfer in the US. If you use the wrong account or routing number then you're basically SOL. There's some verification you can do with receiver names but if your recipient is just at some bank and only the bank name comes up there's not much you can do.

x402 abstracts away gas! You can try here from a human use standpoint: https://www.x402.org/protected And you can see how to accept stablecoins or spend in the the examples https://github.com/coinbase/x402/tree/main/examples/typescri... https://github.com/coinbase/x402/blob/main/examples/typescri...

A truly open payment protocol should handle any currency (not force you to adopt crypto coins) and would leave it to the merchant and buyer to agree on their settlement method or intermediary, the cancelation and dispute policy etc.

It's entirely possible then that some options would be available, for example in SEPA, that offer instant and irreversible settlement at zero cost.

It's not the shape of the API payload that is the problem, is it? Few banks have a REST API for payments is the issue IMO.

> The protocol boast "no fee" but that's deceptive: if it's based upon a blockchain, there will be transaction fees.

These days many transaction types onchain are completely free and subsidized because gas costs are subcent[1].

x402 functions predominantly on L2 networks like Base, where individual tx costs between agents are generally not a factor.

[1] https://www.gasfees.io/

x402 as a protocol has no fees, but the underlying network transactions are conducted on my have costs. Merchants can choose the underlying network transactions are conducted on that best fit their usecase. x402 also has the concept of a facilitator, which exists to abstract away the underlying payment networks. Many facilitators (including Coinbase's) subsidize the gas used for transactions.

The protocol has no fees. If you use it with a blockchain, then there might possibly be a fee. If you use it with VISA, there will be a fee, etc.

There is some Blockchains where the fees are super low, like Solana

> Free and open payments should be bitcoin based to be truely decentralized

Agreed. Which is why 5 years ago, I developed L402 (formerly known as LSAT) to fill this very gap:

  * https://github.com/lightninglabs/L402 (https://lightning-labs-2.gitbook.io/lsat)

  * https://lightning.engineering/posts/2020-03-30-lsat/

L402 is more opinionated as utilizes the Lightning Network (LN) directly within the protocol. The server presents the client with a SHA 256 payment hash embedded within an LN invoice. The server requires the client to present the pre-image for said payment hash. The only way the client can obtain said pre-image is by paying the invoice on the Lightning Network (all payments are conditional payments where a pre-image needs to be revealed to complete a payment).

L402 also adds a layer of macaroons, enabling the protocol handle both payment and fine-grained authentication.

The advantages of LN over something like Coinbase's Base chain include:

  * Privacy: Coinbase and the entire world sees all your transactions. 

  * Decentralization & Reliability: Base is a singleton instance, if it goes down, you can't make any transactions. LN is decentralized, just like the internet, you can always route around failures. 
 
  * Settlement Speed: Base blocks happen every 2 seconds, until that period your transaction isn't finalized. However that's only committing to Base, and not the underlying ETH chain, which has 12 second block time. Latency on LN is primarily a function of e2e network delay, so it can be as little as 100 ms.

You seem like a knowledgeable crypto user. Can you help integrate lightning payments with x402? Then we'll be rid of this Base/corporate-tech nonsense.

It's really difficult to build agentic applications on top of Bitcoin. It's generally possible throughout the EVM however, which is many networks, not just Base. Base won't be the only EVM-compatible network that x402 utilizes.

Being able to handle Bitcoin transactions is fine, but it's disingenuous to act like it's the only way to be truly decentralized.

People want to transact in dollars.

Blockchains are fast and and cheap now! Modern blockchains like Base, Solana, Sui (and many more) typically have block times <2 seconds, and a stablecoin transfer can cost as little as $0.0005 independent of the $ amount being transfered

Coinbase, Kraken, etc... would. And they connect to your bank, so it doesn't seem like a problem if banks don't want to get involved.

Would you have said the same if I told you last year that the president and first lady would each have a memecoin?

Anchorage appears to already support Base.

As long as the agentic browser can automate my PirateBay tasks, I don't intend to overcomplicate it with payments and such.

Yep! Here: https://www.x402.org/ecosystem

New Internet Business Model https://blog.cloudflare.com/cloudflare-2025-annual-founders-... discussed yesterday https://news.ycombinator.com/item?id=45334599

It's pretty trivial to set up, here's a link to the docs: https://x402.gitbook.io/x402

Transactions confirm every 2 seconds on Base, and preconfirm even faster (every 200ms); there's no lag from a peer to peer payments perspective since they settle so quickly.

Through account abstraction and spend permissions, you also don't have to wait and authorize every single payment. It's a customizable from a developer perspective depending on how they want to build out their application.

In Brazil we already have a free, instantaneous payment system with a well documented API

https://github.com/bacen/pix-api

As much as I like SEPA it is primarily for bank transfers.

The way that payments work through SEPA is that the merchant pulls the money from your account. Legally they require a "mandate" - this can be as little as a handwritten signature on a document.

Security is essentially provided by easy reversal and strong penalties for abuse.

Is there also no fee for merchants? I thought business accounts are usually not as cheap as (or free like) consumer ones, some (all?) iirc pay per transaction or have tiers

It's also really hard to interface with. Afaik, I can't simply get an API token from my bank and send 2-cent transactions to pages I read if they'd publish the IBAN as part of an HTTP header or meta tag for example. Nor do I know that my bank would be happy about a thousand tiny transactions each month

SEPA (and all other sorts of payment processors) don't work for micro payments, because no one wants to forward a 5cent payment, or they will charge another 20cent as a fee. We had the WebPayments API fail over exactly this.

USA has started a FedNow program to make, basically, ACH faster.

Will take ages for that to become a browser extension, or embed. Too many parties make money off the current way. Similar to the health "care" ("insurance") in USA

>Given that this runs atop Payment Required, doesn’t this mean that each API request would involve an extra one or two data transfers?

Yes, assuming its the first time you've interacted with an API endpoint and don't have cached payment requirements.

>Is there a reason why you wouldn’t pay ahead of time? I just understand why you couldn’t buy a few dozen/hundred/thousand dollars worth of credits, and wait until it runs low.

This would require manually integrating each vendor, which is totally valid if your agent performs a lot of a single type of task, but we suspect over time there will be huge value in agents being able to dynamically select tools / apis they want to use to accomplish their tasks, and dynamically pay for what they use

Nothing, it's just a stupid thing for making some headlines, and will be forgotten tomorrow.

Basically, this fancy "protocol", is just a HTTP middleware that throws a payment required error and returns a crypto address lol.

> Is there a reason why you wouldn’t pay ahead of time? I just understand why you couldn’t buy a few dozen/hundred/thousand dollars worth of credits, and wait until it runs low.

Maybe you want to buy the service that is priced the lowest at the moment. Example: providers of inference services could drop their prices if they are underutilized. You could then have your system check for the best price and purchase only what is needed at the best price.

I think the purpose is so that your agent can do things like buy airline tickets for you. Using x402 it doesn't have to go through a typical credit card checkout process, which might have a lot of safeguards that make sure there's an actual human on the other end (captchas, etc)

How would non corporate payment rails look like?

>Does x402 prevent the double-spending problem?

This depends on the implementation on the underlying network, but basically the spending signs an authorization for transfer, and the merchant either settles that onchain themselves or delegates to what is called a facilitator that settles on their behalf. On EVM chains for the exact payment scheme this leverages EIP-3009 signatures

And further proof HN is terrible with finance and making money in general.