Re: [w3ctag/design-reviews] Payment Handler (#231)

Thank you very much for the through review, @dbaron and @triblondon! Please see my responses inline.

@dbaron wrote:

> We'd like the web to allow payment processors and payment methods that we don't know about.

We accomplish this in Chrome via the "just in time" (JIT) install, which we consider to be a browser optimization that does not need to be in the spec. Chrome displays the name, origin, and icon of the “installable” payment handler. It’s not saved to disk yet at this point. This is meant as a bootstrapping mechanism only for users with fairly fresh profiles. Therefore, a number of conditions have to be satisfied to make a payment handler available for install.


Conditions to offer JIT | Reasoning for this condition
-- | --
Merchant does not request payment via “basic-card”. | Chrome payment sheet has built-in support for adding new autofill cards, which are used for “basic-card” payments.
User does not have installed any payment handlers that would satisfy the merchant request. | User may already have their preferred payment handler installed.
Payment method manifest specifies a default application (web app manifest), which specifies a name, icon, and service worker that can be installed. | Need to present the best possible experience for brand new users.

@dbaron wrote:

> We should consider whether it's a problem if either the merchants or the users to be confused about what payment systems they're using.

We always display the origin of the payment handler to the user.

The merchant has control over which payment method they are willing to accept. Any payment handler can return data for standardized payment methods, e.g., "basic-card," or URL-based payment methods whose payment method manifest contains `"supported_origins": "*"` directive. If the merchant needs to have stricter control over the source of the payment information, they should use URL-based payment methods whose payment method manifest does not contain `"supported_origins": "*"`. This will allow the merchant to enumerate the full list of origins of the payment handlers with which they could be interacting.

@dbaron wrote:

> Does this API make the right tradeoffs in terms of running the necessary level of detail through the API to allow browsers to present users with trusted payment user interface (or, if needed, giving the user the right security indicators about the level of trust) versus letting the payment handler customize what it needs?

We are [expanding the security considerations](https://github.com/w3c/payment-handler/pull/283/files) section with the following info:

* The user agent may block mixed content (e.g., non-HTTPS or scripts) on the payment handler page.
* If the SSL certificate of the payment handler page is not valid (e.g., self-signed), the user agent may cancel the payment.
* If the web-page is known to be malicious (e.g., a phishing page according to a safe browsing database), the user agent may cancel the payment.
* If the payment handler page redirects to a non-HTTPS scheme origin, the user agent should cancel the payment.

Merchant can set the theme color, page title, web app name, and web app icon to customize the payment experience.

@dbaron wrote:

> Does it allow both user-agents and merchants to make choices about whether the user should only be presented with already-configured payment mechanisms, or given the option to set up new ones? (It doesn't seem to allow setup as part of the overview.) Or is it at least extensible to allow this in the future?

A user agent can use the JIT install techniques for this purpose.

@dbaron wrote:

> Does it make the right tradeoffs about reusing pieces of technology already present in the platform versus inventing new things?

We are re-using web app manifests and service workers as much as possible.

@dbaron wrote:

> Does this specification introduce new mechanisms for communication between origins that need to be considered carefully?

In many ways, we are trying to improve the user experience of the existing payment mechanisms that communicate cross-origin today.

@dbaron wrote:

> It's not clear to me how browsers plan to explain to users what installing a payment handler means.

We've been discussing this as well and have not come up with a good solution. For example, if a user uses the existing PayPal checkout buttons everyday, how confused would they be to see an "Allow PayPal to handle payments" prompt? They would naturally think, "PayPal already handles my payments. This prompt does not make sense." Therefore, so far Chrome does not have much UX for payment handler installation. We are continuing to evolve our thinking here and will make UX adjustments as our understanding of our users improves.

@dbaron wrote:

> If somebody installs a malicious payment handler as a way to cheat merchants, claiming to support a particular payment method that the merchant wants, the expected way to deal with this is that the payment processor and the merchant involved need to validate all the data sufficiently to ensure that they're getting the expected payment. Given that the merchant can't trust any security checking that the browser does anyway (even if the browser does end up verifying something based on the payment method manifest connected to the identifier), this seems like it has to be the answer. Perhaps that should be called out a little more clearly in the section on security considerations?

[Filed an issue](https://github.com/w3c/payment-handler/issues/288) with the payment handler spec.

@dbaron wrote:

> Does this UI from the payment handler's origin that is shown within the browser chrome have the usual permissions that web pages have, or more, or less? 

The payment handler page has the usual permissions.

@dbaron wrote:

> What happens if it asks for permissions that require prompts?

Our plan is to auto-deny those prompts during the payment process for simplicity.

@dbaron wrote:

> Does it share things like permissions and storage with regular tabs from the origin, or are they somehow different? Does it influence computations that depend on whether and how long the user is interacting with a page from the origin? Does it honor settings like private browsing mode?

The payment handler page works like a regular tab, because we are re-using the service worker `openClient(url)` algorithm.

@dbaron wrote:

> It's not clear to me that this sort of user interface will be accepted across browser vendors; in fact I suspect it will not be. That raises the next question: why is this user interface needed? And would passing additional data through the payment handler API allow the browser to present the necessary information to the user in a way that could avoid this user interface... or at least avoid every having to present it in privileged UI rather than as a regular web page? If additional API surface is needed, should it be added?

Payment handlers can have complex flows such as username/password login, biometric authentication, CAPTCHA, and so on. Hard-coding the entirety of these flows is not practical and would stifle the innovative nature of the web.

@dbaron wrote:

> One other question I had ((5) above) was whether this introduces new mechanisms for communication between origins that don't exist today. In particular, I'm wondering about the ability of the CanMakePayment event to communicate with a payment handler installed by another origin (without triggering any immediate network traffic). It's not clear to me whether this is something Service Workers allow today (I'm not particularly knowledgable on handling of cross-origin requests by Service Workers) or whether there are other features of the Web that already allow similar things. This is a concern that may be trivial to refute by demonstrating that it's something already allowed, but if it's not, it may be worth thinking about more closely.

Please correct me if I'm wrong, but I believe that, in the absence of network traffic, there is no cross-origin communication, because the server of the payment handler does not receive network requests.

If the service worker does trigger a network request either in the `CanMakePaymentEvent` handler or at some point later, then this is pretty much the same communication as including a cross-origin iframe to be controlled by the service worker and then `postMessage` to that iframe.

@dbaron wrote:

> One other concern about malicious payment handlers that just occurred to me is that it seems like CanMakePaymentEvents have data about the payment total.

[`CanMakePaymentEvent`](https://w3c.github.io/payment-handler/#the-canmakepaymentevent) does not have the total and I've filed an [issue to remove modifiers (including the total) from `CanMakePaymentEvent`](https://github.com/w3c/payment-handler/issues/289).

>From the Payment Handler spec:

```WebIDL
[Constructor(DOMString type, CanMakePaymentEventInit eventInitDict),
 Exposed=ServiceWorker]
interface CanMakePaymentEvent : ExtendableEvent {
    readonly attribute USVString                           topLevelOrigin;
    readonly attribute USVString                           paymentRequestOrigin;
    readonly attribute FrozenArray<PaymentMethodData>      methodData;
    readonly attribute FrozenArray<PaymentDetailsModifier> modifiers;
    void respondWith(Promise<boolean> canMakePaymentResponse);
};
```

@dbaron wrote:

> Which means that a payment handler could choose to only accept refunds and not debits. This makes me a little bit more worried about malicious payment handlers.

Payment Request currently [prohibits negative `total` values](https://w3c.github.io/payment-request/#paymentdetailsinit-dictionary), so refunds are not available in the API.

>From the Payment Request spec:

> Algorithms in this specification that accept a PaymentDetailsInit dictionary will throw if the total.amount.value is a negative number.

@triblondon wrote:

> Is there any potential issue with users acquiring tonnes of payment handlers without realising it, and those payment handlers existing purely to bring spam content to the user's attention?

That's a potential issue that we're considering and plan to mitigate using UX. For example, Chrome plans to hide never-used payment methods "below the fold", such as a "Show more" button in the list of available payment methods. We view this issue as a spam mitigation issue that is not blocking us, because of the high value of the feature as whole. This is similar to e-mail, which is immensely useful regardless of spam that one might receive and where spam-filtering tools have evolved enough to greatly reduce the annoyance of spam.
 
@triblondon wrote:

> Where possible, we strongly recommend using or extending web app manifest.

[Filed an issue](https://github.com/w3c/payment-method-manifest/issues/27) against the payment method manifest spec.

@dbaron wrote:

> ImageObject is similar to web app manifest's ImageResource, but it: (1) doesn't have the two last properties, (2) has a differing type for type (DOMString vs. USVString).

[Filed an issue](https://github.com/w3c/payment-handler/issues/287) against the payment handler spec.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/231#issuecomment-380872963