See also: IRC log
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
IJ: Consensus to use new request/response objects for payment apps
https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0016.html
IJ: Are we close to payment request response? Do we need to make changes?
adamr: I haven't looked specifically to see where variations are.
IJ: Opportunities for better alignmetn?
rouslan: I think Marcos prefers
dictionaries over interfaces
... and dictionaries are composable
... so I think the payment app dictionary should include the
relevant PR fields
... (and not things like "options")
... and in addition, we will need some things not in payment
request like origin
https://w3c.github.io/webpayments-payment-apps-api/#sec-app-request
<adamR> (1) Add “paymentRequestId”; (2) change “total” to “details”
PROPOSED: Close issue 99 by keeping a new object in payment app API
adamR: We need to add paymentRequestID and we need to copy the details
<Zakim> rouslan, you wanted to say total should still be there, but line items should be added
rouslan: Total should still be
there, add line items
... I think it's useful for the payment app to know both
<adamR> https://w3c.github.io/browser-payment-api/#dom-paymentdetails
adamR: The current structure of
payment details includes total
... I don't think we should factor out the total
rouslan: +1
<scribe> ACTION: AdamR to write a pull request to align the payment app spec with payment request objects [recorded in http://www.w3.org/2017/02/14-apps-minutes.html#action01]
AdamR: While we could make some
cases by refactoring some things in Payment Request API, I
think that's overkill
... so let's reuse structures and names
(Seeking support for proposed resolution to 99)
<rouslan> +1
(No objections)
SO RESOLVED
I have no updates on action from Marcos/Tommy
Ian: I will follow up on the time
frame for that.
... but I think we have consensus
See IJ proposal
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278754087
<Zakim> rouslan, you wanted to talk about the proposals
rouslan: I think that Adam's
proposal has some good properties; I suggest we just use
that.
... let's talk about Marcos' comments about web apps having
same power as native apps
adamr: The one diff between Rouslan/my proposal was how missing properties are handled; but otherwise the proposals were identical
IJ: There are several things to write up:
The capability syntax and a matching algorithm.
How the constructor changes to allow the merchant
to provide capability matching data.
Where in the algorithms to mention application of the
capability matching algorithm
* How payment apps provide the data
<scribe> ACTION: AdamR to incorporate capabilities in his pull request on granular data get/set [recorded in http://www.w3.org/2017/02/14-apps-minutes.html#action02]
<scribe> ACTION: Rouslan to work on text that would go in payment request API regarding capabilities [recorded in http://www.w3.org/2017/02/14-apps-minutes.html#action03]
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278851432
adamR: canHandle() is gone since
we are no longer doing in-app filtering
... we also should not revisit canMakePayment decision that "up
to browser"
... also +1 to proposal from IJ that says "simple checking
before app launched; powerful checking after app launched"
IJ: I suggest then that:
1) PROPOSED: Adopt https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278754087
<rouslan> +1
<adamR> +1
<pascal_bazin> +1
(No objections)
SO RESOLVED
2) Ian will update the issue with pointers to what happens next (ACTIONS, etc.)
Proposal from IJ
https://github.com/w3c/webpayments-payment-apps-api/issues/74#issuecomment-278340715
IJ: Proposal is basically (1) remove from payment app API and (2) continue to work on either as good practice or as a separate layer (or both)
alyver: Shopify would like the
group to continue to work on payment apps
... there are two situations to look at:
... recommenation of an app already registered
(e.g., where merchant preference can be reflected)
Ian: recommendation of an app not yet registered
(where bootstrapping the ecosystem is valuable)
Ian: so there are at least two topics (1) expression of merchant preferences (2) bootstrapping the ecosystem
alyver: One suggestion in the proposal was to leave for later discussion...but I have concerns about the impact on payment API, and if we leave too long there will be implementations that are difficult to change
[IJ summarizes state of discussions around problem statements of bootstrapping the ecosystem, and expression of merchant prefs]
(No takers on actions)
adamR: I haven't heard anyone
describe what the user experience will be when someone
recommends an app that has not been installed.
... it would help if someone wrote down that user
experience.
Ken: Relationships with card
members, merchants are very important to us
... this is an important/sensitive topic that demands
caution.
alyver: Regarding user
experience, the original expectation for recommended
(unregistered) payment apps was on-the-fly registration
... or at least take the user to a site to install/register the
payment app
... there were security concerns raised about sending customers
to malicious sites
... Tommy's proposal (
https://github.com/w3c/webpayments-payment-apps-api/issues/74#issuecomment-278941318
) is also interesting in that apps are recommended only when
payment request API has failed
... but that doesn't address the merchant preference piece
adamR: Regarding Tommy's
proposal, that does not need API support
... we should tease apart the two experiences of "preference"
and "recovery"
Ken: Here are two use cases to consider
1) Merchant does not accept card payments and has no existing contractual relationship regarding recommendations; I can see this feature as valuable to merchants
2) Merchant has contractual obligations and recommendations might present a conflict
alyver: Merchants choose (or not) to surface recommendations.
<alyver> I would be happy to discuss offline to understand your use cases further
Ken: I can do some more work to
outline scenarios that would likely not create conflicts.
... in physical stores a scenario that is analogous that is not
desirable from our perspective is merchant guidance to use
alternative payment methods.
(let's move on)
Ian: Adam indicated he would write a proposal for setting payment method information at finer grain than setManifest. The proposal will take into account Mathieu's desire for easy reset.
Adamr: It will look a lot like
what I proposed already, but I want to do some thinking about
how to fit in something like a "wallet" between app and
instrument levels
... I intend to roll that layer into the proposal
IJ: Time frame?
AdamR: This week (I hope); put on
agenda next week
... related is the issue of 69/70/90
... we will need to give names to options
... I've heard that payment apps want to render card art for
cards
... this means we'll need icons as well
... the app manifest files are overkill for our payment option
level needs
... using app manifest for credit card art is overkill since
there is so much else that does not apply in those manifest
files
... we can discuss that in light of the forthcoming pull
request
pascal_bazin: I am happy to work with Marcos on the coding
\o/
<scribe> ACTION: Ian to write to marcos, pascal, and tommy to see if three of them can get to work on that coding portion [recorded in http://www.w3.org/2017/02/14-apps-minutes.html#action04]
21 Feb