X402 — an Open Protocol for Internet-Native Payments
Posted3 months agoActive3 months ago
x402.orgTechstoryHigh profile
controversialmixed
Debate
80/100
BlockchainPaymentsCryptocurrency
Key topics
Blockchain
Payments
Cryptocurrency
The x402 protocol, an open protocol for internet-native payments backed by Coinbase, has been released, sparking debate among HN users about its potential, security, and the role of blockchain in payments.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
47m
Peak period
95
0-6h
Avg / period
16.3
Comment distribution147 data points
Loading chart...
Based on 147 loaded comments
Key moments
- 01Story posted
Sep 23, 2025 at 10:14 AM EDT
3 months ago
Step 01 - 02First comment
Sep 23, 2025 at 11:01 AM EDT
47m after posting
Step 02 - 03Peak activity
95 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 25, 2025 at 5:05 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45347335Type: storyLast synced: 11/20/2025, 7:50:26 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
With Stripe moving into the space heavily and looking to lock things up in "Stripe-land", I think having an open protocol is great.
I support one of the similar projects in my organisation and I can't wait for golive.
This is different from an API schema of a /payments/ endpoint being segregated from the actual resource that is being paid for.
In this model, the payment is the cost of entry for the resource request itself. It's not as directly applicable to all payment scenarios, but enables a new class of transaction that is effectively pay-per-request.
It's worth noting that this protocol is primarily supported by Coinbase today -- You'd be using USDC on the Base network (Layer 2 on top of Ethereum). However, the protocol itself is opening meaning anyone can self-host the same mechanics on any network, with any token/crypto asset.
It's entirely possible then that some options would be available, for example in SEPA, that offer instant and irreversible settlement at zero cost.
And for crypto payments they already don't need this because they can use the de-facto-standard Metamask API, at least for Ethereum-compatible blockchains.
It's an economic and business problem, not a technical one: the incumbents earn massive fees and have very little incentive to innovate, while the disruptors can't reach the minimum critical mass they require to get rid of the damn credit cards (aka static passwords you need to disclose on the internet).
Note that SEPA is 100% not reversible. In fact, if you look at the scheme terms is absurdly reversible. There's a 8 week no questions asked refund window, so (for instance) one could pay your mortgage with SEPA and then automatically undebit their account up to 8 weeks later.
(Don't do this unless you're happy losing your property, not financial advice).
You might be referring to SEPA direct debit, which can be reversed unilaterally by the client at any point during the 8 weeks. These are payments initiated by the merchant, using an already established direct debit channel.
Want to read a paid message? Please upload your recent utility bill and confirm your identity with a video call. Sorry, you are not a US citizen with possession of the only subset of ID documents we support, reject.
Unfortunately (or fortunately, depending on perspective), this is the law basically everywhere where people have money. Like, you can avoid KYC/AML checks by using small operators, but as they get larger they'll have to introduce them or be regulated out of existence.
If you really hate this (which is a valid position that I mostly don't share) then you should either run for elected office or sponsor/help other people to do this, as that's the only way to change the law.
Fundamentally, as the internet ends up mapping to just society, it will be a reflection of society, much of which is driven by government regulation.
And I'm not sure how you plan to get your crypto into fiat without hitting a bank/financial institution which will have these checks.
Like, this is part of society (for some good and some bad reasons, like a lot of other things).
I wish you the very best of luck in colonising mars, as this is basically the only way you'll avoid KYC/AML in the long-term.
More seriously, I'd probably start making provisions for taxation of your crypto as it would really suck to have that happen unexpectedly (and it will, as governments start forcing financial/crypto institutions to report to them).
> Money existed for like 4,000 years before KYC/AML, and the society was just fine in regards to money.
As an aside, money is relatively recent, debt is the thing that's existed for much longer. And unfortunately, society determines what is important, and apparently society (well actually the US government) has decided that KYC etc matters to society.
Not really.
As it is customary with financial law, it only exists to make hard working people suffer, while leaving all the ways for criminal enterprises to continue business. Being Ukrainian person I can tell you with confidence that legalizing personal 1000 USDT made on a freelance job is harder than laundering $1m made by corruption by government officials.
Also, KYC/AML is not binary, it's a scale. I have no problem KYCing at my local Polish bank and sending my crypto transactions to my bank account and they are fine with it as well as long as they know who I am.
> in the long-term.
True. Operating a legitimate (!) clear business, say, in Singapore remotely from Ukraine was a routine thing like ten years ago and became almost impossible in 2020s - specifically due to American regulatory pressure. Again, we're talking about lawful businesses. Criminal enterprises have no problems opening bank accounts anywhere they want.
> (well actually the US government) has decided that KYC etc matters to
...American political interests. KYC/AML is detrimental to economic growth and harmful to the society as been demonstrated time and again.
Can you give me some more details on this? My understanding was that only the sanctioned parts of Ukraine were impacted by recent changes, but perhaps I'm wrong.
First of all, banks couldn't care less about telling apart different species of Ukrainian people. Second, for any bank in the world it's a matter of cost of finmonitoring. And for each and every customer the cost of compliance is always higher than the profit from this person's transaction. Therefore, banks have strong incentive to refuse service for any person that is remotely unordinary. Hence "debanking": https://en.wikipedia.org/wiki/Debanking
- No fee
- Instant
- Blockchain agnostic
I mean for the actual settlement obviously.
https://en.m.wikipedia.org/wiki/Single_Euro_Payments_Area
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
"ACH faster" cannot and should not become a browser extension, ever.
You could instead argue that the Fed ought to additionally implement a blind signature service a la Digicash. Then customers could make anonymous digital cash payments to participating banks and businesses. (I.e., the recipient is known but the payer isn't.)
Would you advocate for that? If so, you'd have to battle way more cryptobros than Visa/Mastercard lobbyists. Hell, the cryptobros are already spamming Youtube saying ISO 20022 is an evil conspiracy by banking incumbents. And that's just an XML messaging spec!
Imagine the pushback here on HN if you seriously pushed for the fed to do proper digital cash.
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.
I've often wondered whether payments providers entering the blockchain space (like Visa/Mastercard) would act as trusted intermediaries for dispute resolution. Kind of a 2-of-3 multisig to disperse the funds in escrow.
Infact you could implement exactly what you suggest in a similar way.
And I actually use crypto for payments more than most people. I used some just last week to buy a replica rolex from a chinese dealer because they gave a better price than credit cards.
I just tried transferring 0.01€ and it showed 0€ in transaction fees.
Not sure what you're on about.
And if you start receiving hundreds of 0.01c transfers into your private bank account, you will receive a friendly phone call from you bank very soon.
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
https://github.com/bacen/pix-api
I would consider myself tech savvy but I struggled immensely to run lightning without custodial risk back.
Does x402 prevent the double-spending problem?
Isn't it regressive to return to dependence on DNS for financial transactions?
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
"Powering AI commerce with the new Agent Payments Protocol (AP2)" https://cloud.google.com/blog/products/ai-machine-learning/a... :
> AP2 builds trust by using Mandates—tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions. These mandates are signed by verifiable credentials (VCs) and act as the foundational evidence for every transaction.
google-a2a/a2a-x402: A2A x402 extension: https://github.com/google-a2a/a2a-x402
SingularityNET is this concept too, FWIU. https://github.com/singnet
So A2A has W3C VC Verifiable Credentials (and DIDs), but not x402?
Re: ILP payment pointers, DNS, blockerts (W3C VC) https://news.ycombinator.com/item?id=42961635 :
> How can or should a Blockcert indicate an ILP Interledger Protocol address or a Payment Pointer?
In order to avoid DNS. Basically because gethostbyname() does not indicate DNSSEC validation status, or channel sec status e.g. whether there's DoH/DoT/DoQ at every edge in the DNS network), or CT Certificate Transparency log cert revocation status (and OCSP and CRL are in-band))
How can ILP and x402 (and IDK EDNS) be integrated? Are they complementary?
> Think of x402 as the universal "cash register" signal and ILP as the versatile "payment network" that can handle any currency. [...] and pathfinding with path cost and HTA Hashed-Timelock Agreements for the whole path, with an auditable open spec message standard that accounts for each of the Connectors involved (who specify credit limits).
> So, x402 can signal the need for a payment, and ILP can be the underlying mechanism to fulfill that payment request, regardless of the user's preferred currency or payment provider
How do x402 and ILP SPSP Simple Payment Setup Protocol compare in terms of signaling the need for a payment?
> SPSP is a simplified, connectionless mode of Interledger that is often used for streaming micropayments, as seen in the Web Monetization standard. The signaling is more implicit and is discovered through HTML/HTTP, rather than being an HTTP status code itself.
From "HTTP 402: Payment Required" (2020) https://news.ycombinator.com/item?id=22214156 :
> The new W3C Payment Request API [4] makes it easy for browsers to offer a standard (and probably(?) already accessible) interface for the payment data entry screen, at least. https://www.w3.org/TR/payment-request/
There's probably a better HTTP Status dog for 402?
https://anchorbrowser.io/blog/pay-to-win-coinbase-x402-ancho...
We are not far off from humans giving a monthly allowance to their agentic counterparts.
> API services paid per request
Given that this runs atop Payment Required, doesn’t this mean that each API request would involve an extra one or two data transfers?
> AI agents that autonomously pay for API access
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.
> Paywalls for digital content
Isn’t this crypto only? The overlap of people paying for digital content and dealing with crypto must be relatively small. Is it meant to funnel people to a payment portal, going through fiat, à la Coinbase?
> Microservices and tooling monetized via microtransactions
How is this different than the API point?
> Proxy services that aggregate and resell API capabilities
I’m not a huge backend person, but what would be the purpose of this?
Maybe a better example is an image generation api. Your agent chooses one based on its research, and without any account or credit card on file, it buys you an image using a x402.
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
Basically, this fancy "protocol", is just a HTTP middleware that throws a payment required error and returns a crypto address lol.
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.
The flowchart on the back-end looks pretty involved, needing to publish transactions on the chain and get confirmations. For Bitcoin, that takes upwards of like 15 minutes depending on what block depth the receiving party cares about and stuff. Even foregoing that and just listening for conflicting transactions being broadcast for a few seconds, that's an annoying delay to open a page. Not to mention dealing with the UI to authorize a specific payment for every damn page on paywalled news websites
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.
x402 might end up being more legitimate, yet the ecosystem page doesn't inspire confidence - I only recognized node and the rest feel rag tag. Let's not kid ourselves into thinking that this space hasn't been problematic before, so skepticism is warranted.
I'm by no means against Lightning, it's just got a long road of ecosystem, development and better UX ahead of it before we see general mainstream adoption. At the moment, bitcoin's killer feature is holding bitcoin. Most people don't know what Sats are. There are few bitcoin-payable apps. Few stable assets that remove volatility for every day payments like you would need with 402. Stuff like that.
https://l402.tech/
That's because brain power is being corralled around entities that seek to maintain their control as toll keepers of financial transactions. They have to modernize and they must do it through centralized blockchains to maintain their control.
I was a bit confused at first but I now get the criticism.
Agreed. Which is why 5 years ago, I developed L402 (formerly known as LSAT) to fill this very gap:
The x402 protocol as defined uses purely out of band payment verification. This trait makes the "one line of code" to add integration not entirely accurate, as there's still a substantial amount of code needed at both the client and server to verify payment receipt.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:
Now if the problem they want to solve is the case of low amount payments (they claim "no high minimum") then a percentage fee is not an issue, but a per-transaction fee can be absolutely massive. Also depending on the blockchain, you're exposed to fee volatility, which might be another issue.
Am I missing something here?
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/
Obligatory self promotion https://www.youtube.com/watch?v=8hHG8gOkZBE & https://github.com/SerJaimeLannister/randomnano & just because I am lazy and I had never written what this software is except in one comment on HN which I am also going to link lol which is going to be best that I can sum it up with https://news.ycombinator.com/item?id=44700680
Which loops through a lot of transactions with a custom nano vanity id generator to embed data into blockchain which would have 0 gas fees.
Want to do something with it one day but not sure how to, or even if its worth it given the decentralized nature and Like, I want to really play with it once I can secure myself a college and then a job & maybe I will do it in my side project.
Not necessarily. Crypto wallet can authorize expense just by signing something and sending that signature. No blockchain transaction takes place. Then these signatures are batched.
we can get decentralized systems to sub 0.0000000000001 cent fees. Fee volatility Wille xist but thats a prerequisite for openness.
Not now, not in 20 years.
Given that this is Coinbase sponsored I'm not sure this will be even available to the people of the world despite being on blockchain.
> AP2 is designed as a universal protocol, providing security and trust for a variety of payments like stablecoins and cryptocurrencies. To accelerate support for the web3 ecosystem, in collaboration with Coinbase, Ethereum Foundation, MetaMask and other leading organizations, we have extended the core constructs of AP2 and launched the A2A x402 extension, a production-ready solution for agent-based crypto payments. Extensions like these will help shape the evolution of cryptocurrency integrations within the core AP2 protocol.
[0] https://cloud.google.com/blog/products/ai-machine-learning/a...
> Accept payments at the speed of the blockchain. Money in your wallet in 2 seconds, not T+2.
Are crypto payments instant now ?
I don't follow this space at all but my understanding was that the "speed of the blockchain" was pretty slow.
Or maybe they mean this compared to payment processors or bank transfers that can take days ?
Base has sub-second block times, but because it's an Ethereum L2, it technically has ~15min TTF
Practically speaking yes.
When I looked at USDC recently at the end of the tutorial I was following there was a throw way "and don't forget you need ethercoin too, to pay the gas transaction fee." That was after all the warnings about not sending to the wrong address or block chain. (Stable coins are on a bunch of block chains and apparently you are required to manually ensure the sender and receiver are on the same chain, otherwise your coins go bye bye)
What's the point of I need a bunch of other coins and it's so complicated? This complexity and required tinkering seems like the kind of thing cryptocurrency nerds love, but is too complicated for someone just trying to make a payment.
Is there a contract structure that obviates the need for Ether, or in there somewhere am I buying ether and USDC from somewhere and I just don't see that interaction?
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.
In L2 it seems like a "handshake" should be possible as well. Eg Where the sender sends in infinitesimal amount of coins, and the recipient moves the funds in a way the sender can see, so the sender knows the funds sent were accessible.
You could probably build something like this on Solana or the EVM directly. The thing is, if you get the address of the recipient wrong, how can you tell? Like if I send SOL to a payee, then I can look at the chain to make sure that SOL was sent from my address to the payee's address. But that doesn't change the fact that I don't know if the payee is who I think it is.
Are you thinking about situations where, say, you meet in person, then send an amount and have the recipient verify they received an amount, then send the rest? Like a multi-party escrow?
Third-party escrow contracts are very common.
It seems like improving the UX to reduce mistakes is solvable, and maybe there are solutions built, but I never see them in the guides.
SNS and ENS are the best ways I know. They're cryptocurrency-based naming solutions. You can pin your wallet address to a friendly name and pay for holding onto the friendly name like a domain name. Then if your wallet supports using an SNS or ENS address, you can just pay the payee on SNS or ENS. Right now 5+ character SOL names are for-life $20 USD (pinned to USDC), and you can make subdomains.
> It seems like improving the UX to reduce mistakes is solvable, and maybe there are solutions built, but I never see them in the guides.
From what I can tell, until 2018-2019-ish cryptocurrencies were still being widely thought of as payment rails. Then two things happened at once. ERC20 took off and memecoins became a thing, so the amount of gambling in cryptocurrency really shot up. That and added organic popularity to a lot of cryptocurrencies and Bitcoin's refusal to increase block size saw very high transaction fees.
A lot of crypto communities became filled with gambling and scam posts. This shift in focus both soured a lot of the bloggers/commenters which shifted some dev talent away and the remaining talent focused on trying to improve the fundamentals, relating to transaction fees, speeds, and on/offramps. The focus on UX really dropped off during that time.
The good news is now we have fast L1s (Solana, Monero, Bitcoin Cash, etc.) and L2s (including Lightning) so the transaction stuff became solved. Stablecoins offer stability where the actual crypto assets don't. Now there's more renewed focused on everyday usage of crypto and so there's a need to firm up the UX again.
You give a crypto wallet to an AI agent, and make sure it has some USDC.
> What's the point of I need a bunch of other coins and it's so complicated?
The point is that the CDP team built something that fits one of Coinbase's narratives du jour — agentic payments. It's simply a protocol for agentic payments. The team that built it doesn't even really know how it _should_ work or what the actual use cases are — but wouldn't it be cool if your AI agent had a crypto wallet, and instead of the agent getting pay-walled, they could just pay for stuff?
> This complexity and required tinkering seems like the kind of thing cryptocurrency nerds love, but is too complicated for someone just trying to make a payment.
I think that's a fair criticism. The Bridge/Privy/Stripe approach is wildly different, and focuses more on current problems.
I am looking to sell physical goods for low total amounts (<$10 usd) via a website. The most basic e-commerce you can imagine.
In particular, what I want:
- fast-ish payments (settlement in <2hr)
- low/zero per-payment cost, low % fee
- your average HN user could figure out how to use it to pay
What I don't need:
- subscriptions
- payment-level fraud protection
- payment-level kyc
- customer financing (a la Klarna)
- rev rec
It seems like Fednow or lightning would meet some (most?) of these requirements, but I have not yet seen it in the wild.
No one needs that. Not a single party to the transaction, however remote or secondary. Every participant absolutely hates those.
All of which doesn't matter, because the whole KYC/AML bullshit is forced on us and it is inevitable in the TradFi world.
> "This code is reserved for future use."
> For when AT&T, Comcast, TimeWarner, et. al. have succeeded in their plan to make the interweb a toll-road. "Oh, you want your packets to go to reddit.com? That will be $0.00015/per."
Redditor had the right idea, just wrong names.
10 secs into it, Blockchain
Close tab
Shouldn't that be at the top? If you want me to agree to a EULA no one would read, at least make a show as if you expect people to read it, don't hide it in a disused lavatory with a sign on the door saying 'Beware of the Leopard'.
1. Getting USDC from the faucet was pretty easy 2. Connecting Frame to my browser worked well, x402 was immediately detected 3. The first transaction got lost, I submitted it and the page spun forever. I had to make a second transaction to make it work. If this was real money, it'd be super easy to make people pay twice, because my first transaction is probably languishing in a mempool somewhere. 4. Frame is a terrible tool to suggest. It has no transaction log, so once you commit you can't use any of the tricks like "send another transaction with the same nonce, but with more gas" in case it got lost. It also appears to be largely unmaintained. 5. Second transaction worked fine, processing was nearly instant, the feedback was good.
Just use 403 until payments are made. This seems like an unnecessary marketing focus on an error instead of the actual technology.
API payments don't need to happen on the fly, and it will probably be detrimental to their latency to do so.
Oh, and if you were wondering, yes, there is already an X.402[1] out there.
[1] https://www.itu.int/rec/T-REC-X.402/en