Thoughts on the current spec

[rsolomakhin]

Hi All,

Thank you for drafting up the spec. Here are my initial thoughts from the standpoint of a browser implementer. Let's discuss this in further detail.

Registration

I am of the opinion that installing a payment app is sufficient to register it. On the web, this can be accomplished via registering a Service Worker and there's no need for additional navigator.payments.register(info) API. Operating systems have their own concepts of installing native apps, but the spec should not concern itself with native app much, if at all.

Payment options

The spec allows payment apps to take up several lines on user screen via a concept of "payment options." (For example, if BobPay is a credit card wallet, then it can show BobPay Visa*1111 and BobPay MasterCard*5454 as payment option.) I have heard feedback that this may not be desirable for the first iteration of the payment app spec, because it's one more layer of abstraction with marginal benefit. Let's stick with one-to-one mapping here for now. So BobPay should be able to display only one item on browser UI: "BobPay".

Network considerations

The spec talks about network failures. I think Service Workers are the answer here. They provide offline capability and caching, if necessary.

[ianbjacobs]

@rsolomakhin,

Thank you for the feedback and welcome to the task force.

I am of the opinion that installing a payment app is sufficient to register it. On the web, this can be
accomplished via registering a Service Worker and there's no need for additional
navigator.payments.register(info) API.

I think many would agree that any native app installation could include payment app registration and thus no additional user action would be necessary. However, for the Web-based payment app case, please say more about how the user consents to register the payment app. I think consent is important because you don't want payment apps mysteriously showing up in your "matching apps" list merely because you happened to visit a Web site. So it is likely that some user action is required to tell the browser about the payment app data. I'd love to hear more of your thoughts on how you see this happening.

I think there is strong agreement that we want to make it as simple as possible for users. Other than the native app installation use case, the other case we have been talking about is when the merchant recommend an app and the user chooses it, this could be the action that registers the app. It has also been pointed out that registration is not obligatory in this case; it's just useful if you want persistence of the data for future transactions.

Let's stick with one-to-one mapping here for now. So BobPay should be able to display only
one item on browser UI: "BobPay".

Ok, that's helpful input on that question.

The spec talks about network failures. I think Service Workers are the answer here.
They provide offline capability and caching, if necessary.

Do you think we need to provide any information (e.g., a transaction identifier) that
could be used to query the state of a transaction?

Related: We have spoken about creating a "payment app good practices" document that could
include this sort of information (e.g., how to use service workers to deal with network failures). See also our early draft of https://w3c.github.io/webpayments/proposals/method-practice/

Thanks again!

Ian

[rsolomakhin]

For the Web-based payment app case, please say more about how the user consents to register the payment app.

There're several options available to us. From the top of my head, one method is to gate payment app Service Worker registration on user activation. So the user must click an [Install BobPay] button for register() call to succeed.

// Payment app is a Service Worker, but register() can be triggered
// only by a user activation.
navigator.paymentApp.register('/sw.js').then(function(registration) {
  console.log(registration);
}).catch(function(error) {
  console.log(error);
});

When the merchant recommend an app and the user chooses it, this could be the action that registers the app.

Sure, I can see this happening.

1. Merchant recommends https://bobpay.xyz payment app.
2. Browser fetches icon, label, and the location of the Service Worker from https://bobpay.xyz/payment-manifest.json.
3. User selects BobPay from for payment.
4. Browser installs the Service Worker https://bobpay.xyz/sw.js and immediately triggers its onpaymentrequest event.

Do you think we need to provide any information (e.g., a transaction identifier) that
could be used to query the state of a transaction?

This would fit well into your "good practices" document as optional advise. Some payment apps might need this, but others may not.

[adrianhopebailie]

Sure, I can see this happening.

1. Merchant recommends https://bobpay.xyz payment app.
2. Browser fetches icon, label, and the location of the Service Worker from https://bobpay.xyz/payment-manifest.json.
3. User selects BobPay from for payment.
4. Browser installs the Service Worker https://bobpay.xyz/sw.js and immediately triggers its onpaymentrequest event.

Is https://bobpay.xyz a payment app or a payment method?

[rsolomakhin]

Is https://bobpay.xyz a payment app or a payment method?

Both. Is that OK? Sorry for the confusion :-)

[ianbjacobs]

@rsolomakhin wrote:

There're several options available to us. From the top of my head, one method is to gate payment
app Service Worker registration on user activation. So the user must click an [Install BobPay] button > for register() call to succeed.

That was my expectation. To summarize, I see it this way:

• There is a register() function
• It is called in different ways (e.g., during native app installation, as a result of selecting a merchant-recommended app, or upon explicit "register me!" for a web-based payment app).
• It is not always necessary to call it (e.g., one-time usage of a merchant recommended app)
• We want the user to have to do as little as possible to register a payment app, and consent is important but happens in different ways (e.g., explicit installation of a native payment app constitutes consent to register it).

Does that align with your thinking?

Ian

[rsolomakhin]

All of this aligns with my thinking except for

during native app installation

bit. I don't think native apps will call the register() function. Registering native apps may have nothing to do with the register() function. Can we state only that "Browsers and native apps have a platform-specific way to register with each other"? The more relaxed our phrasing here, the better for now.

[ianbjacobs]

@rsolomakhin wrote:

I don't think native apps will call the register() function. Registering native apps may have nothing to > do with the register() function. Can we state only that "Browsers and native apps have a platform-
specific way to register with each other"? The more relaxed our phrasing here, the better for now.

Yes, that's fine with me. The main point I wanted to make is that "registration will happen as part of some other event so that additional user interaction is unnecessary."

Ian

[adrianhopebailie]

Both. Is that OK?

No ;) One is a component and one is a capability. I can imagine the manifest for the component defining that it has the capability but not the manifest that describes the capability also describing the component.

But let's start a new thread on this.

[adrianhopebailie]

There is a register() function

Is this needed if payments apps are ServiceWorkers? There is already a way to register SWs

It is not always necessary to call it (e.g., one-time usage of a merchant recommended app)

I don't follow how this would work.

[adrianhopebailie]

The spec talks about network failures. I think Service Workers are the answer here.
They provide offline capability and caching, if necessary.

Do you think we need to provide any information (e.g., a transaction identifier) that
could be used to query the state of a transaction?

The issue here is with push payments where the website gets no response from the app and so has no way of knowing if the payment was completed. I think we need a holistic approach to this including a unique transaction ID set by the browser and possibly a standard query URL that can be used to get the status of a payment using the ID.

[rsolomakhin]

There is a register() function

Is this needed if payments apps are ServiceWorkers? There is already a way to register SWs

The way to register SWs is through the navigator.serviceWorker.register() function. This is the register() function that I have in mind here. It's the same for Service Workers and payment apps. According to the broad consensus on issue #33, payment apps are Service Workers.

It is not always necessary to call it (e.g., one-time usage of a merchant recommended app)

I don't follow how this would work.

Normally your website would call the register() method in JavaScript to register a Service Worker. This triggers the browser registration logic. However, the browser can trigger this registration logic from a payment UI as well.

The issue here is with push payments where the website gets no response from the app and so has no way of knowing if the payment was completed.

Since this is relevant to push payments only, we should discuss it in the push payment spec, right?

[adrianhopebailie]

The way to register SWs is through the navigator.serviceWorker.register() function. This is the register() function that I have in mind here.

👍

However, the browser can trigger this registration logic from a payment UI as well.

👍 - so both will execute the registration logic of the service worker. i.e. There is no situation where a user uses a Payment App but that app is not registrered.

Since this is relevant to push payments only, we should discuss it in the push payment spec, right?

Well, the point is that pretty much all payments done from a third-party app are likely to be push from the perspective of the website. Said differently, payment methods that are handled by 3rd party apps are likely to process the payment itself before a response is returned to the website.

There isn't actually a "push payments spec" but we are putting more focus on how we can address push payments and if there is a need for changes to either the payment request, payment apps or payment method identifiers specs that are needed.

I think an easy way to allow the website to track the state of a payment request is to give each new request a UUID that is returned to the website through an event when the user selects a third-party payment app. The same UUID should be passed to the app in the request and can be used by the app and the website to reconcile the request with later events such as out of band communications between the app and the website's servers.

[ianbjacobs]

I am closing this issue since:

• We are moving in the direction of service workers, so addressing registration and network failures in that context.
• The point about instrument-specific data at registration is addressed in issue Should payment instrument details be included at registration? #12

Ian