- 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
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.
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.
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.
20 comments
- 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.
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...
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.
You're gonna have to give me more to go off of than this.
pkg:/), now an ECMA standard: https://ecma-international.org/publications-and-standards/st...Compare the README.md to the skills/pay-for-http-request/SKILL.md
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.
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.
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.
skills/pay-for-http-requests/SKILL.MDthat has a "common scenarios" section. It lists four examples with descriptions.