Payment Apps Task Force -- 17 Jan 2017

adamR: My recollection is that this was done intentionally.
... as a matter of privacy...if I am buying something I don't want a payment provider to know about, that might not be something I want passed along.

jnormore: It's pretty common for merchants to prefer to not want to pass that along, but it's also common for them to not care, in order for the payment provider to offer a better experience, e.g., to show the items to the user
... I would lean in the direction of "OPTIONAL"
... as a reflection of status quo

rouslan: If I recall, android pay requires total and displayItems are OPTIONAL

jnormore: From a merchant perspective, the diff between providing between Android Pay and a third party...in the case of Android Pay you are not passing it to a third party...you are just passing to the device for display
... that's when it becomes a concern from a merchant perspective.

frank: We do prefer to have the shopping card items to do risk assessment and to improve user experience.
... it should definitely be optional

adamR: Regarding the display, these items are still going to be displayed to the user as part of checkout...
... as far as making them optional, that sounds like a reasonable compromise
... so we'd need a flag in PR API to indicate whether to pass details on to the payment app

ian: I also heard people might hesitate to pay if they don't see what they are paying for.
... especially in a context where you are doing other things, e.g., relate to coupons

frank: To add to that, in our context, the payment does not happen at the time of purchase. We extend credit, and payment happens at a later stage, and the user needs to see that data when the payment has to happen post purchase.

rouslan: I would prefer not to have another flag in payment request API

<frank> +1

<jnormore> +1

rouslan: PROPOSED - details are optional at PR API level (as the spec already says), but if provided are sent to the payment app. E.g., we could add guidance to merchants to not show sensitive names.

<alyver> +1

<jnormore> +1

<frank> +1

<adamR> +0

<Max> +1

IJ: Should we update the spec to indicate display items and that it will be null if not provided in PR API?

<scribe> ACTION: Ian to update the spec to indicate display items and that it will be null if not provided in PR API [recorded in http://www.w3.org/2017/01/17-apps-minutes.html#action01]

Issue 73: Need to specify behavior for Clients.openWindow

previous action - Rouslan to look into how progress web apps could help

us understand how to manage UI in different contexts.

https://github.com/w3c/webpayments-payment-apps-api/issues/73#issuecomment-273119925

rouslan: Spoke about this a bit. The consensus in Google seems that "progressive web apps" will not be of much help; but we have to keep looking into this.
... I still think it's right but they were tepid; so maybe I need to explain better.

<frank> +q

frank: The current implementation, when the web-based payment app is opened in a separate tab, .... I share the concern that that's probably not the best UX and also problematic with it being separate from the merchant site from a flow perspective.

adamR: I still think that if we are concerned about the tab experience, we need to point out how that can arise.

https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display

AdamR: It's still a note:

"Implementations may vary on how windows open. For example, while opening an entirely new window is possible, it is more likely that the contents will be rendered in a way that makes it more obvious that the interactions pertain to the payment transaction. The opening of a payment app window versus other types of windows can be distinguished based on the event type the user agent is using to grant permission to open a window. "

adamR: We can make it normative if we feel it's important to do so.

rouslan: +1 to adamR...I think this should not be a different API call.
... in terms of making sure that the window looks correct, that should not be in this spec.
... I think we should wait for browsers to implement this, and then provide suggestions if they get it wrong

IJ: that suggests a change to "must call clients.openWindow()"

adamR: It's not clear to me what bad scenarios will arise by calling clients.OpenWindow

frank: Tommy's point is that client.OpenWindow() does open in another tab

adamR: User agent should render this in a way that is different from normal windows, to make it clearer to the user that this is part of a payment flow.
... and the user agent can use information (as the note points out) to determine when to do so

frank: I thought opening tab was standard behavior

adamR: Spec says "new browsing context" but doesn't say tab..it's left up to the user agent

<frank> ok. great

rouslan: I think that Tommy's implementation uses the default implementation. But we would do a custom implementation before releasing that would do the right thing wrt opening a payment window

[Rouslan leaves]

(We have not looked at issue 10 and 11 lately)

AdamR: I think we need more service worker expertise here.

https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display

<frank> I have it as 10.4

10.4!

<scribe> ACTION: Ian to revisit 10.4 to make clear that (1) we want payment apps to use the standard API call but (2) what happens will be UA-determined given this a payment context (3) some guidance about not confusing the user [recorded in http://www.w3.org/2017/01/17-apps-minutes.html#action02]

(IJ I will get rid of the first note and integrate better)

I will ping Tommy on the edits

Issue 83: payment-manifest.json and canHandle function

https://github.com/w3c/webpayments-payment-apps-api/issues/83

AdamR: canHandle() appears in code. This is not in a JSON file

https://w3c.github.io/webpayments-payment-apps-api/#register-example

scribe: I would not call the JS objects in the example "JSON".
... there's a separate topic - we want to make those objects serializable as JSON
... if we have a reason to do that.

Example 1: Payment App Registration

frank: why are "quotes" there?

IJ: What should happen there?

AdamR: Suggest removing quotes

(IJ will do that)

(We also look at Rouslan's comment)

adamR: Right now if you are a mediator trying to determine matches, you can do so by looking at payment methods and calling canHandle()
... but if we move to an event model, you need to find the service workers and see if canHandle() there
... but the big issue is that canHandle() needs to run in a particular context...making it harder to do Rouslan's approach

<scribe> ACTION: AdamR to weigh in on issue 83 on (1) JS v. JSON...and we are fixing quotes; and there is no file required and (2) canHandle() should not be an event [recorded in http://www.w3.org/2017/01/17-apps-minutes.html#action03]

(IJ sees typo in enabled methods: canHandl)

FPWD goals

IJ: Other than the list in the agenda, anything else obvious we should address before requesting FPWD?

(No replies)

Next meeting

24 Jan

scribe: we will review Adam's text on issue 79
... and also revised text around 73 (from Ian)
... another topic raised by Jake Archibald - can we have an end-to-end example of how things work?

Payment Apps Task Force

17 Jan 2017

Attendees

Contents

recent edits

payment app identifiers

recent edits

Tommy's pull request regarding PaymentAppResponse Dictionary

Clarity on whether top-level displayItems sent to payment app

Issue 73: Need to specify behavior for Clients.openWindow

Issue 83: payment-manifest.json and canHandle function

FPWD goals

Next meeting

Summary of Action Items

Summary of Resolutions