Re: Some questions regarding payment request api on mobile (airbnb)

Hi Michel,

Thank you for sending these questions and notes to the group. In addition to last week’s discussion [1] of these questions,
I want to share a “deployment fan" we had created previously that might be useful:
 https://github.com/w3c/webpayments/wiki/prapi-deployment-faq

In light of your question, we’ve added an entry about using PR API data for account creation.

I look forward to chatting more about these topics, and to making progress on the availability of payment handlers for a wider variety fo payment methods.

Ian

[1] https://www.w3.org/2019/05/30-wpwg-minutes#item02

> On May 29, 2019, at 10:52 PM, Michel Weksler <michel.weksler@airbnb.com> wrote:
> 
> Dear web payments wg,
> please find below several questions and observations from Airbnb's recent evaluation of payment request api on mobile.
> Evaluating the Payment Request API
> for Airbnb's Mobile Web Booking Flow
> Overview
> Airbnb evaluated the exciting new Payment Request API for usage as part of Airbnb's mobile web booking flow. We have some questions / concerns / limitations about effectively using this new web standard.
> Payer information for sign up purposes
> Can payerEmail, payerName, payerPhone be used for sign up purposes?
> 
> There is documentation in the Google pay / Apple pay usage guidelines that say it can only be used for transaction purposes:
> data returned by the Google Pay API is used only for transaction purposes, which include order confirmation, shipping notifications, shipping tracking, cancellations, refunds, and refund notifications
> https://developers.google.com/pay/api/web/guides/ux-best-practices 
> 
> You may not use the Apple Pay for any purpose other than to enable or facilitate an Apple Pay transaction from your website.
> https://developer.apple.com/apple-pay/acceptable-use-guidelines-for-websites/ 
> 
> Pre-filling information for account creation was called out as acceptable usage:
> If you want people to register for an account, ask them to do so on the order confirmation page. Prepopulate as many registration fields as possible using information provided by the payment sheet during checkout.
> https://developer.apple.com/design/human-interface-guidelines/apple-pay/overview/checkout-and-payment/ 
> 
> What is the guidance when using PaymentRequest API?
>  • Can an account can be created on behalf of the user with the information from PaymentRequest?
>  • Can account creation be pre-filled for the user with the information from PaymentRequest?
> 
> Our worry with (B) is that if account creation is deferred until after payment there will be a significant drop-off in account creation.
> 
> We could work around this by making the PaymentRequest sheet not the last step in the flow. i.e. The PaymentRequest sheet would appear, the user presses the pay call-to-action (CTA), the sheet closes, account information is pre-filled, the user creates the account, then there is a final pay CTA on our page that completes the payment. However, this feels counter to the more natural flow where the PaymentRequest sheet is the final action that indicates payment completion.
> Accounting for other payment methods in the UI
> There are payment methods that we use on Airbnb that are not available as payment handler via PaymentRequest, such as PayPal. What is the recommended way for accounting for unsupported payment providers. Ideally everything would be surfaced via the PaymentRequest sheet. But today we would need to fragment our UI to account for PaymentRequest-enabled providers vs everything else.
> Apple Pay only on iOS Safari
> Currently, iOS Safari only supports Apple Pay via PaymentRequest. This means we'd have to account for Google Pay or entering credit card information outside of Apple Pay separately in our UI for iOS Safari users.
> 
> - Michel

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Monday, 3 June 2019 16:00:48 UTC