See also: IRC log
<conorhwp> Apologies for late arrival.
=> https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0006.html
"Proposal" => https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
IJ: Any status update from Andre on his action?
jnormore: No; I'll ask him.
AdrianHB: I plan to work with Andre on this this week.
<AdrianHB> There is some useful discussion here: https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-277813048
IJ: anything strike anybody wrong or incomplete?
[Silence]
AdamR: Some info in the payment
request data is specific to payment apps and not from the
payment request (e.g., optionID option selected by the user,
and perhaps merchant origin)
... so the data we send to the payment app is not strictly a
subset.
IJ: Any implementation experience?
AdrianHB: We discussed reusing
payment request back in SFO ftf meeting
... I think that right now purchase and payment information are
tightly coupled
... If we reuse the payment request object in the payment app
we want two things:
a) Strip out data to only those payment methods supported.
scribe: that's doable by the user agent
b) There is also information relevant to the payment app that is not relevant to the merchant.
adamR: I don't think that teasing
apart purchase from payment would make this any easier. It
would be dangerous to have information populated by the
merchant (e.g., origin)
... Marcos' comments relate to reusing form fill (regarding
data collection)
... I am pushing back against that part of the proposal because
I think it is inadequate to the task
AdrianHB: We could change the
shape of payment request (on the PR API side) to make it more
reusable.
... with merchant-specific parts and app-specific parts, but
reusable
... regarding reuse of form fill; I am not getting into that
debate.
... the group has already resolved to gather data in the way
that PR API currently does
adamR: What may be useful here is a statement from the chairs that the way that data is gathered has been defined.
<scribe> ACTION: AdrianHB to reread issue 99, consolidate the topics, and report on the state of relevant decisions by the group. [recorded in http://www.w3.org/2017/02/07-apps-minutes.html#action01]
IJ: PR API does not talk about
payment apps, so even though we could modify PR API
... to include data specific to payment apps, that would break
that wall
adamR: Should we, in PR API, add
an ORIGIN field to the payment request object to convey the
origin to the payment app.
... but that would not be available to the merchant (so may be
awkward)
rouslan: It's true that payment
request object should not have an origin on it
... second, I think we could still pass the payment request data
structure unadulterated to the payment app if we used
composition
... we can have a payment request container object that has
original payment request object and payment app specific
data
adamR: That would be fine.
AdrianHB: But we still need to strip out some information (e.g., "requestShipping" flag)
IJ: How complex to strip out the data?
Rouslan: Currently what we do in our implementation for payment apps:
* We take the payment request object that has payment method data, modifiers, shipping options, and transaction details.
* We take part of that data and send to the payment app: method names supported by the payment app and merchant accepted + their method-specific data + shopping cart details including modifiers relevant to the payment method intersection
scribe: so we do strip
information out
... it would be great to reuse the payment request object with
irrelevant data stripped, composed with other data from the
user agent specific for the payment (e.g., origin, option
id)
<AdrianHB> https://w3c.github.io/browser-payment-api/#paymentrequest-interface
scribe: that's not the cleanest
approach in that many fields of the object will be empty.
... so I think I would favor a new type of object
adamR: That's what I would think
<Zakim> AdrianHB, you wanted to note that the PaymentRequest inteferface is completely inappropriate for sending to apps
AdrianHB: I agree. If you look at
the payment request interface...it's the wrong thing to send to
a payment app.
... the only way we could make this worth is if PR API
changed
... e.g., if you passed the API a container object...
... I have a proposal!
... ...we don't think we can reuse payment request object
unless PR API changes. He may disagree with that.
... but if he agrees, then he may need to convince people to
change how PR API works
rouslan: I'm not sure how much we
would change to make payment request object more usable.
... I think this is unlikely
<scribe> ACTION: AdrianHB to propose to Marcos that we go forward with the "new object" approach, with rationale, and follow the discussion. [recorded in http://www.w3.org/2017/02/07-apps-minutes.html#action02]
IJ: Are people still open to reusing the object if it can be done in a way with minimal disruption to PR API AND without a lot of empty data fields?
<rouslan> +1
IJ: I don't hear anybody saying
"reuse is bad" only...we think there's a cost to revamping PR
API.
... and as-is doesn't seem to lend itself easily to reuse in
payment apps
https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0008.html
IJ wrote:
It seems that we need:
* To define the openClientWindow() method (somewhere; maybe in 10.4)
* To review the text in section 10.4. Some of the cautionary statements there could be deleted if we have
a method that is known to do the right thing on a variety of devices.
* Review example 3 which mentions clients.OpenWindow (but see below regarding Example 3)
IJ: and Marcos volunteered; and I suggested he work with Tommy (he said cool)
adamR: +1 to that path forward. I agree with the approach being proposed.
<AdrianHB> +1 to openClientWindow method on event. Yay!
Ian: Great, I will return to this topic in a couple of weeks to check in on their proposal
<AdrianHB> https://github.com/w3c/webpayments-payment-apps-api/issues/97
<AdrianHB> is probabaly best issue
IJ: Question - what should we support (e.g., from "nothing" to "merchant expressed preference as a list of IDs")
rouslan: Origin is sufficient for
both web and native apps.
... so if we do this, can be a list of origins
... I am ok with limiting what the merchant provides to be a
list of payment app identifiers..and those identifiers should
have the same form for both native and web
<Zakim> rouslan, you wanted to talk about native
<Zakim> AdrianHB, you wanted to mention how permissions API could be used by merchants to test for app with cooperation of payment app
AdrianHB: I think we are still
figuring out whether the identifiers are origins or something
else
... my argument against recommended payment apps in v1 is that
we can achieve much of what we want via the permissions
model
... Merchants and payment app providers can work together to
detect where permissions have been granted
... and payment apps can communicate information to the parent
merchant, allowing the merchant to tailor the user
experience
adamR: What AHB described may be
ok for a workaround. But I think recommended payment apps serve
a couple of purposes (1) merchant promotion of payment types in
the flow....I don't think this is critical for v1 of the API
(2) Building out the ecosystem, which I think we cannot forego
in version 1
... so I think we need something to help bootstrap the
ecosystem
... if we can demonstrate that permissions suffice and are easy
enough to use for merchants, that's fine
... but I'm afraid that it probably won't be and we need
something to raise awareness about payment apps
... some affordance, even if they don't appear alongside
registered things
jnormore: Three things!
(1) From a merchant perspective I'd rather have support for recommendations with less power than no recommendations at all
(2) What's important is when no payment apps are installed. (Prioritization of payment apps is not a priority issue; I agree with AdamR)
(3) Agree that the approach AHB cites is conceivable but also complex and may make life hard for smaller m erchants
<Zakim> rouslan, you wanted to talk about plausibility
<adamR> Jason said something important that I didn’t: the key thing we need to avoid here is a no-match situation. Even if we invoke the installation only in these cases, it helps the situation a lot.
rouslan: In our chats with
payment app distributors, they said they have relationships
with merchants, and they put iframes in pages.
... payment app providers want to give users a very easy way to
install a payment app
... so they want support for bootstrapping
IJ: If bootstrapping is important, then it seems that "highlighting registered" is not an important thing
<Zakim> AdrianHB, you wanted to say that recommended apps can be added later easily
AdrianHB: I think we have a lot
of assumptions about market dynamics where we are
speculating.
... I think recommended payment apps is a feature we can easily
add without breaking the API
... it's an additive feature to payment request
... I would encourage us to take a step back and I think
bootstrapping will not be as big a problem as we think
... if our concern is bootstrapping third party payment apps, i
think that's different
14 Feb
<conorhwp> Regrets for next week due to travel.
IJ: Any interest in whitelisting payment apps? We may not want that and browser vendors may have no interest
AdrianHB: It may also be possible to do this declaratively, outside of the API