Payment Apps Task Force

Disband the task force

Proposed: End regular TF calls; use this slot as needed for editors

<rouslan> +1

<alyver> +1

RESOLVED to end regular TF call and move topics to WG agenda

Implementation updates

rouslan: We've been implementing on desktop and recently landed a change that allows service worker to open a window to prompt the user for input
... we've not styled it yet....it's going to be "smaller" than a full size window

https://www.w3.org/2017/Talks/ij_uspayments_20170912/w3c.pdf

Rouslan: An issue we ran into - how to ensure the user does not think that the payment app window is NOT part of the web site
... we've decided that it will look like a pop-up window but that the user cannot resize or move it.

IJ: Heads up on accessibility issues.

Rouslan: It's just an HTML page; you can change font size, print it, etc.
... if you navigate to a new origin, it will probably open a new tab
... On cross-platform side, we have been experimenting with canMakePayment()...have not settled on it yet
... we think maybe there is a middle ground approach where service workers that use standardized W3C payment methods will be filtered by the browser because, when the merchant says "I accept basic card" they don't have as much controle
... for URL-based PMIs, and where the URLs are validated through manifests, we think firing canMakePayment event would be better.

IJ: If I understand:

1) For standard payment methods, static filtering

(static = browser-based in my mind)

2) For URL-based PMIs, fire an event (=payment app does capability matching)

Danny: What is the performance impact / user experience impact of firing an event?

Rouslan: Good question. In the original implementation we made canMakePayment required and we used a timeout
... currently, however, canMakePayment event is not required, so if your service worker is not registered for the event, you will not be penalized in terms of performance
... performance is definitely important....we have been creating the payment request object before the user clicks the checkout button
... when the user clicks the Buy button, we call show()
... that's because creation of payment request object initiates query of canMakePayment
... if you are on a slower device, it might take up to 2 seconds (in my experience) to query payment apps

<Danny_Wp> good tip!

Rouslan: because of that we've been recommending creating payment request object and call show() only later.

https://github.com/w3c/payment-request-info/wiki/CodeExamples

IJ: Should we add that performance-friendly note there?

Rouslan: It's not called out, but it's shown in the first example
... what happens on click event is request.show()

<Zakim> alyver, you wanted to ask Rouslan whether this is in canary?

alyver: Is the openWindow in Canary?

rouslan: I think it's landing now, should be there within a couple of days

<Danny_Wp> sorry i probably spoke out of turn

rouslan: We are also implementing payment method manifest; should be in Canary within 3-4 days
... if your service worker accepts basic card or inter ledger you're fine...if your service worker accepts a payment method of the same origin you are fine....
... if your payment app has a different origin than the payment method origin, then we download the payment method manifest and we check the supported origins field
... if the origins field is "*" anyone can use it
... if the supported origins field is a list of origins then we check against that list
... otherwise service worker not displayed to the uesr

IJ: Shouldn't expect it to never change (the spec) since not yet at FPWD, but good work!

Rouslan: Maybe we should write some tests.

IJ: Anyone want to help rouslan write tests for that?

[Crickets]

Pull request review

https://github.com/w3c/payment-handler/pulls

https://github.com/w3c/payment-handler/pull/194

https://github.com/w3c/payment-handler/pull/170

Rouslan: We are experimenting, balancing privacy and user experience
... mozilla folks are wrapping up work on payment request and then we should be able to work with them to get consensus

https://github.com/w3c/payment-handler/pull/194

https://github.com/w3c/payment-handler/pull/207

Rouslan: We are implementing it; we've not gotten any payment apps to experiment with this.

Danny: I can work with Rouslan on this.

IJ: Maybe include Frank Hoffman in experiments as well

https://github.com/w3c/payment-handler/pull/209

IJ: How is the text?

Rouslan: I will integrate your suggestion and upload the patch; I don't think we need a test for that.

https://github.com/w3c/payment-handler/pull/213

IJ: Adrian or Rouslan; please review the deletion

https://github.com/w3c/payment-handler/pull/214

AdrianHB: Do you think browsers should do something to help developers understand why a payment app was excluded?

rouslan: +1
... suggest printing console messages when something like this happens
... from our experience with app integration and manifest we've been quite silent with logging

<Danny_Wp> +1

rouslan: and this has confused develoeprs
... it's better when the code tells you what mistake you mde

<AdrianHB> do we need to say something in the spec?

IJ: What do devs want and what do browsers typically say?

Danny: +1 to good practices for logo sizes as well
... for payment apps

https://github.com/w3c/payment-request-info/wiki/PaymentAppPractice

rouslan: Icon guidance is a very good idea
... we are working on our icon selection algo right now
... where there are multiple sizes
... I think best approach is for devs to let us know their issues on logging messages in the issue tracker

IJ: Should we add something like "and should inform developers of the rationale for the exclusion"
... What user experience is there in the case where browser is not showing an app (e.g., manifest-based or error) is there a user experience explaining why?

Danny: One issue I've had in implementation is "what's the messaging that we have for users and merchants for the methods that the merchant supports that the user may not have installed, and the ones that the user has installed but are not accepted?"

<AdrianHB> Don't think we can have a normative req on UI but could put a SHOULD "indicate to users any apps that have been excluded and why"?

Danny: Should we have a standard UI for understanding who has what?

rouslan: Our hope is that there will be a single Buy button and that the button works by calling PR API with all of the merchant's supported payment methods, then the merchant falls back to a legacy payment flow
... but pr api is not powerful enough yet to support all the payment methods the merchant might accept
... the solution that we are trying to propagate right now is to come up with a graphic and phrasing to share with the world that
... we would recommend be used when payment request is invoked

<Danny_Wp> perfect. this would be similar to the contactless logo

<Zakim> Ian, you wanted to talk about mark

IJ: I am hearing:

1) Console logging is appreciated and messages to developers could be added to this pull request

2) What is the user experience in a couple of cases:

a) Exclusion of a payment app

b) Querying available payment methods

IJ: Is there any work going on in recommended payment apps (by the browser)/

rouslan: We are thinking about ways to suggest payment apps that have not yet been installed
... these would be shown "below" installed one

installed ones

scribe: we might show some recommended payment apps and do just-in-time registration
... and immediately fire PR API event for that service worker

<Danny_Wp> +1

IJ: Anything needed in the spec?

Rouslan: Don't think so; feels like user experience optimization

IJ: Should we spend more time on "informing the user of exclusions"

Rouslan: Ok to leave it in as "should" or "may"

Next meeting

None! We'll move to the WG

IJ: Thank you all very much!