search

w3c / payment-handler

Payment Handler API
https://w3c.github.io/payment-handler/
Other
74 stars 42 forks source link

Share user data with Payment App #123

Open frank-hoffmann opened 7 years ago

frank-hoffmann commented 7 years ago

I propose that Payment Apps should be able to receive user data stored in the browser after explicit consent from the user. This is only relevant if RequestShipping or RequestPayer* is set to true in the PaymentRequest.

Use cases:

User consent In order for the Payment App to receive user data in the PaymentAppRequest explicit consent is needed from the user. This can be asked for either at installation or at first time using the Payment App.

The Payment App should indicate that it wants to receive user data at time of installation, when doing the requestPermission call.

User data The user data in question is the same user data that the merchant get back with the PaymentResponse depending on the RequestShipping or RequestPayer* flags

adrianhopebailie commented 7 years ago

+1 to this proposal.

Payment through instant credit, using basic user and transaction information for scoring, is an increasingly common use case in developing economies where traditional credit is not available. i.e. Just the user's mobile number may be enough

This is the user's data and they should be allowed to share it with payment apps they trust if they choose to do so.

marcoscaceres commented 7 years ago

Yes, no one disagrees with the use case - but asking for permission up front is not great. If you want this data, you need to call .show() at least once. Then the user can tell the browser to always share the appropriate data with the site on subsequent payment requests.

However, it's up to the UA to provide this UI/UX capability and not something that needs to be in the spec.

adrianhopebailie commented 7 years ago

However, it's up to the UA to provide this UI/UX capability and not something that needs to be in the spec.

The implication for the spec is that we define a way for: a) the handler to request that it receives the data (it must make this request either at registration or in response to handling a payment request). b) a mechanism for passing the data to the app

How we solve a) impacts the way browsers will ask for permission so while we may not design that we do need to consider it.

tommythorsen commented 7 years ago

Proposal

A payment app can request user data after being invoked, by calling a new method requestUserData() on PaymentManager:

interface PaymentManager {
    [SameObject]
    readonly attribute PaymentInstruments instruments;
    [SameObject]
    readonly attribute PaymentWallets     wallets;
    Promise<boolean> requestPermission();
    Promise<PaymentUserData> requestUserData(sequence<PaymentUserDataField> fields);
};

enum PaymentUserDataField {
    "name",
    "email",
    "phone",
    "shippingAddress"
};

dictionary PaymentUserData {
    DOMString name;
    DOMString email;
    DOMString phone;
    DOMString shippingAddress;
};

It is only possible for the payment app to receive user data that was required by the original PaymentRequest.

The browser may present a permission request dialog to the user. If the user chooses to not give permission to the app, the returned promise will be rejected.

jnormore commented 7 years ago

I get the need to ask for permission but I find the UX a little strange. The customer selects BobPay, payment app is triggered, payment app asks for permission, browser asks user "Do you want to allow BobPay to access your name and email address?", ...

I really only find it strange when comparing it to the experience today with a direct merchant -> payment provider interaction, where what data is shared with the payment provider is determined by the merchant and no permission is required. For a customer, something asking for permission to share data, especially for those not-so-sophisticated customers, is going to scare them off and cause a pretty big increase in cart abandonment rate.

I'm not saying a lot of payment providers don't need this data, I know they do and they should get it, I'm speaking from a merchant and customer experience perspective. I don't have a good answer on the sharing of the data, that may be another problem to solve, I just think that asking for permission on something during a payment process (a time when most customers may be a little on edge) is going to hurt checkout conversion rate a lot.

rsolomakhin commented 7 years ago

Does this API have to be in the payment handler spec? We can use the proposed Phone number API for phone numbers, for example, so maybe additional "Name API," "Email API," and "Address API" would be useful.

jnormore commented 7 years ago

A better approach instead of asking for permission during the purchase flow would be to ask during the install process IMO, anything to not increase cart abandonment rate.

dlongley commented 7 years ago

@rsolomakhin,

Does this API have to be in the payment handler spec? We can use the proposed Phone number API for phone numbers, for example, so maybe additional "Name API," "Email API," and "Address API" would be useful.

This sounds like it's potentially getting into Verifiable Claims territory. We've voiced our opinion in the past about Web Payments components collecting user data and creating separate APIs for each one of these bits of information as the wrong approach -- and one that will cause the platform to incur further technical debt. There's always one more bit of information that websites would like to ask the user for -- including for reasons other than Web Payments -- so there should be a generalized solution for this.

If this group wants to pursue reusing a generalized solution for obtaining user data, then such a solution should be worked out in conjunction with other interested groups (such as the Credentials Community Group and Verifiable Claims Working Group) so we avoid stumbling over each other or creating subtly different APIs that introduce confusion.

tommythorsen commented 7 years ago

In my opinion, a generalized solution for obtaining user data is not ideal in this case. Remember that at the time of invoking a payment app, the user has already gone through steps for selecting phone number, email address and shipping address as part of the payment request flow (assuming the payment request asked for this information).

A generalized API would presumably not be able to hook into the payment request context and pick out these exact pieces of user data. I would like to avoid that the user is prompted multiple times for phone number, email and address, as this would be annoying for the user, and open up the possibility that the payment app get sent different bits of information than get sent to the merchant.

As for when to ask for permission - at installation time or at the time of actually sharing the data - I don't have a strong opinion. Many modern systems (such as for instance the Android platform) seem to move towards asking permission at the time of use, and this generally seems like a better approach, as it better empowers the user to care about their own security and privacy. However, there could be reasons why our case is different (cart abandonment), and that we should ask at installation time instead. I would say that from a technical perspective, either solution is equally simple to specify and implement.

Krystosterone commented 6 years ago

On a related note, I had opened an issue here: https://github.com/w3c/payment-handler/issues/218 that seems to have a lot of overlap with the discussions above. I've closed it for now, but am referencing it here if we ever want to re-discuss these kind of implications.

Issue: https://github.com/w3c/payment-handler/issues/218 Summary: Provide a way for payment instruments to respond with information that would normally be provided by the user

rsolomakhin commented 6 years ago

I have a radical idea: the payment app should send its own user data to the user agent to help bootstrap it, if possible. For example, if the payment app has information about a shipping address that the user agent does not have, providing this address to the user agent will let the user see it and interact with it among the other shipping addresses in the user agent.

Krystosterone commented 6 years ago

🤔 Interesting! Where (in the life-cycle of the payment app) would you see this information being forwarded to the user agent?

rsolomakhin commented 6 years ago

@Krystosterone, most straightforward in my view is when PaymentRequest is constructed. At that point, we can fire a "RequestPaymentAddressEvent" in the payment handler, which can either ignore it or respond with a list of addresses it knows. This would be after "CanMakePaymentEvent" is fired for URL-based payment method names, e.g., "https://android.com/pay".

ianbjacobs commented 6 years ago

@rsolomakhin,

We should discuss two options, which I will name "safer" and "riskier":

Ian

rsolomakhin commented 6 years ago

Hi @ianbjacobs,

Could you please tell me more about these options and your risk assessment? Thank you.

Cheers, Rouslan

ianbjacobs commented 6 years ago

@rsolomakhin,

I am having a knee-jerk reaction to not-yet-selected payment apps being able to have an impact on and relationship to a particular transaction.

I am more comfortable with:

I haven't thought more deeply about it. :)

Ian

adrianhopebailie commented 6 years ago

@ianbjacobs I think the risk is lower here because we are not sharing the data with the merchant until the user selects an address and it gets sent so they can calculate shipping.

That said, how does the payment handler know (without revealing data about the user) if they can trust this merchant with the address data? I think this is less risky if we redact the address data as proposed in https://github.com/w3c/payment-request/issues/648

@rsolomakhin What happens if the browser has no addresses so the default selected address is one provided by a payment handler? I assume this needs to immediately be passed to the merchant to calculate shipping? I think we'd need some explicit language that says:

  1. There is no selected address in this case and the user must explicitly select the address before it is passed to the merchant
  2. The user is able to see where that address comes from so they know how to edit/delete it if it is wrong