See also: IRC log
=> https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0081.html
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
IJ: Any comments?
... Any volunteers to read it?
<pascal_bazin> I volonter
<frank> sure
Two volunteers for next week: Frank, Pascal
https://github.com/w3c/webpayments-payment-apps-api/commit/4430d10f1b0957196576b8018a095a4b5a26eb81
IJ: Next steps?
AdamR: I haven't seen support or opposition.
<rouslan> statement of support
+1
s/americanexpress/amex
AdamR: My proposal does not touch
the request/response object. It assumes filters are going to
come in.
... I do have an outstanding todo for aligning
names
<scribe> ACTION: AdamR to flesh out his proposal to put in place text around procedures for using these IDL constructs [recorded in http://www.w3.org/2017/02/28-apps-minutes.html#action01]
AdamR: Another thing that I would
like to do or see done and relocating explanatory tex to
appendix.
... so examples and IDL are nearer the top.
<scribe> ACTION: Ian to move explanation to the bottom [recorded in http://www.w3.org/2017/02/28-apps-minutes.html#action02]
AdamR: I spoke with Marcos last week. I plan to take some of his examples (finer grain) and integrating into my proposal
+1
IJ: What is status of Marcos/Tommy/Pascal conversation?
Pascal: We have not made progress yet.
IJ: Please keep us posted; will be good to have code in the spec
Pascal: What kind of code do you want?
https://github.com/w3c/payment-request-info
----
* Getting permission
* adding, removing, updating, payment methods
* handling .canMakePayment(),
* handling POSTing for payment (without a secure window).
* Getting the browser to open a secure window
* handling PaymentRequest .abort(), .updateWith(), and whatever else
PaymentRequest can throw at us.
* creating a PaymentResponse - and showing how it coordinates between
the secure window and merchant.
* Other critical things that I can't think of right now... Please add them!!!
---
AdrianHB's list:
====
- Handles multiple payment methods:
o Basic-card payment.
o Web App payment (mine and tommy’s)
- Rendering UI for payment confirmation or cancelation
- Use of the manifest to create explicit choice
- Management of Payment request options by the merchant
- Feedback of the shipping options to alter the amount
- Use of the payment response details by the payment app
- Use of the payment response details by the merchant (for display)
- Registration and more around the service worker control
====
Pascal: I can gather what I have
in small examples
... can put that in once place and let editors put the code
where it goes
<scribe> ACTION: Pascal to gather example code; send link to WPWG [recorded in http://www.w3.org/2017/02/28-apps-minutes.html#action03]
(IJ: How should we do this on github?)
AdrianHB: The original request
from Marcos was not to write working code, but rather code that
showed how we would use the API to see if it makes sense
... I had understood we would write things the way we want them
to work, and then design the API accordingly
AdamR: .canMakePayment() is no
longer relevant
... I believe the example for POSTing for payment means take
the current example and update it
https://github.com/w3c/webpayments-payment-apps-api/pull/101
IJ: May have been fixed
AdamR: If so, that addresses handling POSTing
<Zakim> AdrianHB, you wanted to suggest we agree on use cases before diving into code
AdrianHB: I think it would be useful to agree first on the things we need examples for.
Adrian: I don't just mean
functions. I mean different scenarios like "one service worker
per payment method"
... "I have 4 options that I want to separate into wallets"
IJ: Is the latter part of AdamR's proposal?
<AdrianHB> The proposal from Tommy: https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Apps%20and%20Workers%202.md
AdamR: I think we probably do
want to keep the WebIDL in concert with examples
... otherwise it could be difficult, e.g., to write examples
that are mutually consistent
... +1 to a place with lots of examples that we can cherry pick
from for the spec
... examples.md
<AdrianHB> https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
AdrianHB: This will also help with testing
IJ: Let's update Pascal's action to start to edit https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
Pascal: We may need to differentiate code example from app example
<pascal_bazin> pjbazin on Github
IJ: AdamR, do you want to put some code in there too?
AdamR: Don't think it's necessary but not opposed
AdrianHB: Let's not waste time; just put in the spec if we are happy with code....this examples.md is a scratch pad
AdamR: I distinguish code to illustrate the design from code to drive the design
https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-279904374
IJ: Should browsers (good practice) offer a feature to let users share or not share line items with payment apps?
AdamR: It's still my position that these strings should NOT be passed through, but I understand that's not the prevailing sentiment
alyver: There are cases where you
do want to send it through, e.g., credit cards for level 2 and
level 3 requirements
... specific to credit card transactions (corporate
cards)
... if there's a payment app that handles corporate
purchasing
... you would need additional data to get a lower interchange
on that transaction
adamR: Is this something that's possible to do based on text, or do you need structured data?
alyver: E.g., shopify would send
this data to downstream processor
... you'll have quantity, amount, tax amount, description
... just treated as strings; no validation is done
AdamR: We probably want to
collect information on this. if it's a requirement on the API,
we want to make sure that what we have is adequate to satisfy
those requirements
... e.g., we don't have quantity indicator, etc.
... these would be new requirements (on PR API, not payment
apps)
alyver: It's really for corporate purchasing cadrs
Frank: Ian summarized our use
cases: credit based on risk assessment and what is
purchased
... we also send an invoice (similar to payPal) ... payment
happens at a later stage and it's useful to know what you
bought
<Zakim> AdrianHB, you wanted to ask if there are other ways to get the data?
AdrianHB: Are there other ways to
get the data?
... its sounds to me like this use case is potentially payment
method specific.
... if you are using basic card but the line items are only
appropriate for certain cases, you could provide data in
payment method data
Frank: Doesn't that complicate implementation? Easier if part of standard data set
AdrianHB: Yes, it would.
Adrian: One idea is for merchant
to say "don't pass on"; so browser displays but does not pass
on to the payment app
... and this could be done on a payment method specific
data
... payment details only passed to selected payment apps
... so merchants pass on only for payment methods where they
think payment apps need the data.
IJ: That puts control in merchants' hands rather than users'
pascal_bazin: We have to remember
that at least shipping option is included
... it's potentially always sent to the payment app
frank: If the main concern is privacy, sharing this with the browser isn't that as bad as sharing with actual payment providers?
<frank> Fair enough
alyver: +1 to AdrianHB's idea of a merchant being able to control whether line items are passed on to the payment app
adamR: I would hesitate for this
to be part of payment method specific data
... if it's a flag that the merchant controls, I think this
should be top-level
<AdrianHB> +1
<frank> +1
<rouslan> +0
<alyver> +1
IJ: Note that this is different
from merchant not providing data at all, since browser does
display line items in native chrome. This is just about not
handing data to (1) all apps and (2) thus only selected
app
... How is google currently managing this for native app
integration?
rouslan: We are sending line
items to native payment apps
... haven't really heard any feedback. I'm open to changing
this.
IJ: Should we address this with Pull request on PR API?
<AdrianHB> +1 - maybe an issue first
<alyver> Shopify officially providing feedback to Rouslan: As a default, we do not want to share line items to downstream payment apps.
<rouslan> alyver: ack
<scribe> ACTION: AdrianHB to raise PR API issue for discussion in the WG [recorded in http://www.w3.org/2017/02/28-apps-minutes.html#action04]
https://github.com/w3c/webpayments-payment-apps-api/issues/91
IJ: Rouslan had some updates to do and talk to MS
Rouslan: We pinged MS; they have
not yet replied.
... in general there are mixed feelings about this particular
change regarding addition of a filters field. We'd still prefer
a data field
... I understand that filters is a clean API...we trust
Mozilla's idea. But the backwards compatibility is an issue. If
MS does not implement "filters" as a key, there is less
motivation
7 Feb
IJ: Ideally we have an updated spec by 16 March
Proposed: Payment Handler API
<adamR> I support this change.
<rouslan> +1
+1 from me
IJ: Any objections?
<AdrianHB> +1
(Let's give people one week then we'll resolve this.)