Skip to content

Should Payment Request API handle non-human payment flows? #1072

Description

@hemanth

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions