Some questions regarding payment request api on mobile (airbnb)

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