Should Payment Request API handle non-human payment flows?

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

No implementation files or tests are identified. Start by reviewing the Payment Request API scope and the PaymentMethodData concept, then compare the X402 approach built on HTTP 402. Done means reaching a clear decision on whether this belongs in the API, an extension, or a companion specification.