See also: IRC log
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
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]
`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]
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]
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"
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
<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)
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]
11 April!