x402 — An open protocol for internet-native payments

Re:x402 — An open protocol for internet-native payments by olivia-banks on Tuesday September 23, 2025 @11:29AM (#45348434)

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?

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by tleyden5iwx on Tuesday September 23, 2025 @12:17PM (#45349102)

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)

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by cestith on Tuesday September 23, 2025 @03:24PM (#45351562)

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?

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by tleyden5iwx on Tuesday September 23, 2025 @05:00PM (#45352679)

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.

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by astroflection on Tuesday September 23, 2025 @12:18PM (#45349118)

> 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.

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by _el1s7 on Tuesday September 23, 2025 @02:15PM (#45350807)

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.

[ Parent | on HN ]

Re:x402 — An open protocol for internet-native payments by __erik on Tuesday September 23, 2025 @02:56PM (#45351265)

>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

[ Parent | on HN ]