Payment-request: Require user gesture when `.show()` is called

[michelle]

If interoperable behavior emerges amongst user agents, then that behavior will be standardized here before progressing the specification along the W3C Recommendation Track.

It looks like this is already noted in the CR, but I wanted to open a ticket for this to track status on this.

ApplePayJS (whose behavior I imagine will eventually make it into Safari's PaymentRequest implementation) only allows .show() to be called by user activation (e.g. click). On the other hand, Chrome allows .show() to be called as long as the page is in focus. This makes it hard to build consistent UIs.

[michelle]

cc @aestes @jenanwise @marcoscaceres @rsolomakhin

[rsolomakhin]

We can start requiring the user gesture in Chrome.

[zkoch]

This will break some implementations in the wild, so we should be thoughtful about how we do this.

[marcoscaceres]

Requested upstream: https://github.com/heycam/webidl/issues/479 ... let's see how that goes, but we can certainly provide some prose for this in our spec if those discussions are not fruitful.

[cyberphone]

I have just created a real world PR implementation that would break if this requirement become mandatory. It will be particularly troublesome in those cases where PR is only used partially (skipping the selection part) and payment methods execute in different Web applications since the gesture (I guess) get lost if you change URL. Yes, essentially it much boils down to how gestures and host domains are dealt within browsers. Is there actually a standard for that?

[marcoscaceres]

The "partial case" wound't be affected: this only affects calling show().

Is there actually a standard for that?

That's what heycam/webidl#479 would be.

[cyberphone]

What I meant is that some users of PR (including myself) will for various reasons stick to the old school model of selecting payment methods and then let each method implement the associated payment interface in specific web applications. The methods building on PR would if I understand it right need an extra button and click.

[cyberphone]

So the _specific_ PR is initiated and activated including show() by anonload() event in the specific Web application triggered by the user's selection. It works quite well BTW :-)

The motives the the old school approach to payment method selection and execution are two-fold:

• External payment methods like QR have not yet been addressed by the WG
• The code can get quite messy if very different payment systems are to be supported. Splitting code is quite logical and aligned with how most _existing_ systems are architected

[rsolomakhin]

Splitting code is quite logical.

Agreed. Have you seen our Payment Handler API demos? That API allows writing 3rd party payment apps in JavaScript and has ability to open a window as well.

[marcoscaceres]

It should, in theory, be possible to carry over a user gesture across a navigation (see Google proposal)- but that would need to be part of HTML and supported by browsers.

Effectively, what this means, is that a user could collect a bunch of items into a shopping cart, hit "buy", be navigated to a checkout page, and have the payment sheet displayed (without them having to click on another thing).

That would address @cyberphone's concerns and potentially @zkoch's concerns with existing sites relying on the ability to pop up the payment sheet without user gesture.

[cyberphone]

Agreed. Have you seen our Payment Handler API demos? That API allows writing 3rd party payment apps in JavaScript and has ability to open a window as well.

Yes, I have. However, as a Scandinavian, I'm rather into the 360 degree _mobile_ payment App vision which already is a "smash hit". It is currently not clear to me how you integrate these schemes in the _desktop_ Web using PaymentRequest which is one of the motives for separating payment method "selection" and "execution". BLE is a possibility but that would be a pretty difficult project.

https://www.mobilepay.dk/SiteCollectionImages/MobilePay-Universe-2/TheStoryInEnglish/MobilePay_desktop_ENG.jpg

[rektide]

This would directly contradict the purpose & intention of the Donation Acceptance specification that I am working on. The "tipjar" page is supposed to immediately open a payment request. Requiring user interaction would inhibit this flow.

[marcoscaceres]

@rektide, understood, but that's kinda the point.

@tantek has a much nicer way of doing exactly what you propose, giving the user choice while also requiring the user to click on things. See, for example: http://tantek.com/pay/12

[tantek]

Thanks @marcoscaceres. For more background on the design & implementation of that /pay/amount page, as well as additional examples (including use of the Stripe library to implement Request Payment API), see https://indieweb.org/pay - recently discussed at IndieWebCamp Austin: https://indieweb.org/2017/Austin/pay (40 minute session video, discussing donations, recent Patreon drama etc.).