-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change of approach for gesture to invoke Payment Sheet #834
Comments
@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 |
Inlined the proposal above, so it's easier to review and discuss. |
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;
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
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. |
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.
Kinda, yes. But it’s similar to a file picker. The spec doesn’t enforce presentation, however. |
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! |
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. |
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. |
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! |
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. |
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:
Problems:
Recent A/B testing from Shopify has shown significant cart abandonment, specifically, on first use.
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:
Proposal:
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:
Additional musings
The text was updated successfully, but these errors were encountered: