[w3c/payment-request] Should Payment Request API handle non-human payment flows? (Issue #1072)

hemanth created an issue (w3c/payment-request#1072)

## The problem

Payment Request API was built around a human clicking through a browser checkout. That made sense in 2016. But now we have AI agents making API calls, autonomous services purchasing compute on behalf of users, and multi-agent systems transacting with no browser in sight.

When an AI agent hits a paid API and gets back `402 Payment Required`, there's no standard way for it to negotiate or complete payment. It just... stops.

## Some context

HTTP 402 was reserved for "future use" decades ago. That future seems to be arriving. Proposals like [X402](https://www.x402.org/) are working on standardizing machine-to-machine payment flows — structured headers, payment negotiation, all triggered by the 402 status code.

## Questions I'd like to put to the group

1. Should Payment Request API's scope expand to cover non-browser, non-human payment initiators? Or is that out of charter?
2. Could a new `PaymentMethodData` type work for autonomous/agent payment methods?
3. Is there value in aligning with protocols like X402 that build on the 402 status code?
4. Does this belong as an extension here, or would a companion spec make more sense?

## Where this comes up in practice

- An AI agent needs to pay for API access within a user-set budget — no human in the loop
- Microservices settling charges between each other at runtime
- A browser-based AI assistant encounters a paywalled resource and needs payment authority from the user
- IoT devices purchasing bandwidth or compute on their own

I don't have strong opinions on whether this belongs in Payment Request API or somewhere else — genuinely curious what the group thinks.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/1072
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/issues/1072@github.com>