What is a Payment App?

[tommythorsen]

So this is something that we've discussed a lot, but looking at comments in our recent threads, I still don't feel we quite have agreement on this definition. I would really like to nail down exactly what a Payment App is. I would really not like to end up shipping a Payment App API specification, where the term "Payment App" is not clearly defined, and everyone ends up having a different interpretation. This, I think, would make things extremely confusing for anyone who tries to read the specification and figure out how everything fits together.

Looking back a bit, we started out with a Payment App being some loosely defined thing, which the mediator could communicate with using HTTP or Javascript -- we couldn't really decide which one. Then @adamroach saved the day, and proposed the Service Worker based approach, which I think everyone agreed was a huge improvement. It turned out though, that saying "A Payment App is a Service Worker" sounded very strange to many, so I think most of us have agreed that it would be better to say something like "A Payment App uses Service Workers to handle payments". But then what is a Payment App?

I have argued for using the definition "A Payment App is a Web App that can do payments", because I think people will instantly understand this definition. However, this definition requires that we have a clear definition of "Web App". I think most people understand "Web App", as the collection of web pages that are related to a particular Web App Manifest. I think most people think of a "Web App" as the thing you can install to the home screen of your phone if you're on a page that links to such a manifest.

An advantage of my proposed definition is that the relationship between Native Payment Apps and Web Based Payment Apps becomes very straight-forward. Everyone knows what a Native App is (it's the thing you install from the app store, and that shows up as an icon on the home screen of your phone). But what is the web equivalent of this? It's the (Progressive) Web App.

I would be very interested in hearing other potential definitions of "Payment App", and the advantages and disadvantages of those.

[ianbjacobs]

Hi Tommy,

I believe we have consensus on this sentence: "A payment app is a Web application that manages payment requests on behalf of the user by supporting one or more payment methods. "

I don't think we should stray from that. At today's meeting (with Jake Archibald on the call and in reviewing Adam's proposal) I hope to get additional consensus around the relationship to service workers, their scope, options, etc.

I realize you may not be able to join, so check the minutes. :)
Ian

[tommythorsen]

@ianbjacobs that does sound pretty good. What is the definition of "Web application" that goes into that sentence?

[ianbjacobs]

@tommythorsen,

It is not clear to me that a precise definition is necessary for our specification. And it will surely
be a difficult exercise to choose a definition for "Web application." Do you think that more detail is important to understanding or implementing the specification?

Ian

[tommythorsen]

@ianbjacobs

The problem with not having a definition for "Web application", is that we then have no proper definition of what a "Payment App" is. I think that figuring out things like the relationship to service workers, and what a good identifier might be, is almost impossible without some kind of a definition. It wouldn't have to be an official definition, and I wouldn't expect it to go into the actual specification, but working out some kind of loose definition of what a "Web application" is, and keeping it in wiki, would be very useful for further discussions.

From today's meeting minutes, I see some arguments for focusing less on payment apps, and more on the features needed to implement them. I think that is reasonable, and I am positive to renaming the specification. In particular, I like Adrian's statement:

@adrianhopebailie

e.g., the spec could be named after the feature name
... so it's less about payment apps and more about features that we are defining to let someone build a payment app

[delapuente]

Can a web property handle payments without having a manifest? If that is the case, I won't tie the concept of a web app to the manifest. But I would bind the definition to the concept of scope somehow. Nowadays, the most important scope is the web origin.

So, a possible definition would be the collection of web pages under the same web origin.

[tommythorsen]

Based on the conversation with @adamroach in #104, I've made another document that explores how to match Payment Apps and Service Workers, here. This time, we do not depend on a Web App Manifest.

This lets us get around the problem of defining what the Payment App is. The only downside to doing this, is that we don't have any kind of identifier for the Payment App any more, but this is only a problem if we want to merge Options and Wallets from different Service Workers within the same App. As I mention in the document, we could get around this by specifying a "Payment App Id" from the Service Worker. This would let us consider all Service Workers with the same Payment App Id as belonging to the same Payment App.

[adrianhopebailie]

The only downside to doing this, is that we don't have any kind of identifier for the Payment App any more, but this is only a problem if we want to merge Options and Wallets from different Service Workers within the same App

I don't think this is a problem. The introduction of the "wallet" concept has negated the need for a way to group options under an "app".

[adrianhopebailie]

So, having read the proposal in detail here are a few thoughts:

1. Wallets
I am still not convinced that the use case for wallets is strong enough to justify all the complexity it brings with it. Your first code example is so clean and easy to understand and doesn't require any new data models to carry icons, just a label and set of supported methods.

I won't oppose to it being pushed through but my personal preference would be to hold off until we get feedback that it's required.

2. Multiple Service Workers per origin
None of your examples demonstrate what would happen if two Service Workers were registered from the same origin with no wallets. Would they be grouped together? I assume so.

i.e. If I replace the scrip block from your first example with the following do I see the same thing?

      function install_payment_app() {
        navigator.serviceWorker.register("visa.js")
        .then(function(registration) {
          registration.paymentAppManager.options.set(
            "4e05bb9d-fe26-415b-9cc3-ee2fc3877315",
            {
              name: "Visa Cash Rewards ending 3701",
              enabledMethods: ["basic-card"]
            }
          );
        });

        navigator.serviceWorker.register("amex.js")
        .then(function(registration) {
          registration.paymentAppManager.options.set(
            "41856018-7631-409e-b45b-45641465aa09",
            {
              name: "American Express ending 5006",
              enabledMethods: ["basic-card"]
            }
          );
        });

        navigator.serviceWorker.register("mastercard.js")
        .then(function(registration) {
          registration.paymentAppManager.options.set(
            "9f68610b-7515-4746-a3ec-a6c37fdc64f1",
            {
              name: "Master Card Business ending 9123",
              enabledMethods: ["basic-card"]
            }
          );
        });
      }

[tommythorsen]

@adrianhopebailie

I am still not convinced that the use case for wallets is strong enough to justify all the complexity it brings with it. Your first code example is so clean and easy to understand and doesn't require any new data models to carry icons, just a label and set of supported methods.

I agree, and this was my reaction too, to the pull request that introduced them. Like you, I won't oppose it too strongly, but I would prefer simplicity over having this -- in my opinion unnecessary -- feature. I say unnecessary, because you can achieve the same result by using two apps and no wallets.

@adrianhopebailie

None of your examples demonstrate what would happen if two Service Workers were registered from the same origin with no wallets. Would they be grouped together? I assume so.

No, not according to my proposal. For the case in your example, it would absolutely make more sense to group them together, since they are indeed registered from the same page/app. However, if they were registered from different pages within the same origin, things get a bit iffy. I think you should be allowed to have multiple apps within one origin, so I'm not sure I agree with grouping them all together inside an item representing the origin.

I would personally prefer the following solution:

We introduce an appId property on the PaymentAppManager. This property defaults to the url of the context that registers the Payment App, but can be set to any string. If multiple service workers within one origin have the same appId, they will be considered the same app, and sub-options will be grouped together in a single item.

[adrianhopebailie]

I think you should be allowed to have multiple apps within one origin

I disagree as long you have wallets to group them together. The whole concept of an app is tangential to options and wallets.

I like the idea that any Service Worker that registers options, automatically groups them under their origin. The origin is not an identifier it is a "default wallet".

Wallets then allow you to create other groups under the same origin and put options into those groups instead of the default.

So, if we didn't have wallets then you could create groups by using sub-domains but I've heard a lot of push-back on that idea 😄

[tommythorsen]

I think we have to accept that the concept of a "Web App" is something that already exists, and that if we want to make use of the slogan "A Payment App is a Web App that does payments", we have to align our definition of "Web App" with what most people consider a Web App to be. This whole concept is quite fuzzy, and different people will have different opinions of where the boundaries of a Web App are, but I don't think most people think that "a Web App is the same as an origin".

The related concept of a "Progressive Web App" as defined by the Web App Manifest specification allows for an arbitrary number of Web Apps within one origin, and I feel that it would be wise of us to align with this.

Of course, what you are suggesting, @adrianhopebailie, will also work perfectly well, and it's actually really similar to my proposal (the algorithm will be almost identical), except that the origin is used as a "default wallet", rather than the current web page. If we go in that direction, though, we should stop talking about "payment apps" (and rename the specification). Maybe "payment handlers"?

[ianbjacobs]

@tommythorsen,

In the summary [1] I wrote 'There is some support in the task force for renaming the specification to more closely reflect the features it adds to the Web platform (e.g., "Payment Handler API").'

What do you think of that name (courtesy I believe of @jakearchibald)?
Ian

[1] https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130

[adrianhopebailie]

@tommythorsen can you move some of your example code from your proposal to https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md so we can start collecting a central place for example code and snippets

[dlongley]

@adrianhopebailie,

A quick note about your example here: #105 (comment)

Each of those service worker registrations is for the same (default) scope, which means they will overwrite each other. You can only have one registration per scope. This is probably just glossed over in the example, but I wanted to point it out in case anyone was unaware. Instead, you'd have different scopes for each of those workers to make the example work.

[adrianhopebailie]

Each of those service worker registrations is for the same (default) scope, which means they will overwrite each other. You can only have one registration per scope. This is probably just glossed over in the example, but I wanted to point it out in case anyone was unaware. Instead, you'd have different scopes for each of those workers to make the example work.

Good catch. That was not my intent, they should all have different scopes

[tommythorsen]

@ianbjacobs

In the summary [1] I wrote 'There is some support in the task force for renaming the specification to more closely reflect the features it adds to the Web platform (e.g., "Payment Handler API").'

What do you think of that name (courtesy I believe of @jakearchibald)?

I think the name "payment handler" is a lot more generic and carries a lot less information and meaning to prospective developers than "payment app" does. However, if we decide to not focus on apps anymore, in favor of origins, wallets and options, "Payment Handler API" is an appropriate name.

@adrianhopebailie

I like the idea that any Service Worker that registers options, automatically groups them under their origin. The origin is not an identifier it is a "default wallet".

Say we do it this way -- where do we get name and icons for the origin entry?

I think this is the main weakness of focusing on origins over apps. In the apps case, my first example is super simple, since it picks out name and icons from a web page, using existing algorithms (and presumably, existing implementation). If we want to pick this information out of an origin, we will need to require payment app implementors to do something that isn't currently standard practice. We can require HTTP GET / to return an html page, or certain link headers, but I don't feel too good about making this kind of requirements.

[adrianhopebailie]

Say we do it this way -- where do we get name and icons for the origin entry?

The same way you did in your first example. If there are multiple SW registrations from different pages then use the icon and title from the first page. If the page has an App Manifest then use that.

I don't think we need to specify how the browser gets the bits it uses for UI. Some brwoser may not even want to display an icon or label at that level, just the origin.

[ianbjacobs]

@tommythorsen, we discussed this issue at today's call [1]. The sense on the call is that the spec has advanced to the point where we can close this issue. Also, @mattsaxonwp has volunteered to create a diagram for the spec.

Are you ok if we close this issue?

Ian

[1] https://www.w3.org/2017/04/04-apps-minutes#item05

[tommythorsen]

Yes, let's close it.