w3c / w3c/payment-request

Consider spec-ing when a user agent should allow activationless PaymentRequest

Open
#1,022 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
510
Forks
139
PR merge metrics
No merged PRs in 30d

Description

In https://github.com/w3c/payment-request/pull/1009, we added support for calling PaymentRequest.show() without a user activation. This was done to support redirect use-cases, a few concrete examples of which are:

  1. A user is checkout out on merchant.example. They select a payment method, and the merchant redirects the user to a PSP experience to handle that payment method. The PSP wants to immediately trigger the payment experience without the user having to re-click.
  2. A user is using a shopping aggregator site, that shows results from many merchants at once. The user selects Buy now via PayApp on a particular item from a particular merchant. The aggregator site redirects to the merchant site, which wants to immediately trigger payment via PayApp without the user having to re-click.

When we spec'd this, we were vague about when the user agent should allow an activationless PaymentRequest, and we didn't do the best job of motivating the need in the spec itself. We should revisit this, and try to see if there's a path to spec or at least provide non-normative guidance for user agents. This may not be trivial, as at least in Chrome we want some control to apply friction in cases where we think the website or 'payment app' may be (partially) malicious, but it's worth giving a go :)

Some possible non-exhaustive angles to consider:

  1. Look at cross-navigation capability delegation, such that the users original intent/activation can be carried through the redirect.
  2. Spec formally Chrome's "one free try" approach that we currently implement.

Marcos also mentioned that the Screen Wake Lock API had a similar need, though I don't personally know the details.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading pull/1009 and the issue's redirect examples, then investigate cross-navigation capability delegation and Chrome's "one free try" approach. Compare the related Screen Wake Lock API discussion if available. Done means proposing a concrete normative rule or clearly scoped non-normative guidance for when activationless PaymentRequest.show() should be allowed.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
api, payments
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.