- 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
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.
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
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.
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.
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.
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 something really cool going on with payment over the wire. But why written in Rust? absolute pain to setup.
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
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?
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.
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.
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.
[dead]