- The default seems to make the payment without confirmation. What stops an endpoint from changing payment amount between an inspect request and the actual request?
- Will adoption of this payment protocol ever grow large enough for anyone to implement this on either the client or server?
- Bots have more of a financial incentive to crawl sites than a human. I doubt this will actually stop anything
- I see a AGENTS.md. How much of this is vibe coded? It's near impossible to get a sense of the care taken to review LLM output. Hard to trust with money.
While I can understand the rationale behind it, I can't imagine this being used for anything that requires low latency requests.
I imagine the flow would be something like (correct me if I'm wrong) [client request] -> [backend returns an error]/[accepts the request and waits for payment] -> [client sends the money] -> [backend accepts the transaction] -> [backend returns the requested data]. All of this sounds like a huge bloat over the current API key/token system.
It's also the name of my business, chosen for the definition "(of a stream or river) flow with a swirling motion and babbling sound". I have to say, it's really unsettling when a behemoth like Stripe shows interest in a word you use for branding/identity, even in a totally unrelated industry. I doubt it matters, but I'd feel better if they just didn't
An annoying trend I've been seeing recently, which the GitHub repo behind this does, is having better documentation for the robots than there is for the users.
Compare the README.md to the skills/pay-for-http-request/SKILL.md
In the cryptocurrency world this has existed many years already. For example with the Lightning network on top of Bitcoin it has always been easy to let the server generate an invoice, which the client pays and then the client sends another request including cryptographic proof of the payment. On layer 2 it was always cheap and fast.
i don't love the HTML response for "payment required" endpoints, not least because it just asks the agent to install an arbitrary NPM package for "full wallet connection and payment UI". seems so easy to exploit maliciously - what's to distinguish genuine payment instructions with crypto stealers
user@NAS:~$ curl -fsSl https://www.purl.dev/install.sh | bash
...
purl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by purl)
user@NAS:~$ uname -a
Linux NAS 6.1.0-43-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1 (2026-02-08) x86_64 GNU/Linux
You know, it's funny. A while back people would've been building cURL alternatives/wrappers/collecting client header stacks designed to sidestep paywalls on web content (sidestep, at best).
With purl, the web gets just a little less punk. Which is nothing new, unfortunately. I miss the times when people would put in stupid amounts of effort to stick to their principles in hobby tech.
My first thought was that it would make payments easy for bots. It would be trivial to turn this into tool calls, so you'd just set up the wallet and let your bot go shopping.
Serve data to users at their expense instead of yours.
I've wanted something like this for a while. S3 Requester Pays kind of achieves the same thing but requires the requester to have a funded AWS account.
that's an interesting take, I'm curious to what a pricing model for a setup like that could look like at an enterprise tier
I could see stuff like how some B2C things sell stuff like PDF, videos, tutorials, at a flat-fee, but usually B2B enterprise ends up with a metered pricing so negotiating that could end up with many dynamic urls which sounds like a giant mapping table on top of the protocol
I'm thinking along the lines of wikis, archival projects, and yeah pay-per-view video/photo websites. Torrents only work for static data and aren't very performant.
This is a fair way to allow AI scraping too: you can let bots scrape as much as they like, as long as they cover the cost of serving that content. The bots don't have to enter payment information into every website they want to scrape.
Was wondering the same. There's a markdown table in `skills/pay-for-http-requests/SKILL.MD` that has a "common scenarios" section. It lists four examples with descriptions.
A couple questions:
- The default seems to make the payment without confirmation. What stops an endpoint from changing payment amount between an inspect request and the actual request?
- Will adoption of this payment protocol ever grow large enough for anyone to implement this on either the client or server?
- Bots have more of a financial incentive to crawl sites than a human. I doubt this will actually stop anything
- I see a AGENTS.md. How much of this is vibe coded? It's near impossible to get a sense of the care taken to review LLM output. Hard to trust with money.
It only took us 29 years but HTTP 402 Payment Required might finally mean something on a wider scale…
Oh no, this is already the second "purl" Name collision...
https://github.com/package-url/purl-spec
https://en.wikipedia.org/wiki/Persistent_uniform_resource_lo...
These things are always a massive source of confusion...
While I can understand the rationale behind it, I can't imagine this being used for anything that requires low latency requests.
I imagine the flow would be something like (correct me if I'm wrong) [client request] -> [backend returns an error]/[accepts the request and waits for payment] -> [client sends the money] -> [backend accepts the transaction] -> [backend returns the requested data]. All of this sounds like a huge bloat over the current API key/token system.
Uncharacteristically unclear marketing from Stripe!
You're gonna have to give me more to go off of than this.
There is also package url (`pkg:/`), now an ECMA standard: https://ecma-international.org/publications-and-standards/st...
It's also the name of my business, chosen for the definition "(of a stream or river) flow with a swirling motion and babbling sound". I have to say, it's really unsettling when a behemoth like Stripe shows interest in a word you use for branding/identity, even in a totally unrelated industry. I doubt it matters, but I'd feel better if they just didn't
An annoying trend I've been seeing recently, which the GitHub repo behind this does, is having better documentation for the robots than there is for the users.
Compare the README.md to the skills/pay-for-http-request/SKILL.md
In the cryptocurrency world this has existed many years already. For example with the Lightning network on top of Bitcoin it has always been easy to let the server generate an invoice, which the client pays and then the client sends another request including cryptographic proof of the payment. On layer 2 it was always cheap and fast.
For example I created this Go middleware at the time: https://github.com/philippgille/ln-paywall#how-it-works (currently defunct)
Similar projects implemented that into standalone API gateways.
All using status code 402 already.
Here Stripe's example is using USDC, so still crypto BTW.
There is something really cool going on with payment over the wire. But why written in Rust? absolute pain to setup.
i don't love the HTML response for "payment required" endpoints, not least because it just asks the agent to install an arbitrary NPM package for "full wallet connection and payment UI". seems so easy to exploit maliciously - what's to distinguish genuine payment instructions with crypto stealers
You know, it's funny. A while back people would've been building cURL alternatives/wrappers/collecting client header stacks designed to sidestep paywalls on web content (sidestep, at best).
With purl, the web gets just a little less punk. Which is nothing new, unfortunately. I miss the times when people would put in stupid amounts of effort to stick to their principles in hobby tech.
what are the use cases here?
My first thought was that it would make payments easy for bots. It would be trivial to turn this into tool calls, so you'd just set up the wallet and let your bot go shopping.
Serve data to users at their expense instead of yours.
I've wanted something like this for a while. S3 Requester Pays kind of achieves the same thing but requires the requester to have a funded AWS account.
that's an interesting take, I'm curious to what a pricing model for a setup like that could look like at an enterprise tier
I could see stuff like how some B2C things sell stuff like PDF, videos, tutorials, at a flat-fee, but usually B2B enterprise ends up with a metered pricing so negotiating that could end up with many dynamic urls which sounds like a giant mapping table on top of the protocol
I'm thinking along the lines of wikis, archival projects, and yeah pay-per-view video/photo websites. Torrents only work for static data and aren't very performant.
This is a fair way to allow AI scraping too: you can let bots scrape as much as they like, as long as they cover the cost of serving that content. The bots don't have to enter payment information into every website they want to scrape.
Was wondering the same. There's a markdown table in `skills/pay-for-http-requests/SKILL.MD` that has a "common scenarios" section. It lists four examples with descriptions.
[dead]