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 concentrate examples of which are:
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.
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:
Look at cross-navigation capability delegation, such that the users original intent/activation can be carried through the redirect.
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.
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 concentrate examples of which are:
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.Buy now via PayAppon a particular item from a particular merchant. The aggregator site redirects to the merchant site, which wants to immediately trigger payment viaPayAppwithout 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:
Marcos also mentioned that the Screen Wake Lock API had a similar need, though I don't personally know the details.