Treat scroll as a user gesture for PaymentRequest.show()

[danyao]

Today, PaymentRequest.show() does not show the payment method picker UI if all the following are true: 1) Merchant request payment via a URL-based payment method identifier. 2) User has a single payment handler for the payment method. 3) PaymentRequest.show() is triggered by a user gesture, such as a click. 3) Payment handler does not call PaymentRequestEvent.openWindow(url).

This makes it possible to build a seamless checkout experience that doesn't require any user interaction, once the first gesture is provided.

Currently "scroll" is not considered a user gesture for (3) above. This prevents me from building a scroll-to-pay flow, which can be very useful for paid web content.

Naively enabling "scroll" to be treated as a user gesture can lead to abuse. I think we can counter that in three ways: 1) Ask user during Payment Handler registration for permission to allow scroll-to-pay for this handler. They should also be able to change this setting in browser UI. 2) Optionally allow scroll-to-pay for only small amounts. 3) Display a non-intrusive UI in browser (e.g. a toast) after PaymentRequest.complete() is called to alert user that payment took place.

[marcoscaceres]

This prevents me from building a scroll-to-pay flow, which can be very useful for paid web content.

Could you help us understand a little bit more with what "scroll-to-pay" looks like?

Ask user during Payment Handler registration for permission to allow scroll-to-pay for this handler. They should also be able to change this setting in browser UI.

The challenge that we face in browsers is that we rely on HTML's "triggered by user activation". The "scroll to pay" case would need to be sufficiently common to warrant having a special code path just to handle this kind of payment interaction.

[danyao]

This prevents me from building a scroll-to-pay flow, which can be very useful for paid web content.

Could you help us understand a little bit more with what "scroll-to-pay" looks like?

Sure! Imagine if we want to implement a paywall for an article using Payment Handler API. User lands on the article page, sees a paywall overlay with a "Sign in or pay to unlock access" button. When user clicks on the button, the onclick handler creates a PaymentRequest and calls request.show(). With the right conditions, the payment request can be processed without further actions from the user.

I wonder if we can change this 1-click interaction to a 0-click interaction. What if the paywall is replaced with a banner at the bottom of the screen that says "Scroll down to keep reading. You'll be charged $0.50 (powered by BobPay)". In this case, when user scrolls past the initial content, request.show() is triggered in the onscroll handler. To me this seems a more seamless user experience, because they can complete the transaction by simply continuing to read.

Removing this bit of friction may seem scary: user may be afraid that a mistaken scroll will now cause them to lose money. However, on a website the user frequents, and for small amounts, I wonder if this improvement can tip the friction / value balance for micropayments.

The challenge that we face in browsers is that we rely on HTML's "triggered by user activation". The "scroll to pay" case would need to be sufficiently common to warrant having a special code path just to handle this kind of payment interaction.

Fair point. I was mostly thinking about mobile for the use case above. I'll see if I can use touchend or pointerup somehow.

[ianbjacobs]

@danyao,

Thank you for the description of the user experience.

I have no particular view on whether the HTML spec should change to allow for scroll events.

However, could you implement the desired behavior by showing the user what amounts to a button (that overlays the content) that says "Scroll to keep reading for $0.50". Pressing the overlay is a click. The click causes the payment, the overlay to go away, and pages down one screen. After that it's just regular scrolling.

(I am just riffing; I am not a Web designer. :)

Ian

[danyao]

@ianbjacobs Thanks for the idea. Yes it is possible to implement the user experience with an overlay button and a click. I'm hypothesizing that the requirement of such a click may deter users from initiating the transaction due to cognitive cost to evaluate a micropayment. But I do realize a lot of sites already have "Click to Continue Reading" pattern, so maybe my hypothesis is wrong. I'll try to get feedback from folks actually building paywalls.

[marcoscaceres]

As there is no further action we can take here, I'm closing. Thanks for your input @danyao!