Re: [w3c/payment-request] Treat scroll as a user gesture for PaymentRequest.show() (#797)

> > 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/797#issuecomment-436700963