Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98)

@adamroach wrote: 
> But now you seem to be saying it's... okay? Or maybe okay? I'm getting whiplash trying to follow your can-or-can't have multiple payment apps[1] per origin.

I've **not** changed my position, AFAICT - but I clearly didn't articulate my position well and kept getting confused by the existing terminology (which is why I provided code and images, which are subject to less ambiguity). From my very first proposal, I held that I view "payment web apps" as single origin progressive web apps - meaning you could have as many service workers registered to handle requests per payment as needed. I.e., they were exactly the same as any web application today. Sorry if I was not clear. 

Also, should I, or anyone, change their position by coming to a new understanding in light of new information, that's a good thing - not something to be mocked. I'm not here because I like s***posting or making an ass of myself. If I am wrong, or proved wrong, I will be totally happy with that. But I will continue to question as to assure that this is the best solution for users, developers, merchants,  payment processors, implementers and the Web as a whole. 

I still think we can do better - and we are a long way from anything I would support publishing as a FPWD or would feel comfortable taking back to Mozilla to allow us to consider implementation.   
 
> [1] Which, for avoidance of doubt, is the term we have been using as shorthand for "service worker that is registered to handle one or more payment methods."

**That's not the definition I was using** - and that definition is the source of all confusion (which is why I removed it from my counter proposal - and continue to argue to drop it from this spec too). The definition I was using was from a user's and developer's perspective (and basically what everyone else in the web community would call these things, and how user's would understand them): "web apps that can handle payments". 

This image (the actual web application) represents what is meant (wallet.com is a **payment app**):

![screenshot 2017-01-27 13 57 21](https://cloud.githubusercontent.com/assets/870154/22359138/a5887614-e498-11e6-9964-6e979b4da5c5.png)

A end-user would see when making a purchase:

![screenshot 2017-01-27 13 50 17](https://cloud.githubusercontent.com/assets/870154/22359141/b4c0048a-e498-11e6-8ce9-95d57126f5c6.png)

(one web application: multiple payment methods)

Thus, "a payment app is a web application that is registered to handle requests for payment via one or more payment methods. Payment methods are processed via one or more service workers". If we can get behind a logical definition, that is consistent with the rest of the web platform, then we can stop all the confusion. 

Now, with regards to permissions we could even refine the proposal as follows:

```JS
// Register once on static PaymentManager method. 
PaymentManager.requestPermission().then(async result => {
  // can do  both Visa and Amex
  const multiHandler = await serviceWorker.register("visa_and_amex.js");
  // can do only MasterCard
  const masterCard = await serviceWorker.register("mastercard.js");
  
  // Add payment methods
  multiHandler.paymentManager.methods.set("visa-4756", {
      name: "Visa",
      methods: ["basic-card"],
      icons: [...visaIcons],
   });
  multiHandler.paymentManager.methods.set("amex-5361", {
      name: "Amex",
      methods: ["basic-card"],
      icons: [...amexIcons],
   });
  masterCard.paymentManager.methods.set("mastercard-1234", {
      name: "MasterCard",
      methods: ["basic-card"],
      icons: [...mastercardIcons],
   });
});
```

@adrianhopebailie wrote:

> Resolve whether or not a user must consent to a payment app altering the set of payment methods it supports.

I'm of the opinion that the web application need **not** ask a user for consent to manage payment methods. It should be a goal of this spec to enable developers to build apps like "wallet.com" above - which include saving payment hander details, handling the payment processing (in coordination with payment processors), and being able to store shipping/billing information, and whatever else will help to make for a speedy checkout experience. 

I can't build "wallet.com" if I have to annoy the user every time they want to add or modify a payment method. 

Lastly, as an implementer, I want developers to have _exactly the same API_ that we would use to build a card management interface in Firefox - this includes Firefox also having to ask for permission to handle credit cards on behalf of the user, etc. I don't want the browser to have any special things that are not available to developers unless there is some demonstrable privacy or security restriction that can't be handled in any other way (e.g., in fetch API, developers can't override certain headers for security reasons - I want the same here, where it makes sense).   

Again, in pictures, to reduce ambiguity: Firefox settings to manage credit cards and wallet.com are the same thing, and must use the same APIs:
 
![screenshot 2017-01-27 14 14 43](https://cloud.githubusercontent.com/assets/870154/22359413/1e8d1e96-e49b-11e6-811f-337477072af2.png)

In fact, I should be able to host Firefox's credit card manager at "mozilla.com/manage-payments" or whatever, without requiring any browser only APIs. If this spec doesn't let me do that, then it's not meeting the use cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-275581133