Payment Apps Task Force

yes!

https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html

<rouslan> thx

<scribe> agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html

triaged issues => https://lists.w3.org/Archives/Public/public-payments-wg/2017Apr/0010.html

Substantive maybe do before FPWD

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

MattS: These two issues (120 and 111) they didn't sound substantive to me.
... I suggest you reconsider the word "substantive"

IJ: I didn't mean "blocker"

rouslan: We are close on 120, but not a lot of time

https://github.com/w3c/webpayments-payment-apps-api/issues/120#issuecomment-289769943

Rouslan: There was a proposal to put iframeOrigin into the payment app request data.
... I think that's a good idea and we do that in android payment apps (was a requirement from multiple vendors)
... good to put in the handler spec as well...question was then about naming:
... some options are iframeOrigin, invokingOrigin, sourceOrigin
... I propose here that we go with source origin

adamR: It occurs to me that we have the potential for more than the root origin and the iframe origin
... these things can be nested
... one way to get around this is to pass an array
... and first element is root....second is iframe....then nested, etc

rouslan: Marcos also proposed an array
... I pushed back on that for 2 reasons..the full chain of iframes would be a pain to get in Chrome...there's also no use case to get the sequence of iframe

Frank wrote on Github: "I checked wth the PSPs we are working with and it seems like nested iframe is an uncommon practice so I am fine with your suggestion."

rouslan: ...so in practice we have 2 origins in practice

AdamR: What I have seen historically (but may no longer be done)....would be to frame a merchant site (e.g., for additional discounts)...which could then frame a payment

<alyver> removing myself from the queue. Rouslan addressed my same concern re: the usefulness of all the "intermediate" iframe origins

AdamR: If we are not seeing in the wild, then probably ok to go forward with proposal.

Summary of proposal: Pass origin of iframe that did payment request and call it sourceOrigin

scribe: in addition to 'origin'

IJ: I think those are not sufficiently distinct

MattS: topLevelOrigin and sourceOrigin

<adamR> SGTM

<alyver> +1

<rouslan> +1

Ian: Counter-proposal: topLevelOrigin and paymentRequestOrigin

<adamR> +1

<rouslan> +1

<AdrianHB> +1

<alyver> +1

<adamR> +10 to rouslan

<frank> +1

RESOLUTION: To include topLevelOrigin and paymentRequestOrigin in payment app request data

<scribe> ACTION: Ian to update issue 120 and edit the spec accordingly [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action01]

issue 111

`appRequest` attribute should not be a dictionary

rouslan: Original issue was syntactic...attribute was a dictionary...but IDL spec says dictionaries cannot be read-only attributes

AdamR: In the set of edits that I did, I changed from a dictionary to an interface, but that raised an issue about not being able to have arrays
... so they had to be changed to frozen arrays
... I think the spec is up to date

See Marcos' comment:

https://github.com/w3c/webpayments-payment-apps-api/issues/111#issuecomment-287944141

AdamR: There are a bunch of fields missing that we would have to add...that would not be used on the PR API side...that will probably receive pushback from the broader group

rouslan: payment app request is no longer a dictionary, so the problem is solved from my perspective.

adamR: I think we can close this.

<scribe> ACTION: Rouslan to close issue 111 with a summary [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action02]

issue 109

https://github.com/w3c/webpayments-payment-apps-api/issues/109#issuecomment-287705543

WalletDetails to PaymentWallet

or

PaymentInstrument to InstrumentDetails

<AdrianHB> +1 - WalletDetails to PaymentWallet

rouslan: I think that the general pattern is to prefix datatypes with the word "Payment"

so the would be PaymentWallet and PaymentInstrument

===

5.2 PaymentManager interface

5.3 PaymentInstruments interface

5.4 PaymentInstrument dictionary

5.5 PaymentWallets interface

5.6 PaymentWallet dictionary

===

rouslan: Don't be concerned about difference of "s"..the way that they are accessed in the API...Wallets is accessed through .wallets....and PaymentWallet is a dictionary
... so you don't refer to it by name...you could define it in curly braces
... so low risk of name collections in code

Proposal: "PaymentWallet"

<AdrianHB> +1

<rouslan> +1

<scribe> ACTION: Ian to update the spec with name harmonization of PaymentWallet [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action03]

.and close 109

Issue 117

IJ: seems like it's mostly about PR API

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

IJ: where in payment handler do we talk about htis?

MattS: We don't; we need a handshake
... if the payment handler supports Abort, then PR API should say that it honors Abort

rouslan: I think this is a good idea. Some payment apps will support abort, others will not
... abort is asynchronous....will succeed if abort succeeds and fails otherwise
... in PR API, the wording is "if the state of payment request is interactive" then abort should fail....we can change it to say that "if it's impossible to abort the third party payment app, then reject the abort promise" and then in the payment handler spec, we can define an event that would have to be responded to in the payment handler
... a payment abort event...and then the third party payment app would have the choice (e.g., based on logic or business requirements) to resolve or abort that promise
... the promise exists on the payment request side. On the payment handler side it's a payment abort event that has a "respond with" function that takes a promise

AdrianHB: If the abort event on the payment handler side lets you return a promise, we are getting into funny race conditions with the payment request promise.
... we should not allow the handler to resolve the abort promise but also resolve the payment request promise
... maybe you just raise an abort event and that's it; and the payment handler must resolve the request promise with a failure or something like that

rouslan: That's an excellent proposal....another thing we could do is in a respond with function we could respond with a boolean....@@missed
... let's have domenic or marcos take a look

<AdrianHB> +1 to synchronous response to abort event

IJ: AHB would you mind adding some ideas on GitHub?

Adrian: Sure

IJ: Where do we hook this issue into the spec?

MattS: Because this issue is related to handshake, we run the risk of not being able to take PR API to CR.

<AdrianHB> I note that we haven't entirely resolved Matt's issue (because we are saying we can't) but have proposed some additions to Payment Handler that would make it more complete

<MattS> https://github.com/w3c/browser-payment-api/issues/473

IJ: I will (1) put on this week's WPWG agenda and (2) move 117 to the list of "open at FPWD"

issue 105

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

IJ: I want to close this one due to evolution of the spec

MattS: Ok for handler; but there is some language harmonization to do in PR API around "payment app" or "payment handler"
... I raised an issue in PR API on that topic

<MattS> See https://github.com/w3c/browser-payment-api/issues/497

MattS: How I would like to see it resolved...payment handler could use an architectural diagram

<scribe> ACTION: MattS to create a diagram for Payment Handler showing the different components [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action04]

PROPOSE: Close issue 105

<adamR> +1

<MattS> +0

IJ: I will go ask Tommy if he's ok with that, and mention MattS is working on a diagram

Issue 74 - recommended payment apps

<alyver> Issue 74, not 74 - https://github.com/w3c/webpayments-payment-apps-api/issues/74

<adamR> alyver: Thanks! I was lost.

[IJ does background on current state of apps, prefs]

MattS: I am wondering whether we should put this in as an issue marker

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

Relation between merchant order of payment methods and payment app order of instruments #116

IJ: I would like to focus on 116 rather than 74
... that is: how do we make use of payment method info, rather than expect new info from merchants
... I am not sure that 116 is resolved even if we remove merchant order of payment methods

MattS: Please update 116 if you think it includes other aspects like user order of payment methods in browser

(IJ: will go back to look at 116)

MattS: I would leave in 74 for discussion by merchants

rouslan: In terms of issue 74, I believe that we can close 74 since the spec works fine as-is and we don't need to define any additional fields
... this could also be worked on in parallel
... my recommendation is to close 74
... since the use case can be satisfied without changes to the API

Ken: I support Matt's point and get more input from merchants...
... as well as card issuers and brands

IJ: If we leave it, it seems section 4 (Overview) might be appropriate

Ken: If one spec is providing prioritization and the other spec doesn't speak to it, there's a possible incongruency
... worth looking at how preferences are being asserted across all the specs

<adamR> As an aside, I’ll repeat that we’re making this harder than it needs to be by using the term “recommended payment app” to mean both “if you don’t have an app installed for a supported payment method, here is where to find one” and the very different “if you have more than one app installed that matches this payment method, please render them to the user in a way that highlights or orders them according to some scheme.”

<alyver> +1 to Adam's comment above. We discussed that same point previously, and I thought we had agreed to seperate those concerns.

IJ: I don't mind including a hook in section 4 asking for feedback on importance of a feature to (1)facilitate installation of a particular app or (2) highlight an already registered app.

<adamR> Right. We should burn the term “recommended payment app” and come up with two very different terms for the different concepts.

(+1)

Summary: Mention the 2 topics in question in the spec at FPWD (e.g., in 4)

Issue 69

IJ: I propose we close this given the way the spec is written

rouslan: There is no link to a definition of how image object works

adamR: We point to the definition in app manifest

<rouslan> +1

PROPOSED: Close 69 and open new issue about definition of "image object"

<rouslan> +1

AdamR: +1

<scribe> ACTION: Ian to close 69 and create a new issue about definition of image object [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action05]

AdrianHB, can you say what issue 5 means (on the mailing list or in github)?

<scribe> ACTION: Ian will update the list and send to the WG for discussion on Thursday [recorded in http://www.w3.org/2017/04/04-apps-minutes.html#action06]

next meeting

11 April!