Change of approach for gesture to invoke Payment Sheet

[mattsaxonwp]

Following to Shopify presentation of the difficulties with cart abandonment, I've considered an alternative user experience flow which instead of putting to paymentrequest.show() behind a button gesture, instead swaps this for a different gesture, allowing the existing "press button and traditional forms appears" to remain and therefore perhaps aide in transitional abandonment.

I'm not actually clear if my proposal needs a change to the payment request spec, but it certainly involves a change of thinking about the UX flows.

The proposal is here and I'd value consideration of it and feedback.

Status: Notes by Matt Saxon.

Quick summary:

1. Delay the appearance of the modal dialogue that is currently brought up on .Show()
2. Instead have the browser native chrome or an operating systems gesture that bring up the PaymentSheet. This gesture is available when .Show() is in effect.

Problems:

1. Recent A/B testing from Shopify has shown significant cart abandonment, specifically, on first use.

2. Merchants also need a way to allow legacy payment page access for:

   a. Abandonment due to ‘new experience’

   b. Additional features not currently supported (e.g., vouchers)

   c. Preferred payment methods that are not available through Payment Request (either because the user does not have a payment handler, or because the browser does not support payment handlers).

Even Shopify, who have experimented the most, have not found a solution to dealing with 2c above, they restricted their pilot to only merchants who used cards.

Furthermore, their solution to 2b was not entirely satisfactory IMO.

Hypothesis:

1. We need an adoption mechanism that allows user to self-select for the use of the Payment Sheet experience linked to PaymentRequest API. This allows us to deal with the normal distribution of technical aptitude in any population. Commonly referred to early adopters/laggards etc.

Proposal:

1. Payment Sheet does not appear as a modal dialogue on call of PaymentRequest.Show()
2. Instead on called to Show(), the following occurs; a. Browser informs the user that the payment sheet is available but some (typically visual) means (e.g. system tray notification) b. Payment Sheet is only made modal via a further gesture, e.g. swipe up, click on tool bar, select icon from system tray c. Browser page remains available for interaction and under merchant control until above gesture is made, allowing the traditional payment experience to occur in the main browser pane

Benefits:

1. Traditional model can remain unchanged as per user experience, removing card abandonment issue for laggards
2. Early adopters can self-select for WebPayments experience with a well known gesture which is platform/browser dependent making is clearer that this is not a traditional web interaction
3. Specific scheme branding outcomes can be met, all be it by browser native rendering rather than merchant web page render
4. Merchant can use standard browser pane to alert users to optional experience if desired, e.g. ‘you will get a faster checkout by using the [insert vendor specific browser feature]’ (yes this would require some feature detection by the web-page, but would easily be created in a reusable JS library)
5. In a full WebPayments experience, the merchants site in the browser pane can instruct the user to pay via the browser
6. This effectively separate the web-page gesture, which a user expects to result in a page navigation from a non-browser gesture, which the user will reasonably expect to product a response from outside the browser pane.

Additional musings

1. Is a WebPayments brand required in the above experience? I’m not clear it is
2. If not, is a vendor specific brand appropriate, understandable to the user? From my perspective, I think it’s reasonable to use vendor specific, this is often the case with standards, e.g. 3DS is known as different consumer names by each scheme Verified by Visa, Mastercard SecureCode etc.
3. Is the WebPayments experience really a checkout experience, so taking Chrome as an example is this actually “Google Checkout” (brand was used up until 2013!) rather than “Google Pay”? This logically fits nicely as Google Checkout would support other payment methods apart from Google Pay.

[marcoscaceres]

@mattsaxon, your proposal is interesting (kind of "ambient badging" for payments 🤔), but IMO it falls outside the scope of the spec because it deals specifically with UI/UX issues.

I absolutely agree that there needs to be significant work on the part of browser UI/UX teams to make presenting the payment sheet experience much less jarring (we found the same thing at Mozilla in our own testing in Firefox). This is a new UI component for the web, and it's going to take a lot of refining and getting used to over the next few years.

Thus, I think it's too early to look at changing the spec and we need to let both merchants and browser vendors work together to refine the experience... possibly in the manner you propose, with the "Try faster checkout with Foo-Browser-Pay!".

Using the .hasEnrolledInstrument() (pull request #833) might give merchants more confidence, because they will at least know if the user has gone through the pain of at least having set up a card once and possibly seen the UI.

[marcoscaceres]

Inlined the proposal above, so it's easier to review and discuss.

[mattsaxonwp]

Thanks @marcoscaceres. I agree that the full details of my proposal are beyond the spec, but I think there are a few items in the spec that could do with amending to allow this sort of approach. For example the spec current states;

It is not possible to show multiple PaymentRequests at the same time within one user agent. If a PaymentRequest is already showing, calling show() —from any Web site— will return a promise rejected with an "AbortError" DOMException.

With the approach I outline, I don't think the restriction in the specification needs to apply. I think this restriction was inserted on the basis that the interactions after .show() was expected to be modal.

Furthermore I think some of other wording implies a modal approach, for example

....when the user accepts the payment request.

I would suggest this could read 'if the user were to authorize a payment request"

If we can remove the expectations around modality from the spec, then I think it better represents the possibilities.

[marcoscaceres]

It is not possible to show multiple PaymentRequests at the same time within one user agent.

Agree, and you’ll be happy to hear the soon to be published new CR version does allow multiple tabs/windows to show payment requests at the same time.

I think some of other wording implies a modal approach, for example.

Kinda, yes. But it’s similar to a file picker. The spec doesn’t enforce presentation, however.

[mattsaxonwp]

OK, if you are saying you think the spec is suitable for such an implementation as I suggest (or will be shortly), then we are good I think!

[mattsaxonwp]

Following verbal discussion at the Payment Handler regular call yesterday, it became apparent that because the change from sync to async would need need merchants to write their webpage code differently, that this would require a change to the specification. Obviously the presentation style would not be specified and my examples above are purely to help people visualize.

[ianbjacobs]

Following @mattsaxonwp, an idea was for a merchant to provide both a legacy checkout experience and a call to PR constructor. The browser could render them both and prompt the user to choose one path or the other.

[marcoscaceres]

The merchant can already do this without needing to involve the browser. They can display the form and also say: "try this faster way to check out! <button>Browser Payments! wow!</button>"

[mattsaxonwp]

I appreciate this can work, but I feel that the distinction is that this gesture would be made from within the web content region of the browser rather than outside of it, e.g. form the browser chrome or operating system chrome. The fact that, in my proposal, this gesture would originate from outside browser content may mean that it might be considered more trusted. It would certainly be consistent for a given user agent/operating system.

I see a semantic distinction here to from 'merchant is asking for payment via payment request (only)' to 'merchant accepts payments via payment request (as well as others)/user offers payment via payment request (and they had other options)'.

I appreciate these distinctions are subtle and I only offer the proposals and my interpretation to foster a discussion.