See also: IRC log
present AdamR
Decision email => https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0035.html
nicktr: Thanks to all who
prepared the documents and those who reviewed them.
... chairs and team contacts have been discussing the feedback
and concerns as well
... there was broad support in the group to publish
... but also statements regarding implementation ("not planning
to")
... we will want to ensure we have implementers in the
group
<Zakim> manu, you wanted to offer next steps / plan
<ShaneM> Thanks for getting this moving!
Manu: The Editors chatted briefly before this call. Our plan is to change the title of Core Messages, update the prose to match that, and we are wondering if there are other changes people want us to make to finalize the specs for publication
nicktr: I don't recall seeing seeing others
IJ: Any interest in combining the specs?
Manu: I think we would like to
keep them separate for now.
... distinguish protocol from messaging
... at TPAC we will put forward a plan to address some of the
concerns that were raised, such as getting implementers in the
group.
... having the FPWD out there will help us in discussions with
other PSPs and sites that want to expose the API
IJ: I am happy to draft the transition request. Anybody other than chairs want to see it?
[No answers]
IJ: I will draft that today for the Chairs.
<manu> The editors will have FPWD-ready specs by next Monday.
IJ: Hope to have approval by Monday
Max: We had a brief discussion in
the payment apps task force about merchant control of app
ordering
... decided to bring the discussion here
<Max> https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown
[Max wrote a proposal for discussion
Max: The use case is that a merchant may want to highlight a particular payment method (e.g., because there is some period of time when that payment method is subject to a promotion)
===
The merchant website supports aPay and bPay.
The user browser has only registered bPay.
There is a commercial promotion campaign cooperation between merchant website and aPay.
The merchant want the user browser to display both aPay and bPay during the promotion cooperation period. It is preferred to display aPay in a higher priority.
===
Max: Merchant needs an API to influence the payment app display order
<Zakim> manu, you wanted to wonder if this is the thing that drove the card brands out of the room at our F2F meeting?
Manu: Right now we have payment
method order from merchant.
... are you suggesting an API instead?
Max: I am not sure what the mechanism should be...API is just an example. Other mechanisms to achieve the same goal of merchant-specified order are ok
rouslan: I would like to hear
perspectives from Amex.
... it would be good to get back to us on that
<manu> +1 rouslan - this should be /one/ of the signals that a browser takes.
rouslan: I think that we should enable the merchant to send preferences, but leave to the browser (using other data as well such as user prefs) to choose the final order
<manu> also, fwiw - +1 to declarative approach (in JSON) vs. imperative approach (API)
Roy: I definitely see the use case for this and why it is valuable. I get concerned about "going down the rabbit hole" of allowing the merchant to have final control over display
<dlongley> +1 merchants can implement this on their own by communicating with the payment app in some way
Roy: what is the value proposition of a merchant to use the API instead of implementing their own checkout flow, especially if they have a limited number of payment methods, and they have a desire to strongly control the ordering.
<Zakim> rouslan, you wanted to perhaps clarify Roy's point?
rouslan: to clarify Roy's point
further - the browser provides value to the merchant by
bringing in more signals like "which payment methods were used
on other sites" which the merchant would not know. This is a
value-add for the merchant.
... if the merchant controls everything there are no signals
from the browser.
<Zakim> Ian, you wanted to give some framing
IJ: Signals we have
<manu> Ian: Sounds like we're going to talk about signals, some of these signals include:
<manu> Ian: The first one is payment method order through the Payment Request API.
<manu> Ian: The second one is recommended payment apps
<manu> Ian: Some of the scenarios we can imagine are - if you are on a website, and merchant recommends their own app, they can decide if one of them is same origin and display that at the top. Browser may have other configs that are helpful to the user, though. The question is a choice between the merchant having enough channels to express their preferences where browser takes those signals into account.
<manu> Ian: or, browser has a definitive list - Roy/Rouslan said that if you want to take over the flow totally, then using the API doesn't help that much.
Max: Responding to
Roy/Rouslan...merchant doesn't want full control...just some
options to influence the ordering of the payment app. The
benefit is that some merchants are more likely to adopt the
payment request API if there is more flexibility to meet their
needs.
... we would rather have them using the API then falling back
to "the current way" of implementing their own checkout
flow.
... my opinion (to clarify) is not to give the merchant total
control of display order, just a mechanism to give the merchant
some flexibility to influence the display order
zkoch: Two quick thoughts -
...(Chromium 53 rolled out yesterday)....we have talked with a
lot of merchants
... as you know we are only supporting cards + android
pay..it's not been a blocker for merchants to accept the
API..it's limiting yes, but not a big blocker.
... in the end the merchants want to know whether the API has a
positive effect on convergence
... I don't think we need all uses covered for merchants to
adopt the API
... I will say that we have heard that there are use cases
where the merchant would like to guarantee definitively that a
payment app is available
... e.g., PayPal
... merchants would like, for example, not only to influence
ordering, but to guarantee that a particular app is
available
... so that's another "I need to guarantee" requirement
nicktr: Max, are you looking for there to be a new mechanism beyond payment method order and recommended apps?
Max: For me, I haven't spent a
lot of time thinking about solutions yet.
... I think we need more discussion to see whether the current
mechanism is sufficient to cover the use case
<manu> Ian: On the topic that Zach raised about guaranteeing a particular payment method...
<manu> Ian: I think we discussed this at some point, Zach, don't know if you put this idea of splitting accepted payment methods into two bundles - "must have support for these payment methods" and "I also accept these other ones". The merchant could get a signal back from "none of the required payment methods are registered".
<manu> Ian: Can you clarify, Zach?
zkoch: I made two contradictory
points - you don't have to solve all problems and "sometimes
there are must-haves"
... if we want to solve the nascar problem and have a single
"buy" button, then we need to solve this "must show"
problem.
... meanwhile, back to the question about required v.
also-supported payment methods, we've chatted a bit about
it...AdrianB is looking into how we could potentially address
this requirement.
<manu> Ian: Then the merchant can set preferred order if required instruments are there? I don't know what browsers are going to provide - going out on a limb, Max, do you think knowing that required thing is there and being able to specify order is sufficient?
<manu> Ian: Max, does having those two things meet your use case?
Max: Maybe...but need more time to work on it
NickTR: Sounds like it would be useful to have an issue to track against
IJ: I think we have an issue on this ...maybe we need to reopen if already closed to include this use case
<manu> Ian: I think we have an issue on this, will look into it later.
zkoch: No updates yet
https://github.com/w3c/browser-payment-api/issues/244
zkoch: Google's I18N team raised this issue
adamR: The rationale for putting
it there in the first place (and why I would like to keep
it)...is that it has semantic importance at least in the
US.
... I cite some references to legal postal code where these
things have legal force
... and it's semantically appropriate to include these in
addresses
<dlongley> +1 priority of constituencies (easier for users)
adamR: by not having this, we
either force users to put information in a place where it's not
convenient or obvious, or we make libraries more complicated to
deal with this
... priority of constituencies suggests we make the user's
experience easier
nicktr: I've not seen careOf in other APIs, FWIW
zkoch: There is a cost to support
this. While I agree with AdamR's point about preferring the
user experience, there are ways to address this.
... the browser could have a careOf field and put into the
recipient of the response...we do that already
... if you want to put a CareOf field, you need to figure out
as an implementer where to put it
... I do agree with Andy who raised the issue that there's not
a lot of evidence of this in use out there.
<Zakim> ShaneM, you wanted to mention that there are interop requriments with other standards like ISO 20022
ShaneM: We may also want to consider interop with ISO20022
<dlongley> is "care of" just a "special delivery instructions" field?
<adamR> dlongley: See the references I put on the issue
nicktr: I don't think I've seen careOf in a card protocol; I also don't recall (but it may exist) careOf in a payment protocol
adamR: We are still going to have to have these fields, it's just a question of whether the user is doing it or software.
<manu> Ian: We have an upcoming face-to-face meeting where we've been talking about whether browser vendors want to see if their code bases could use better harmonization. Wonder if Zach and AdrianB might discuss how this could be managed/addressed.
<manu> Ian: So, punting to face-time so we can look at user experiences.
IJ: Can we punt to face time at TPAC to look at user experiences?
<ShaneM> Might be useful to query the interest group
zkoch: I'm ok to punt to pac...also allows additional time for responses on github
zkoch: Is there more evidence than USPS..if so, would be good to highlight that?
(Nick observes ISO 20022 doesn't have careOf)
Nick: I will take an action to work with Kris/Vincent to look at careOf in ISO20022
<scribe> ACTION: Nick to check with Kris/Vincent on support for careOf in ISO20022 [recorded in http://www.w3.org/2016/09/08-wpwg-minutes.html#action01]
<trackbot> 'Nick' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., nshearer, ntelford).
<manu> https://github.com/w3c/webpayments/wiki/FTF-Sep2016
https://github.com/w3c/webpayments/wiki/FTF-Sep2016
<manu> Ian: In the last call, we asked for some people to sign up for some sessions. Just an update. Rouslan and I talked about implementation experience and demos.
<manu> Ian: The goals of that session are now going to be to have implementers ask us questions based on their implementation experience, showing us demos, address issues, etc.
<manu> Ian: For folks doing testing, share some of their observations on the specs. I distinguish that on the test suite. What we've learned through testing that might affect the APIs, I know Mike found some ambiguities / inadequate level of details when writing tests. This is an opportunity to discuss that.
<manu> Ian: The decision on HTTP API, Manu will present something there.
<nicktr> https://w3c.github.io/webpayments/proposals/method-practice/
<manu> Ian: For Payment methods, we could have breakout sessions on day 2 to make progress on payment method specs. Max started a draft, I made some edits to it. Part of the payment methods agenda item. We don't have updates to SEPA, don't yet know if someone wants to sign up to lead a discussion on that.
<manu> Ian: That requires preparation - what question do editor's want feedback from group on. We'll have to meet on day 2 and make progress, unless someone wants to do a SEPA update for the group.
<manu> Ian: We have a draft SEPA Credit Transfer specification that Cyril started to work on.
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
<manu> Ian: Unfortunately, Cyril won't be at TPAC.
<manu> Ian: I started discussion w/ editors and Matt trying to figure out what we need to do to get it updated so we have a fresh draft for the group/get it updated. I haven't heard how we're going to do that. No updates to specification in time for TPAC. For those that are interested in spec, like in London, we can meet and make progress.
<manu> Ian: Capturing inputs/outputs for credit transfer - don't know what we need to do to get that into a FPWD.
<manu> Ian: Credit Transfer is close to push payments, so we have a first step to go through which is to establish some common vocabulary and understanding of what we're talking about, which is Direct Debit and Credit Transfer. Cyril created a UML diagram on credit transfer and some bits on direct debit, just a first draft. Various use cases inside Direct Debit. The point I'm making is that I do think that we need to not be so specific as SEPA. There is a recurring
<manu> impression wrt. what are push payments. I think it would be very useful to define, during TPAC, the common understanding of what we're talking about. Payments for push payments / pull payments should not be specifically European question.
jyr: Maybe we need to group this under "push payment" discussion
<manu> Ian: Maybe we do a break-out session where we talk about push-payments
<Roy> +100
<ShaneM> +1
<ShaneM> (super interested in push payments!)
<jyr> +1
<pirouz> +1
<jyr> +1
<ShaneM> How do we know when we are done?
IJ: Roy will lead the push payment session and start by documenting his idea of goals for the session
<manu> Ian: We may have discussion on recurring payments, etc. led by Andrew Betts in IG
<manu> Ian: Points that we need to get through to get specs to CR, Zach, you're going to do stuff in that slot?
<manu> Zach: Yes
<manu> Ian: You mentioned two other specs that might appear by TPAC - cash on delivery and invoice specs.
<manu> Zach: Yes, I'll see if we can bring some of that stuff up at TPAC. Those are payment method specs.
<manu> NickTR: If there are other things you want to see on the Agenda, put them on there.
15 September