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

Hi Michel,

Thank you for the very thoughtful feedback. Please see my replies inline.

On Wed, May 29, 2019 at 11:53 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 FlowOverview
>
> 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?
>
>    1.
>
>    Can an account can be created on behalf of the user with the
>    information from PaymentRequest?
>    2.
>
>    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.
>

I cannot speak for Google Pay (+Avnish Miduthuri <avnishm@google.com> for
that) and Apple Pay, but IMHO it should be OK to create an account using
Payment Request, as long as you're making it clear to the user what you're
doing. For example, I can imagine your page showing a button labeled [
Create Payment Account ] that launches PaymentRequest with the total
labeled "Create payment account with AirBnB, not charged until booking --
$0.00."

I've seen New York Times use Payment Request with "basic-card" for updating
the card stored on file with NYT and I consider this to be acceptable
practice.

[image: Screenshot from 2019-05-30 09-16-52.png]

W3C has at least two standards for collecting contact information:

   - https://www.w3.org/TR/2011/WD-contacts-api-20110616/
   - https://www.w3.org/TR/contacts-manager-api/

I'm not aware of any browsers that implement these. If you find this use
case very compelling, perhaps browsers could be convinced to implement one
of them.

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

Ideally, PayPal would use the Payment Handler API so that AirBnB can
integrate with it seamlessly.

   - Question for AirBnB: Would a JS shim that turns PayPal into a payment
   handler be helpful?
   - Question for PayPal: Would a JS shim that enables Payment Handler on
   Safari and Firefox be helpful?

Although one workaround is to use separate branded HTML buttons for such
payment methods, I can see how that's suboptimal.

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