> 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."
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.
(x402 author here) Thats actually exactly what the intention with x402 is. Merchants express to the buyer multiple ways that they accept payment and the buyer chooses the one they prefer.
As of right now stablecoins on various crypto rails are the major form (largely because they're the easiest to start with from a development standpoint), but as Cloudflare indicated in their blogpost, they're proposing a scheme that uses deferred payment via credit card or ACH https://blog.cloudflare.com/x402/.
Hi Erik. Frankly, I wonder if this is an elaborate joke since there are some serious concerns in terms of CVP ("wait two seconds and retry"), in terms of gatekeeping potential nobody will sleepwalk in to ("we solve two the second wait with our CoinbaseCoin, get an enterprise subscription!"), or in terms of the inherent lack of openness in HTTP these days (client/server, HTTPS identity chains, DNS, gatekeepers like CloudFlare). For thoughts on a more open protocol without these drawbacks see https://raw.githubusercontent.com/globalcitizen/ifex-protoco... Sincerely, architect of a predecessor exchange (founder asked me not to continue work on open protocols).
> in SEPA, that offer instant and irreversible settlement at zero cost.
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).
How would you make it open and decentralized without crypto? I mean, you say it's only open if it supports all currencies, but I say it's only open if it supports all users and use cases, and that's a thing that non-crypto currencies don't do (except for Liberty Reserve, which got shut down by the government for precisely this reason). Like, it's not really open if they have the option to require you to have a Wells Fargo account. We're not falling for the HTTP Cloudflare-great-firewall trick again, I hope.
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.
Open just means the implementers of the protocol can select the settlement methods. Cryptocurrency allows in band settlement, but there is nothing wrong in principle with trusting finance institutions that the money really reached your account. So the settlement can be done out of band, using non-blockchain methods by mutually trusted financial institutions, just like credit card payments. It's cheaper, faster, simpler etc.
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).
The nature of the transaction itself is fundamentally different in a paygated/trustless API request.
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.
There are modern banks-connected (including PBs) finance firms that offer modern protocols and can facilitate payments quickly and nicely (offering both custodial And non-custodial services).
I support one of the similar projects in my organisation and I can't wait for golive.
Given that this protocol is Coinbase sponsored, you can be sure that the whole KYC/AML bullshit is going to be applied to every transaction.
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.
> Given that this protocol is Coinbase sponsored, you can be sure that the whole KYC/AML bullshit is going to be applied to every transaction.
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.
This is one of the US political instruments, and not part of the society. Money existed for like 4,000 years before KYC/AML, and the society was just fine in regards to money.
The protocol boast "no fee" but that's deceptive: if it's based upon a blockchain, there will be transaction fees.
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.
According to that site Base USDC fee is 1/8th of a cent. The x402 whitepaper says 1/100th of a cent so I'm not sure what accounts for the discrepancy; maybe Coinbase is willing to subsidize fees in some cases.
> if it's based upon a blockchain, there will be transaction fees
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.
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.
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.
The choice of name comes off as shady to me; seems like a marketing hack to make it sound like it's some kind of internationally-accepted standard, like oh, X.500.
Oh, and if you were wondering, yes, there is already an X.402[1] out there.
My experience using this, I picked "Frame" from their list of clients.
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.
No mention of Lightning or Bitcoin in the entire whitepaper. Just Base - a L2 rollup on Etherum developed by Coinbase which is behind the x402 standard. Hope this goes nowhere, clearly Coinbase has too much interest in pushing its own stack. Free and open payments should be bitcoin based to be truely decentralized, on Layers-2 such as Lightning or Liquid.
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:
* 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.
That is why I said Layer-2, like Lightning. That is not difficult at all, there are already successfull, workable solutions that allow for automated micro-payments (alby, or Nostr's zaps).
Debatable but IMO Lightning is still nascent even to this day. There is no real large ecosystem of interactive web applications available in-browser that you can build 402 offerings on top of. The EVM is light years ahead.
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.
It is a bit unfair to say you cannot build any x402 offerings on top of lightning, when the very same driving force behind x402 (=Coinbase) didn't design it to, but instead pushes it's very own corporate technology into the standard (Base). There is no technical limitation in lightning that wouldn't allow it to be integrated into a standard - if you design that standard accordingly.
See also L402 (previously LSAT), which has been in production use for half a decade at this point, by Lightning Labs (for their products Loop & Pool) via their Aperture proxy.
> It's really difficult to build agentic applications on top of Bitcoin.
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.
Hinges on you definition on truly decentralized. ETH is not truly decentralized (and never will be since their shift to proof-of-stake) as there is no way of not-knowing that the majority stake is not in a single force (or a conspiring group) - which in theory could already be the case. Absence of the counterproof and presence of a case where it would be centralized can never make it truly decentralized.
That's not really a valid criticism. You can say that same thing about any protocol. Who's to say that the majority of btc hashing power isn't single force or conspiring group?
What's the easiest way to do this with a stablecoin?
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.
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.
Yeah I understand that if someone generates a key then burns it, there's no way to know. But it was shocking for me to realize that there doesn't seem to be a universal mechanism to ensure you are sending something to *the correct blockchain*. The sender should know what chain their coins are on, so if the recipient embeds that metadata in the address or QR code, some basic validation should be possible.
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?
I'm thinking about how to reduce honest everyday mistakes where the wrong address is entered, not preventing malicious actors from taking coins. Something to ensure they sent money to a wallet on the right chain, that was expecting their tx.
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.
> Something to ensure they sent money to a wallet on the right chain, that was expecting their tx.
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.
> What's the easiest way to do this with a stablecoin?
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.
Interesting. I couldn't get that working with Coinbase wallet or Metamask from FF on Android.
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?
I don’t know who at Coinbase discerned that HTTP 402 is unused. There are sites that return 402 and a relevant “pay your bill to continue” page out there. Not all of them will suddenly support this blockchain payment method.
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.
At the bottom of the page, it reads "By using this site, you agree to be bound by the CDP Terms of Service and Global Privacy Policy."
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'.
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
Yeah, it's mostly bitcoin that's slow. SOL is sub-second, AVAX has a new architecture that has gone from a few seconds to sub-second, and while I have never used SUI I believe that one too is sub-second. ETH is still relatively slow, but not bitcoin slow.
glad some people trying to make this. I've had the same idea in 2015 back when bitcoin was the only widely used cryptocurrency: https://www.jcfrei.com/the-ai-economy-bitcoin/ now with stablecoins and much faster chains it makes even more sense
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.
As opposed to blockchain where reversal depends on the grace of the merchant.
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.
I'm sorry but I'm big into crypto and have never seen a contract like that deployed in the wild.
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.
You've never staked a token? Every single major chain and most exchanges have staking contracts deployed which are essentially the same thing (you can't access your tokens until an oracle says so, or you cancel out).
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
> Will take ages for that to become a browser extension, or embed.
"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.
Has anyone tried this out and can say how long it takes?
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.
> 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.
More crypto and more microtransactions - look what a place the web has become... I don't see why we can't just happily hobble along our free cute little information highway and why capitalism has nowadays infused the internet with a rage for money-making.
This whole thing seems very strange to me, but maybe I’m missing the point.
> 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?
> 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.
>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
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)
Airlines pretty much need to know their customers no matter how they get paid. Wouldn’t you just be moving that to another part of the process in that example?
API clients can already easily identify the user during the authentication process. What’s currently “missing” is a way for an API client to pay a service via the API call “on the fly”, without having a credit card on file or some prior account balance.
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.
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
> 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.
> 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.
> 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?
What do you mean? Perhaps some HN users prefer traditional financial vehicles instead of something that could be fly-by-night.
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.
18 years ago: https://www.reddit.com/r/WTF/comments/6hc3w/comment/c03udg0/
> "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.
For those who are interested in origins, a Coinbase sponsored protocol.
With Stripe moving into the space heavily and looking to lock things up in "Stripe-land", I think having an open protocol is great.
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.
(x402 author here) Thats actually exactly what the intention with x402 is. Merchants express to the buyer multiple ways that they accept payment and the buyer chooses the one they prefer. As of right now stablecoins on various crypto rails are the major form (largely because they're the easiest to start with from a development standpoint), but as Cloudflare indicated in their blogpost, they're proposing a scheme that uses deferred payment via credit card or ACH https://blog.cloudflare.com/x402/.
Thanks for stopping by.
Hi Erik. Frankly, I wonder if this is an elaborate joke since there are some serious concerns in terms of CVP ("wait two seconds and retry"), in terms of gatekeeping potential nobody will sleepwalk in to ("we solve two the second wait with our CoinbaseCoin, get an enterprise subscription!"), or in terms of the inherent lack of openness in HTTP these days (client/server, HTTPS identity chains, DNS, gatekeepers like CloudFlare). For thoughts on a more open protocol without these drawbacks see https://raw.githubusercontent.com/globalcitizen/ifex-protoco... Sincerely, architect of a predecessor exchange (founder asked me not to continue work on open protocols).
> in SEPA, that offer instant and irreversible settlement at zero cost.
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).
What's the difference between spending USDC and USD via a credit card? I don't get the hatred for anything crypto.
How would you make it open and decentralized without crypto? I mean, you say it's only open if it supports all currencies, but I say it's only open if it supports all users and use cases, and that's a thing that non-crypto currencies don't do (except for Liberty Reserve, which got shut down by the government for precisely this reason). Like, it's not really open if they have the option to require you to have a Wells Fargo account. We're not falling for the HTTP Cloudflare-great-firewall trick again, I hope.
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.
Open just means the implementers of the protocol can select the settlement methods. Cryptocurrency allows in band settlement, but there is nothing wrong in principle with trusting finance institutions that the money really reached your account. So the settlement can be done out of band, using non-blockchain methods by mutually trusted financial institutions, just like credit card payments. It's cheaper, faster, simpler etc.
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).
[dead]
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 nature of the transaction itself is fundamentally different in a paygated/trustless API request.
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.
There are modern banks-connected (including PBs) finance firms that offer modern protocols and can facilitate payments quickly and nicely (offering both custodial And non-custodial services).
I support one of the similar projects in my organisation and I can't wait for golive.
FIS is just waiting for them to pay $250k/enabled API call to make it happen...
Given that this protocol is Coinbase sponsored, you can be sure that the whole KYC/AML bullshit is going to be applied to every transaction.
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.
> Given that this protocol is Coinbase sponsored, you can be sure that the whole KYC/AML bullshit is going to be applied to every transaction.
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.
Fortunately crypto exists. Fortunately, it is perfectly usable in real world while avoiding most of the KYC/AML crap.
Honestly, probably not for long. Like, basically any Western headquartered crypto company will have (at least in theory) KYC/AML checks.
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).
This is one of the US political instruments, and not part of the society. Money existed for like 4,000 years before KYC/AML, and the society was just fine in regards to money.
The protocol boast "no fee" but that's deceptive: if it's based upon a blockchain, there will be transaction fees.
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?
> 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/
According to that site Base USDC fee is 1/8th of a cent. The x402 whitepaper says 1/100th of a cent so I'm not sure what accounts for the discrepancy; maybe Coinbase is willing to subsidize fees in some cases.
Gas is variable, but Coinbase currently subsidizes x402 transactions that go through our facilitator
> if it's based upon a blockchain, there will be transaction fees
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.
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.
Coinbase's blockchain (Base) generally has sub-cent send fees for USDC. Solana's fees are also in that ballpark.
Nano has 0 transaction fees in the sense that you have to do some work function instead to prevent spam
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.
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.
all these are solvable problems
we can get decentralized systems to sub 0.0000000000001 cent fees. Fee volatility Wille xist but thats a prerequisite for openness.
There is some Blockchains where the fees are super low, like Solana
The choice of name comes off as shady to me; seems like a marketing hack to make it sound like it's some kind of internationally-accepted standard, like oh, X.500.
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
My experience using this, I picked "Frame" from their list of clients.
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.
No mention of Lightning or Bitcoin in the entire whitepaper. Just Base - a L2 rollup on Etherum developed by Coinbase which is behind the x402 standard. Hope this goes nowhere, clearly Coinbase has too much interest in pushing its own stack. Free and open payments should be bitcoin based to be truely decentralized, on Layers-2 such as Lightning or Liquid.
> 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:
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:
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.
If he was, he wouldn't be shilling blockstream solutions.
This already exists (L402 -- formerly known as LSAT), and pre-dates x402 by several years:
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.
That is why I said Layer-2, like Lightning. That is not difficult at all, there are already successfull, workable solutions that allow for automated micro-payments (alby, or Nostr's zaps).
Debatable but IMO Lightning is still nascent even to this day. There is no real large ecosystem of interactive web applications available in-browser that you can build 402 offerings on top of. The EVM is light years ahead.
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.
It is a bit unfair to say you cannot build any x402 offerings on top of lightning, when the very same driving force behind x402 (=Coinbase) didn't design it to, but instead pushes it's very own corporate technology into the standard (Base). There is no technical limitation in lightning that wouldn't allow it to be integrated into a standard - if you design that standard accordingly.
See also L402 (previously LSAT), which has been in production use for half a decade at this point, by Lightning Labs (for their products Loop & Pool) via their Aperture proxy.
https://l402.tech/
> It's really difficult to build agentic applications on top of Bitcoin.
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.
You profile says "Ex-Coinbase" employee. 'Nuf said.
Also ex-Base! Gee whiz.
True, involvement with the Base team at Coinbase: https://wbnns.com/ (bottom, "Decrypt"). Somebody has stake in the game (pun intended).
Being able to handle Bitcoin transactions is fine, but it's disingenuous to act like it's the only way to be truly decentralized.
Hinges on you definition on truly decentralized. ETH is not truly decentralized (and never will be since their shift to proof-of-stake) as there is no way of not-knowing that the majority stake is not in a single force (or a conspiring group) - which in theory could already be the case. Absence of the counterproof and presence of a case where it would be centralized can never make it truly decentralized.
That's not really a valid criticism. You can say that same thing about any protocol. Who's to say that the majority of btc hashing power isn't single force or conspiring group?
oh with truly decentralized you mean like “verifiably” decentralized in the same sense as a scientific truth right?
I was a bit confused at first but I now get the criticism.
bitcoin is decentralized in name only.
People want to transact in dollars.
As an European I very much want to transact in Euros.
Cloudflare using it: https://blog.cloudflare.com/x402/
What's the easiest way to do this with a stablecoin?
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.
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.
Yeah I understand that if someone generates a key then burns it, there's no way to know. But it was shocking for me to realize that there doesn't seem to be a universal mechanism to ensure you are sending something to *the correct blockchain*. The sender should know what chain their coins are on, so if the recipient embeds that metadata in the address or QR code, some basic validation should be possible.
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.
Huh interesting idea.
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.
I'm thinking about how to reduce honest everyday mistakes where the wrong address is entered, not preventing malicious actors from taking coins. Something to ensure they sent money to a wallet on the right chain, that was expecting their tx.
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.
> Something to ensure they sent money to a wallet on the right chain, that was expecting their tx.
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.
> What's the easiest way to do this with a stablecoin?
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.
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...
Interesting. I couldn't get that working with Coinbase wallet or Metamask from FF on Android.
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?
I don’t know who at Coinbase discerned that HTTP 402 is unused. There are sites that return 402 and a relevant “pay your bill to continue” page out there. Not all of them will suddenly support this blockchain payment method.
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.
At the bottom of the page, it reads "By using this site, you agree to be bound by the CDP Terms of Service and Global Privacy Policy."
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'.
Working with banks and payment processors during a 15-year period, I can with 1.000% certainty say - no sane Bank will touch this with a 10-foot pole.
Not now, not in 20 years.
Would you have said the same if I told you last year that the president and first lady would each have a memecoin?
You mean a ponzi scheme, right?
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.
Thankfully it doesn't matter because this happens on a blockchain so banks can go pound sand with their restriction and KYC/AML horseshit.
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.
Anchorage appears to already support Base.
I am developping an open source x402 Java stack and I love this protocol ! You can see my projet ar https://mogami.tech
Anchor Browser has documentation here showing how to combine x402 with an agentic browser session.
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.
As long as the agentic browser can automate my PirateBay tasks, I don't intend to overcomplicate it with payments and such.
> Instant settlement
> 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 ?
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
Yeah, it's mostly bitcoin that's slow. SOL is sub-second, AVAX has a new architecture that has gone from a few seconds to sub-second, and while I have never used SUI I believe that one too is sub-second. ETH is still relatively slow, but not bitcoin slow.
> Are crypto payments instant now ?
Practically speaking yes.
There are now chains with sub-second Time to Finality and sub-cent gas fees (this was not true ~3 years ago)
Which chains have sub second block times?
SOL, AVAX, SUI
A big step towards agentic payments and commerce.
I am excited to see how people will use this. Are there any sites actively allowing to use it rn?
Yep! Here: https://www.x402.org/ecosystem
glad some people trying to make this. I've had the same idea in 2015 back when bitcoin was the only widely used cryptocurrency: https://www.jcfrei.com/the-ai-economy-bitcoin/ now with stablecoins and much faster chains it makes even more sense
Why not look at sepa? There's a whole continent that already solved this? Ticks all the boxes:
- No fee
- Instant
- Blockchain agnostic
I mean for the actual settlement obviously.
https://en.m.wikipedia.org/wiki/Single_Euro_Payments_Area
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.
As opposed to blockchain where reversal depends on the grace of the merchant.
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.
One of the most common examples of smart contacts is a reversible transaction with dispute resolution by a third-party.
Infact you could implement exactly what you suggest in a similar way.
I'm sorry but I'm big into crypto and have never seen a contract like that deployed in the wild.
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.
You've never staked a token? Every single major chain and most exchanges have staking contracts deployed which are essentially the same thing (you can't access your tokens until an oracle says so, or you cancel out).
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.
What do you mean?
I just tried transferring 0.01€ and it showed 0€ in transaction fees.
Not sure what you're on about.
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
> Will take ages for that to become a browser extension, or embed.
"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.
In Brazil we already have a free, instantaneous payment system with a well documented API
https://github.com/bacen/pix-api
Has anyone tried this out and can say how long it takes?
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
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.
Looks like a competitor to the A2P that google released....
No, they're working together on it
> 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...
What about GNU taler?
What about it?
I looked at this space about 3 years ago, what I want seems to still not exist
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.
> - payment-level fraud protection > - payment-level kyc
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.
Does stablecoin send/receiving via stablecoins or Lightning not work? Is it too difficult to get a user to pay? x402 should work just fine?
Tempo might be good for this once it comes out.
More crypto and more microtransactions - look what a place the web has become... I don't see why we can't just happily hobble along our free cute little information highway and why capitalism has nowadays infused the internet with a rage for money-making.
New Internet Business Model https://blog.cloudflare.com/cloudflare-2025-annual-founders-... discussed yesterday https://news.ycombinator.com/item?id=45334599
The free web hasn't gone anywhere. You're using it now aren't you, on HN?
Isnt the speed of the blockchain still rediculously slow?
> dormant 402 HTTP status code
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.
This whole thing seems very strange to me, but maybe I’m missing the point.
> 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?
> 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.
>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.
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)
Airlines pretty much need to know their customers no matter how they get paid. Wouldn’t you just be moving that to another part of the process in that example?
API clients can already easily identify the user during the authentication process. What’s currently “missing” is a way for an API client to pay a service via the API call “on the fly”, without having a credit card on file or some prior account balance.
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.
basically a copy of l402.org
Corporate capture of payment rails, masquerading as open payments.
How would non corporate payment rails look like?
The Lightning Network (an open payment layer built on top of Bitcoin) or some other cryptocurrency.
This is built on top of crypto currency.
That would be nice... Good luck to you if you can use it.
I would consider myself tech savvy but I struggled immensely to run lightning without custodial risk back.
Perhaps something like https://github.com/stellar/basic-payment-app/blob/main/src/r...
Look at how Nostr does it with lightning micropayments ("zaps"). No middlemen needed.
How are Hashed Timelock Agreements (HTA) like in the Interledger Protocol (ILP) and WebMonetization Protocol more secure than x402?
Does x402 prevent the double-spending problem?
Isn't it regressive to return to dependence on DNS for financial transactions?
>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
ILP (Ripple, FedNow,) has Connectors. I just had this conversation about "Intents" and ILP Connectors: https://news.ycombinator.com/context?id=45296648
"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?
Oh no, apparently this crypto shit is not dead yet.. :(
And further proof HN is terrible with finance and making money in general.
What do you mean? Perhaps some HN users prefer traditional financial vehicles instead of something that could be fly-by-night.
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.
Cryptocrap. Pass.
Interesting, how does that work?
10 secs into it, Blockchain
Close tab