Nearby: 23 February minutes
<nicktr> scribenick: nicktr
<rbarnes> if people are on the hangout, what's the right way for them to comment?
Ian: presents his requirements doc - this is his initial view, not consensus
<rbarnes> wseltzer, shepazu, zkoch: ^^^
<zkoch> agreed ^
Ian: but we should work through
these. The order is not (yet) significant
... (general assumptions about the user agent)
-> https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016-Requirements
<Zakim> zkoch, you wanted to say it’s …hard
<nick> +1, people don’t understand the difference
zach: users don't understand the difference between native and non-native ui
<wseltzer> [re: UI un-spoofability, see also the IronFrame work in WebAppSec]
ian: the browser folks are not anticipating handing off to third parties in the first draft
<Zakim> padler, you wanted to ask if we want to set a minimum requirement for security
ian: concrete changes are most
welcome
... for example, how this is stored is an implementation
problem
rbarnes: the baseline assumption should be that this information is stored like other sensitive information
jheuer: information needs to be
storable externally
... and we need to be browser independent
adrianba: I wonder if there are requirements buried here
adrianba: rather than assuming things like "there is a trusted UI"
<Zakim> ShaneM, you wanted to request that we keep in mind the testability of our assertions / requirements
shaneM: these requirements are our user acceptance criteria
<ShaneM> To be clear - I think they are the acceptance criteria that we will drive the testing. That and any assertions that are in the spec.
<zkoch> +1 to inaccessible without user consent
adamr: we should be clear that user agent stores information that is inaccessible without consent
adrianhb: the role of the browser
is as an intermediary
... browser vendors may also implement something like a payment
app, but that's not in the spec
ian: let's move onto the next
section
... (general design goals)
... streamlined user experience
... limit API to common ecommerce transactions
... limit API capabilities to be independent of the payment
application
<rbarnes> since when do W3C WGs have an obligation to measure effectiveness? :)
manu: yesterday there was data on cart abandonment - how are we testing for abandonment in this new approach?
<Zakim> manu, you wanted to beat the cart abandonment horse
shepazu: we could write down our
assumptions, then collect data against those assumptions
... that would be good practice
nick: i want to reiterate that
merchant interests are not necessarily the interests of
users
... give merchants the tools to improve retail experience while
empowering users to make smart choices about how they pay
shepazu: there are many reasons to abandon a cart, user experience is only one of them
jheuer: users can make use of trust in (for example) card brands to improve confidence
ian: how is this a design requirement?
<Magda> +1 on Striking balance
brian: we can only have a goal of "keep it simple"
Ian: (general requirements)
... user data exposure must have user consent
<shepazu> (I sometimes "abandon" my cart because I was doing comparison shopping across multiple sites, and shipping and handling charges or shipping times affected my decision to choose one merchant and "abandon" the others, so to reinforce Manu's point, the earlier I know about extra costs the better it is for my shopping experience. I don't know how this fits into API requirements, but it indicates a tension about "decreasing cart abandonment")
Ian asks Wseltzer for a view
Wseltzer: guidance from privacy interest group on long-lived IDs and user tracking - my be a good place to include them in this
Ian: I will work with wseltzer to review this sentence
<Magda> +1 on Privacy IG sync
gregoryE: usually when you
design an API you want a user to use it. we have three parts to
solve for. we have to take into account the merchant
requirement
... there will be a negotiation phase.
<nick> -1 …we very much can state that
gregory: the merchant must be able to request user data
mountie: who has ownership of
the data?
... we have to clarify this
Erik: we believe there should never be an unattended transaction
Ian: who can trigger the API is out of scope
erik: that's going to cause a lot of grief
brian: to clarify - we are
talking about personal data here?
... the EC have a proposal on privacy by design
... including a certification of new apps
<manu1> -
markw: what is the user
consenting to?
... the user is trusting the site to charge the correct amount
- we have to align consents to how is asking
<zkoch> At the end of the day, the user still has some responsibility here to identify evil.com merchants
<zkoch> That said, I agree with Mark’s point fundamentally
jheuer: i want to propose that we include a reference to identity providers
<Erik> +1 to identity provider schema
mountie: consent should relate to where the data is from
Ian: (payment scenarios)
<Zakim> AdrianHB, you wanted to reword 2nd bullet
adrianba: initiation without
final amount is different from "commit" without total
amount
... clarification to call the API
roy: this is relevant for
recurring payments
... you're trying to get a payment credential without knowing
the amount
adrianHB: this is payment instrument specific
<vish> my q: for recurring payments, should there be a requirement for consumers to revoke their permission,and if so how? what happens if consumer no longer has access to device / browser?
adrianHB: "establish a payment relationship via the API"
matts: iso20022 - payment obligation - let's use this
vincent: linked to payment delivery
markw: +1 for recurring, ongoing
payments
... requirement is ambiguous
... does the API just hand over the credentials, or include
details about the commitment
<adrianba> I think "payment agreement" is a good use case but I don't think it satisfies the "For the first version, keep the API to the minimum viable API to address common ecommerce transactions" goal so perhaps we need to revisit that to decide what the scope actually should be
jheuer: are we talking checkout
or payment?
... payment is the final "now I am paying" with final
amount
ian: these are choices that the WG need to make
<AdrianHB> +1 adrianba - but I think we could support something as simple as a transaction type of "authorization" and in future include the details of the obligation in the API request
jheuer: we need to define payment
<Zakim> wseltzer, you wanted to comment on where the requirements fit
wseltzer: these requirements are of very variable level
vish: should there be a
mechanism for a user to revoke a permission? what would that
look like?
... would there be a control panel? what happens if they lose
access to the device/browser
<adrianba> adrianhb, I agree, but that's not minimal viable in my mind and quickly gets into these questions of canceling, terminating, etc.
<adrianba> adrianhb, and I prefer to defer those discussions (my preference)
<AdrianHB> adrianba - those are all out of scope in my mind. +1 to what rbarnes has just said
<wseltzer> s/variable level/variable level: some are "it should be possible to", versus "the API must directly provide"
<AdrianHB> the API is a match-maker
rbarnes: we have to do stuff
<Erik> - To ensure segregation of authentication data and PAN data, the authentication data and the PAN must be transmitted in separate sessions from the consumer’s browser and the merchant to the authenticating vendor.
<Erik> - To ensure privacy of the payment instrument, the transmission of the PAN must be in a separate browser session than the merchant checkout process. The Merchant must not be exposed to the users payment instrument details.
<Erik> - The authentication data shall be secured and processed separately from other sensitive consumer data until it is encrypted in an HSM or other SCD.
<Erik> - The merchant shopping and payment must be in separate browser sessions.
<AdrianHB> rbarnes: the browser API is intended to be the match-maker between payer and payee and their agents
rbarnes: browser is doing matchmaking - but how much of recurring payments is in scope
mountie: payment instrument or payment method?
adrianhb: payment instrument is
the specific (for example) card
... API cares about the method
kris: 1:1 between instrument and method?
adrianhb: no
zkoch: we need to limit the scope
<Zakim> manu, you wanted to note that our scope is starting to expand to an uncomfortable degree.
<vish> +1 to shane on reviewing use cases
manu: this is motherhood and
apple pie
... we have 4 weeks to get a FPWD
... if it's not in the spec, it's not in the FPWD
... the discussion does not need to happen now
<Magda> *ah*
<shepazu> +1 to manu
<Erik> American National Standard for Financial Services - Secure Consumer Authentication for Internet Payments
erik: look at the standard
<wseltzer> Erik: I put 4 requirements above in IRC
adrianhb: what is the requirement
for the API
... I don't think they affect the API directly
<zkoch> +1 to recurring flag
<zkoch> Sorry Mark, didn’t mean to explicitly call out :)
markw: i would still like the very simplest requirement of recurring payments to be in scope
<AdrianHB> +1 for allowing a simple auth flow (no amount) to be possible in v1
<ShaneM> +1 to recurring and authorization flows (via flag)
Ian: (shipping information)
(everyone reads the requirements on the screen) - is anything missing?
(edits made in the wiki page)
<Erik> Secure UI requirements: To enable mutual authentication, an Anti-Phishing solution shall be embedded into the graphical display process and available for consumer use. The Anti-Phishing solution should let the consumer know that the graphical display they are interacting with is a genuine display and not a fraudulent display
<wseltzer> Erik, you might be interested in some of the work in WebAppSec, e.g. Ironframe
jheuer: I'm really worried about the complexity of shipping. The shipping information can come from lots of places.
Ian: we agreed to include it
roy: it must be possible for the merchant to specify a custom display of payment app information
<vish> +1 to roy. also merchants have significant variation in their checkout flows which they want to maintain for many reasons
roy: for example labeling of fields (like postal code)
adrianba: i want to offer a different requirement:
adrianba: the source of user data for shipping is out of scope for the API used to make a payment
<Zakim> Rouslan, you wanted to say i don't see how source of shipping address is part of the spec. API provides payment info and shipping address. we want payment info to come from an app.
vish: there are situations where
you need multiple shipping addresses
... example airline tickets
... going to multiple members of the family
<Zakim> VincentK, you wanted to state that it is mandatory to update the finals price based on shipping address due to tax/VAT reasons (local VAT is applicable in Europe)
vincent: it's mandatory to apply VAT on shipping
<ShaneM> requirements help us know when we are done.
<VincentK> Correction to nick's scribe: It is mandatory to adjust the VAT based on the shipping address in Europe
<zkoch> +1 to PR!
<Magda> +1 to PR
brian: let's keep things as simple as possible
<vish> For those interested in whiskey infused sriracha - https://www.kickstarter.com/projects/657999288/sosu-barrel-aged-sriracha/description
<Magda> *Vish likes it spicy*
rouslan: overall, we should use URLs for payment method ids
<ShaneM> I note that this is not a browser requirement.
<AdrianHB> +1 to Rouslan - I vote for the first bullet
rouslan: I don't think only the controller should be able to specify that URL
<wseltzer> nicktr: glad we're talking about this, because it's hugely complex
<wseltzer> ... there are many different kinds of issuer product
<wseltzer> ... I don't see how you can have fine-grained control, good user experience, with just the short string "visa"
<wseltzer> ... if then I have to decline the blob
<wseltzer> ... I think you have to have one set of identifiers, controlled either by the entity that will process the transaction
<wseltzer> ... processor/acquirer
<wseltzer> ... or wherever the payment app is going to send the info
<vish> +1 for nicktr - these were the points I was going to make
<wseltzer> ... they need to define what they're going to accept
<wseltzer> ... otherwise we're imposing standards on people who aren't in this room
<wseltzer> ... and aren't part of the API
adrianHB
adrianHB: I agree with
nicktr
... here's my thoughts on the architecture
<jheuer> We could parameterize the app and/or the registration with the 'identity' of a particular 'payment product' (or card)
<Rouslan> +1 AdrianHB
adrianHB: people who are going to
accept payments will have to define the payment method
identifiers
... we will create a framework
<jheuer> trademarks can be regional!
<ShaneM> Is there a way the W3C can assist merchants by allowing people who have minted a payment method identifier to advertise them?
<adamR> Visa is a bad example, though: http://www.newsbtc.com/2015/03/03/us-application-bitcoin-trademark-turned/
<jheuer> Overlapping (also using different character sets) will be in the way
<nick> jheuer has a good point
<nick> Visa is two distinct companies, after all
zkoch: it's critical that we deal
with bootstrapping
... we need to make sure users can't get confused
... and i think we should have a repo where we store the method
ids/specs
<ShaneM> T
nick: better example visa
debit/visa credit split
... these identifiers should have relationships with each other
- like nesting
<AdrianHB> -1 for us needing to review new payment methods.
<zkoch> We don’t have to review if new payment methods are just URIs
nick: we don't want to have to update APIs every time a new payment method is launched
<zkoch> We do need to, I think, if they are short strings
<nick> I should credit Stripe for raising that point with me, really, but they’re not here for me to thank them
<AdrianHB> +1 to short strings (they are special)
brian: interchange regulation/PSD2. merchants will be able to choose with some real granularity
vish: i wonder if these identifiers should actually be schema definitions
<Zakim> Rouslan, you wanted to say that nesting can be accomplished by URLs as payment identifiers.
<adamR> nicktr: It’s almost like we need to have top-level identifiers, and then constraints to be applied to them.
rouslan: i like nesting idea
<Laurent_> +1 on nesting through URLs
<wseltzer> nicktr: more on European requirements
<wseltzer> ... users will be able to say not only I want to use this kind of card
<wseltzer> ... but even "I want to be routed on this processor network"
rouslan: we could have different URLS for different combinations
<vish> +1 nicktr. wonder if the reality is that acquirers / gateways will be publishing payment method apps / identifiers
<Zakim> AdrianHB, you wanted to say I don't think nesting is necessary
adrianhb: definitions will be at
the payment acceptor level (example: braintree)
... it's a way of identifying the formats only
... it's not supposed to be tied to our existing concepts of
schemes
... it's simpler than that
... @@@@4563
laurent: braintree is a PSP
<nick> that’s not strictly true
laurent: my payment app doesn't have a relationship with braintree
<zkoch> This seems complicated to implement across platforms
adrianhb: braintree will have
method called braintree and a method called visa, for
example
... this is how proprietary tokenization can be supported
too
<Zakim> ShaneM, you wanted to argue with Adrian
shanem: let's talk about
paypal
... as a merchant I want to be able to do paypal, but not with
amex
<wseltzer> [break for 30 min; return at 11:30 PST]
<Ian> scribe: Ian
(AdrianHB on process of getting to FPWD)
AdrianHB: Plan is this:
* Take the proposal from the WICG
* Fork into a new repo
* Identify people who have the right to merge pull requests
* Everyone in the WG will submit pull requests in the document
scribe: the model is thus that if
you want something to change, you write a proposal
... this includes editors
... editorial fixes (spelling changes, formatting, etc.) will
be done by the editors without additional group
discussion
... outside of editorial fixes, substantive changes will
involve group decisions
... so please note that the role of "editorial" is not about
writing proposals (though editors can) but rather gatekeeping
on requests being merged into final document.
... Adrian and Zach are happy to continue exercising the editor
role.
... anyone else? (Roy raises hand but FB needs to join first,
we recognize)
AdrianHB: I may also propose myself as well.
wseltzer: Group needs to watch contributions from participants in the WG (patent policy)
MattS: I suppose lots of people
doing pull requests.
... I want to understand whether that precludes people from
being able to contribute usefully.
<mountie> what is "pull requests"?
MattS: There is still a place for "issues" when I don't know how to resolve things
<wseltzer> mountie, in github, you can branch the spec and propose a change via pull request
AdrianHB: Use the group repo we already have for the group.
<Roy> With regards to IP and other requirements on joining the working group, I and FB are aware of these and there is already traction to perform these checks.
AdrianHB: If you want to contribute, use the github issues list
<zkoch> Roy, great!
<Zakim> ShaneM, you wanted to have a friendly amendment to Adrian's methodology
ShaneM: Heads-up on "what's editorial" since can be a slippery slope. One idea is to use tags to alert people to pull requests that are substantive.
<nicktr> s/sack ShaneM/ack ShaneM/
<scribe> ACTION: AdrianHB to gather info on good practices for using github for spec editing [recorded in http://www.w3.org/2016/02/24-wpwg-minutes.html#action01]
<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
Erik: Regarding github, make sure we can create branches...I can do pull requests but can't do pull requests from within Bloomberg.
AdrianHB: I will look into that.
adrianba: We should avoid adding substantial things after FPWD
(IJ talks a bit about process and avoids patent policy discussions)
<zkoch> Spec is a bold word...
Manu: Shane raised a good question. I was not under the impression we have adopted the registration spec.
<Erik> Not 100% correct about the patents. Royalty or non-discriminatory license. Its up to the chairs if they will allow a fee based non-discriminatory license.
Manu: I thought we were just
talking about payment request specification
... what are we publishing for FPWD.
IJ: Perhaps we wait for the actual publication decision to determine what goes into FPWD, rather than do so now.
AdrianHB: I believe we have agreed to the "proposal" not just the one spec.
zkoch: We don't have a
registration spec yet. I think the right thing to do is write
spec and take pull requests.
... we start with the basic payment request, and do pull
requests for the remaining things
... I am ok to merge bits over time based on pull requests.
AdrianHB: I propose that we fork the request spec, the card payment spec, and the first explainer document into our WG repo
<adrianba> http://wicg.github.io/paymentrequest/
<Zakim> ShaneM, you wanted to ask if we need to have registration at the end of march? and to point out that spec organization decisions are editorial.
ShaneM: I think we need to focus
on what we are shipping at the end of march. My impression was
that we were going to ship the browser API.
... we can also point to editors' drafts of things that are
coming up.
... spec organizational decisions are editorial.
rbarnes: Yesterday some comments
were made about FPWD demonstrating scope of our
expectations.
... I think that registration will be an important aspect of
the work going forward. I think it's important to have
something.
... I am happy to help get things into shape around
registration to help include it in FPWD set.
adrianba: When I wrote the docs
in the specifications section, the goal of creating the first
three specs was to create a structure to enable us to progress
the browser API spec and the registration spec independently.
And the other pieces are glue.
... the basic card payment spec is intended to be both an
example of how you would write a spec with pieces for a payment
method AND a necessary boot-strapping.
... I don't feel the need to publish basic card specs end of
March
... but I think we need to bring the three other documents in
(whether in one doc or multiple) at FPWD
... So I'd like to see architecture, identifier, and payment
request API into the WG. We can decide in the WG whether to
publish as 1 or more docs at FPWD.
... they form the core of the proposal.
... I think we can leave the explainers behind
... we can decide whether the WG wants to publish a primer or
something to motivate the specs
... I don't mind what happens with that doc...we can point
people to them or do something else.
<ShaneM> Typically that sort of thing is done as a "Note".
adrianba: it's ok for me if we don't publish registration as FPWD at end of March
adrianhb: I think it adds value
to publish basic card spec as well.
... any opposition to doing so?
... My concrete proposal is that we will pull four specs into
WG repo (arch, ids, request, basic card) and NOT the
explainers.
Manu: I am ok with pulling all four in, but I want us to focus on the paymentRequest API.
<Zakim> manu, you wanted to -1 focusing on anything other than the browser API for FPWD. Fine with pulling in whatever other documents. Also, thought we were doing some monolithic thing,
SO RESOLVED to accept AdrianHB's proposal for what to publish at FPWD
<ShaneM> Point that features not in the FPWD that are wildly different restart the patent policy clock. So additional features like registration might best go into a separate document initially. They could be merged up later after the patent period expires. Leave this sort of stuff to Ian / shepazu
<rbarnes> I volunteer to be an editor for this WG
<ShaneM> Yay rbarnes! I am very much in favor of rbarnes assisting as editor.
<nicktr> thank you richard
(Review of issues list)
https://github.com/w3c/webpayments/issues/89
How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgment?
<zkoch> I think #6 would be most effective with a smaller group
Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.
(That's #6)
https://docs.google.com/presentation/d/1ckU7ZJWmKqtbygAgN2BZhx6aT1fYe6DZsS_WntJ8UK4/edit#slide=id.p
<Zakim> manu, you wanted to note things we've covered
(Slide 11 from Manu's presentation)
* More explicit indication of information requested and sent
* Ability to dynamically request more information mid-flow
(Question about whether to discuss questions in a small group v. larger group)
MattS: How does flow work contribute to FPWD?
AdrianHB: It may not have a
material impact on FPWD, but should have a material impact on
the final product
... it's work that we should do.
IJ: +1 to continuing to gather requirements (from flows) even if they do not influence FPWD
AdrianHB: But they might, if they are critical.
<Zakim> manu, you wanted to note that we may want to publish a ED at the same time as FPWD of how API maps to flows.
Manu: There is a CG spec that
shows mapping between spec and flows...we could port that
in.
... we can make that an Editor's draft to do in parallel with
the FPWD
<Zakim> ShaneM, you wanted to ask about making a decision on publication strategy
ShaneM: +1 to showing how spec supports flows as Manu describes. Also good for testing.
Magda: I'd like to discuss dissemination at FPWD this afternoon.
Manu: The CG Proposal supported different amounts depending on things like choice of payment instrument and currency.
Rouslan: I'm ok with multiple
pricing options in the spec, but not sure whether it should be
in V1.
... to help determine that I would like to hear from some
merchants.
zkoch: My original thinking
around this was "simplicity wins" which is why the original
version did not include this.
... that said, I think this has evolved and we have had
conversations with merchants.
... a topic that has come up multiple times is that there are,
for example, use cases for "reduced prices based on loyalty
cards"
... I am concerned that if we don't support this we might limit
adoption
... I am coming around to the notion that it is worth
supporting price variability.
... but I want simple cases to remain simple.
... So I am +1 to supporting this use case in FPWD (based on my
discussions with merchants)...if it's simple enough.
Vish: The example you raised on
pricing is interesting. But it's a pandora's box a bit.
... there are also pricing changes directed at the merchant
(e.g., costs less to merchant if a particular card is
used)
... some nuance there might be interesting to think about
<Zakim> ShaneM, you wanted to stress that additional options in the payment request will help the case for future smart wallets
ShaneM: Having additional options helps the future case.
adrianHB: The design constraint
is "once the payment request has reached the app there is no
turning back"
... we need to think about scaling...what happens if, as we
were saying, a company supports 100 or so payment
methods?
... don't want to have to repeat the same price over and over
again
<zkoch> Intelligent Design (tm)
Do the Right Thing (tm)
<AdrianHB> FYI: this is discussed in this issue: https://github.com/w3c/webpayments/issues/79
<Zakim> manu, you wanted to say the JSON blob doesn't grow like that.
manu: In the average case where the merchants takes 70 types of payment, there's one price entry. Where they take 3 different currencies and 70 payment instruments, so does not grow exponentially.
<Zakim> manu, you wanted to suggest a way forward.
<mountie> +1 for different pricing even by considering DCC (Dynamic Currency Conversion) of credit card.
<ShaneM> Oh please no
Vish: The whole notion of
incorporating price into app selection seems unusual.
... it forces a lot of logic on the merchant side before
checkout
... they have to take into account the effect of shipping,
loyalty, etc....nuances that may be hard to pass into a
third-party object
... we've tried this with Visa and not succeed, so where we
ended up was "let the merchant deal with nuance" and if the
consumer wants to go back and choose a different payment
method, they can do so.
... it feels a little dogmatic
... merchants may not be able to provide price without more
data gathered early on
AdrianHB: We are trying to decide
whether this is a feature we want without knowing the knock-on
effects
... I would not invest a ton of time in multiple pricing until
we get feedback this is valuable
nicktr: Regarding merchant ordering: strong +1
<mountie> +100 for allowing merchant to influence order
nicktr: here's a real example. I am aware of many processors who have financial incentives to present the payment methods on a page in a particular order.
<zkoch> q+
Roy: I wanted to second Nick's
point
... there are many scenarios at FB where we want to determine
the order of payment methods
... one example is the impact on our side....e.g., motivation
to use something like credit card v. direct debit
... there are also financial implications (fees)
<Zakim> manu, you wanted to note about merchant-provided payment apps. and to note conformance criteria on the spec - the order in the JavaScript array is the order of display.
manu: I want to talk about
merchant provided payment apps...what if the merchant wants you
to use their payment app .
... here are a couple of ways we could put conformance in the
spec:
* The user agent must respect the order of payment methods as defined by the merchant
scribe: back to the merchant-provided payment app, that questions a big question mark around the API
(Here's the draft list of "requirements" on this so far in the reqs doc:)
===
It must be possible for the merchant to specify a custom display of payment app information.
It must be possible for the merchant to provide labels for user information procured via the API.
It must be possible for the merchant to specify a preferred order when displaying payment apps.
It must be possible for the user to specify a preferred order when displaying payment apps.
===
AdrianHB: Another idea is this:
* The API must allow the merchant to determine whether the user has registered an app associated with the origin of the merchant .
<wseltzer> [privacy considerations: can the user disable that checking?]
<ShaneM> wseltzer: It feels like there should be a grant at that point.
<ShaneM> wseltzer: as in "This site wants to check if you have their payment app installed. Allow / Deny"
nick: I am not opposed to allowing merchants to express preferences...but it should be expected that user agents will not take that as a guarantee, but the information will be used in combination with user preferences.
<Rouslan> +1 nick
<ShaneM> User preferences must always win.
<nicktr> all we can do is specify what can be carried on the api
<Zakim> ShaneM, you wanted to stress that I don't see how the flow allows for the merchant to provide an order and then have that order override the order presented by the payment app if
<Erik> The browser distinguishes between the interests of the user and the site, but didn't anticipate that there could be other interests represented (such as the merchant, payment processor, etc)
<zkoch> Food is here!
ShaneM: FYI, we are working on
accessibility doc for payments, and those will include user
preferences that have to win.
... also, the payment application provider may have a preferred
order that could be user-informed or "smart"
... if the payment app is presenting choice, that could
potentially override what the merchant is requesting.
vish: Merchants also have
incentives to place payment methods in a particular
place.
... so there is a tension between merchants who have
contractual obligations and user choice, and certain Api
choices may have an impact on adoption.
<zkoch> I think we do have to accept generally that *part* of the status quo around payments/merchants/checkout etc is going to have to be…to use a tech bubble word…disrupted by this
<nicktr> +1
AdrianHB: I am hearing that we should support merchants specifying a preference, and allowing users to express a preference that overrides merchant preferences
markw_: As a merchant I'd like to know what the order was that was actually displayed.
<nick> some privacy implications there
(Yes)
<markw_> yes, privacy impact needs to be thought through, but inability to either determine or influence-and then-detect the ordering would affect whether merchants will use the API
<markw_> it may not be necessary to disclose which payment methods were available, just to return an ordering of the methods that the merchant passed in
<shepazu> markw, vish https://www.w3.org/Payments/IG/wiki/Subscription_Management
<wseltzer> [resumed]
MattS: Quick word on mapping
flows to the spec.
... if we break out, I suggest we talk about next steps for
flows task force
<Zakim> m4nu, you wanted to note new use cases and potential flows.
m4nu: Two flows to consider:
* Pre-auth
* Multi-tender
scribe: pre-auth use cases include hotel reservations, gas purchases
MattS: We have some flows that support those (e.g., legacy card supports pre-auth)
m4nu: My point is that the API design doesn't solve that.
nicktr: From a user perspective a pre-auth just looks like a payment.
AdrianHB: Tied to question of whether one can provide a label for the button, like "pay" v. "reserve"
<Zakim> ShaneM, you wanted to ask if zkoch thinks it is supported?
<mountie> pre-auth with zero amount
adrianhb: We don't yet know the priority of the pre-auth use case
<Zakim> m4nu, you wanted to note that there may be higher priority items.
MattS: I'm going to go out of the room to investigate the use case
<zkoch> I do think this point is largely lost on users to begin with
<zkoch> I personally never know if I am being pre-authed or charged
<zkoch> So my initial inkling is that from a UI perspective, nothing should really change
m4nu: I think we should discuss
the "general shape of the API"...
... one approach is you have a an object that you send to the
API
... another is you send a thing and gather information through
events
AdrianHB: I propose we not discuss now and discuss in a smaller group
[Multi-tender]
adrianhb: What are the multi-tender requirements?
<mountie> what is "multi-tender"?
adrianhb: e.,g the ability to pay a proportion with a one payment instrument, and a portion with another.
m4nu: This is a big thing for
convenience stores and small shops.
... people pay with things like food stamps...these are two
distinct payment instruments
jheuer: Are there online examples of this?
adrianHB: I have a way to split payments between points and payment instrument.
Shanem: Amazon supports this - you can pay with amex points and another part that's not amex
rbarnes: You can emulate this
with a single tender interface.
... you could serialize payments
... to pay part with one instrument then go through the flow
again
<GregoryE> Ian: cheques vacances in France, #1 payment instrument for railways
rbarnes: there may still be requirements on a single tender API like "submitting a request"
adrianhb: Yes, your payment response would need to specify an amount
Magda: I move we mark as an issue and move on.
<Zakim> ShaneM, you wanted to mention that does not work 'cause you cannot fail out
ShaneM: Serializing payments doesn't work since you can't unroll...not part of an atomic transaction anymore.
Vish: Most small merchants don't offer split payments due to complexity
M4nu: I think that it depends on type of merchant
<Zakim> m4nu, you wanted to note that "klunky solves" could still paint us into a corner.
<adamR> The Internet never ceases to amaze me. Someone has actually done this: http://www.easysplitpay.com/
<zkoch> Haha, interesting. Step 1: Buy a gift card.
<rbarnes> adamR: that reminds me, i bought a lamp on CB2.com the other day and they offered to split (e.g., for roommates buying furniture)
<wseltzer> https://github.com/WICG/paymentrequest/issues/30
adrianhb: there is a pci implication
adrianba: When we added this
issue to the spec initially, the concern was that we wanted to
be clear to the user who is making a request for payment.
... the concern was that a script from an app network might
trigger a payment request, but that script is not controlled by
the site you are growing.
... so by tying to top-level browser context would mitigate the
issue.
... but other people have raised the issue that it's common for
people to use an iframe to host something from their PSP so
they don't have to interact with the payment information
directly.
... and it's a good way of scripting it so they can be told
"you've been paid" and nothing else.
... So one proposal is that it not be top-level requirement but
that you are giving permission to a particular iframe
permission to do a payment on your behalf.
<zkoch> Our proposal was to use the iFrame sandbox attribute
<zkoch> <iframe sandbox=payment”>
rbarnes: I am unenthusiastic about exposing this API to iframes (due to experiences with certificate authorities)
<Zakim> wseltzer, you wanted to recommend TAG/WebAppSec review
wseltzer: Since this would be a "feature with significant security consequences" I think TAG and/or WebAppSec review would be helpful - is there a way to make it secure and comprehensible to the user.
adrianhb: For PCI compliance, you
outsource processing to the PSP. Today done through redirects
or iframe
... I think there is a strong use case for it.
... I think an alternative solution is something like a
header-based solution where the top-level context specifies
domains that are permitted to make payment requests.
... WebAppSec doing something like that.
<Magda> -1 for allowing iframe access
nicktr: Here's acquirer perspective - iframe are used all over the place....the idea of iframe being able to open mediator gives me the creeps.
adrianhb: So the question is what
other option is there?
... Merchants need a way (for card payments) to not see the
PAN.
<Zakim> nicktr, you wanted to respond to m4nu
adrianhb: The API response from
the payment app potentially includes a PAN in the clear. The
merchant needs to be able to forward to the PSP without seeing
the PAN.
... one other idea has been for the payment app to send the
information through another mechanism (e.g., HTTP)
rbarnes: It may be that we want to punt this to the payment app
adrianhb: PROPOSED: Top Level
Context only
... and punt to payment app
<rbarnes> -------------- <> |_|
zkoch: There are use cases
outside of PSPs that are compelling such as games (e.g.,
Facebook games).
... e.g., a game maker like Zynga has a use case
... I'd like to reach out to some of these orgs to see if there
are ways to address this
... I am not so ready to say "issue resolved"
rbarnes: How about "provisionally resolved" ... only top-level and then later we can re-open....
ian: What about spec saying "Top-level only but we want feedback"
zkoch: +1
rbarnes: +1
<ShaneM> I think the merchant should have a way to signal that they payment complete message payload should go to some *URI* and the resolution of the promise is "payment completed; transaction ID x" or something
<rbarnes> no better way to get feedback than to say something controversial
<Magda> *heh*
<ShaneM> rbarnes: and say it up top
m4nu: +1 to punting and asking for feedback. We could even list a few ideas we are tossing around for concrete feedback
<Zakim> m4nu, you wanted to note CORS-like HTTP header solution.
adrianba: please submit a pull request for what the spec should say
(Issue 19)
<wseltzer> https://github.com/WICG/paymentrequest/issues/19
adrianba: Today the spec requires
you to provide a single amount in a specified currency.
... there's a general question about what happens if the
payment instrument that you have is billed in a different
currency.
adrianhb: This feels like "should
we allow different amounts per payment method" ; sounds like an
extension of that
... do we want to specify a different number of amounts per
currency
roy: In Brazil you can't process a credit card in non BRL
zkoch: So is the implication that
single currency is ok?
... or is your point that we should support multi-currency?
roy: If your site only supports USD but you want customers in Brazil, you need to support conversion to BRL
zkoch: How does this work
today?
... are they blocked, or does somebody play a role to help?
nicktr: The scheme, or DCC
... The other interesting use case for me is bitcoin
specifically.
... if you price in USD and you say you accept bitcoin, the
price will need to be expressed in bitcoin on the way back
adrianHB: Who picks the conversion rate?
nicktr: Yes, that's part of it but not only that.
<Magda> *why do I feel like some folks here are secretly running money laundering schemes?*
nicktr: is it valid to send back an amount in another currency?
<zkoch> m4nu: We accepted a proposal for multi currency? Or price per payment method?
<m4nu> both
<m4nu> we didn't accept a proposal
<m4nu> we can do multi currency and price per payment method w/ the same CG spec proposal.
mountie: Use case - let user select home currency
<m4nu> and we said we'd try a PR for it... I feel like this is a "solved" problem, unless I'm missing something.
mountie: let the merchant provide a list of currencies and amounts for the items and allow the user to select on the web site
<Zakim> zkoch, you wanted to discuss simplicity
zkoch: the status quo in the ecosystem....it sort of works today
adrianhb: There is a revenue opportunity for PSPs ...exchange happens without knowing the detail, but you pay a premium.
<nick> I am very wary of this. Some merchants today do a lot of dark patterns to do this conversion
markw: Depends on whether conversion happens on the user site or the merchant side
<nick> (which zach is just saying)
<adamR> protip: ALWAYS CHOOSE THE LOCAL CURRENCY
<nick> sssh, you’ll let the secret out!
zkoch: I think we should look at the CG proposal
<Vish> There are also regulatory considerations in some geographies
<zkoch> TIL always choose the local currency
kris: By including the feature in
the API would you be offering a service that is currently later
in the chain?
... are you saying that including this at the API level is
going to short-cut FX service that happens later?
<Vish> +1 on choosing local currency - networks buy currency in the billions and usually have some of the better rates
<Vish> Some merchants use FX houses and capture that FX spread revenue - not just gateways
adrianhb: We are trying to understand whether the API still supports the DCC use case, or whether we don't need to support it because merchants and PSPs will still support it.
<ShaneM> +1 to enabling currency selection
adrianhb: the merchant shows the
price before knowing how you are going to pay
... there are two ways to do this...one is friendlier since the
API could take the multiple prices up front, v. the API always
asking you to pay in a particular currency then updating after
the fact.
<nicktr> this is precisely the use case which prompted me to suggest a chattier multi-message api way back when
IJ: Can you get a response with a different price/currency than the request?
pttpa
IJ: Can you punt to the payment app? And allow the response to include the final amount and currency?
adrianhb: that would remove the service from the PSP
<Zakim> Ian, you wanted to make a proposal
<Zakim> m4nu, you wanted to note that I thought we just accepted a proposal for pricing in multiple currencies. Currency conversation is done in the payment app.
<mountie> allowing the response to include amount and currency user selected
<zkoch> I wasn’t aware it was multi-currency I guess
m4nu: I think we resolved previously this:
<zkoch> But still interested in seeing the PR
* It should be possible to specify prices that vary based on payment method and potentially currency
<zkoch> I’m very concerned about the anti user pattern, though, so I’m very timid about supporting such a pattern
Magda: I am ok with this going in as long as it doesn't derail FPWD in terms of complexity or time
(IJ agrees with manu's conclusion)
CyrilV: ISO20022 deals with
this
... there are not "multi currencies" there are "multiple
offers"
<zkoch> This is also getting much more complex from a UI perspective
<AdrianHB> cyril: ISO20022 calls these "offers"
(I think that "one offer with multiple tenders/currencies" is the same as "N offers with one each")
adrianhb: We should look at the ISO20022 data model
M4nu: This is the same topic as multi price/currency
mountie: Multiple currency
choices may have to be time-limited
... offers are time-sensitive
<wseltzer> https://github.com/WICG/paymentrequest/issues/16
adrianba: It's frequently the
case that during checkout, sites ask for more information about
either the person paying or the person who is going to receive
the shipment
... for example, you might ask for the email address so that
you can send them a receipt
... you might ask for the telephone number of the recipient
regarding shipping
... since shippers often require that phone number
... the open question is whether we need to support providing
that information as part of the payment request.
... we started from the point of view that we should minimize
the amount of information that the browser shares (that it
knows about you)
... and so we should not automatically send back all of this
information, and if we provide a mechanism for requesting email
address, that that should be explicit so it can be highlighted
in the user experience and consent sought.
... if we decide that the API should support it, then we have
to specify it
m4nu: -1 for expanding the scope
of the API for collecting things like phone number and proof of
age collection.
... this is a topic around verifiable claims
... my concern is that the checkout API will grow and become a
data collection mechanism.
<Zakim> m4nu, you wanted to note verifiable claims work and browser may get data from there. -1 to expanding scope of payment request to email, proof of age, etc.
<ShaneM> +1 to limiting the scope of the api and data gathering
<kriske> +1 on manu's concern
zkoch: Here's where I think you need to draw the line - what is necessary to get information from point A to point B.
<Magda> +1 to limiting data
zkoch: I think what's required is
address, phone number, and email address is typically required
to send receipt.
... I think email is more optional, but phone is almost always
required for shipping.
... my line of thinking was to add phone number...I think it's
also part of the shipping information discussion we
started
... I'm inclined to include email and phone number
rbarnes: I don't have strong
thoughts on particular fields. I think it will evolve over
time.
... we should be use-case driven and settle on something that
we think will address a big slice of use cases and deal with
other requirements later
<ShaneM> zkoch mentioned xAL. Oasis standard for postaladdress etc. Here is an instance: http://shane.spec-ops.io/xAL/xAL.html
jheuer: -1 to adding more
... in Europe I have the option of specifying billing
address
... I think it's something that will "never end"
<burdges> -1 to any user information being mandatory, this depends upon the payment method. I suppose we're not talking about it being mandatory anyways though.
nicktr: Good debate. I don't want
to punt this one. I want to put a marker down on this
one.
... I would like to propose that we not extend beyond payment
information and shipping address.
<ShaneM> Yes - billing address is essential for some merchants when they talk to their PSP.
(Billing address is typically part of payment instrument registration I think)
<Zakim> nicktr, you wanted to propose that we do not extend the data collected
nicktr: Look at the worldpay DTD...thousands of lines long
<ShaneM> +1 to not expanding at this time
<zkoch> I’m fine with making this decision for the FPWD
zkoch: If you go to best buy you can't check out without a phone number
jeff: These fields should be optional.
<nicktr> for those who might be interested:
<nicktr> http://dtd.worldpay.com/v1/
zkoch: I want to ensure we are giving merchants enough incentives
Erik: In some of these cases, the decisions should be made outside this group. You can kick some of these back to the IG
<Laurent_> +1 to billing address being the scope of the payment method not part of the registered info
adrianhb: I am undecided on
this.
... I see the value. I don't agree with the value that adding 2
fields adds complexity.
<mountie> at https://www.ietf.org/rfc/rfc3106 (ECML of IETF) touching "ship to", "bill to", "receipt to"
<zkoch> The merchant needs to send a receipt somewhere, right? So it feels like we need email address
adrianHB: I think we should distinguish verifiable claims from data capture.
<kriske> +1
adrianHB: there's no assumption
here that the data be "verifiable" ; this is user
provided.
... that is specific to the merchant.
<Magda> * approx T-40min to turning to pumpkin time*
<zkoch> Not sure how IP routing works. But if you already have a system from the merchant for sending email receipts, and that’s what users expect, can we expect things to change?
IJ: We can change the issue to say "do we need email and phone number for recipient" and get merchant feedback on the spec?
<ShaneM> Note that 99% of the time you are still going to have to ask for billing address.
<zkoch> Is there an existing standard for addressing pigeons?
<Zakim> m4nu, you wanted to issue marker, move on
Ian: Proposed - modify issue marker to say "Is email and phone important to you?"
<nicktr> +1 to proposal
<mountie> +1 including name.
(On soliciting feedback from merchants...how do we get their reply....can they use mailing list? What if they don't want to speak on the public record?)
<zkoch> +1 to Ian
Proposed - modify issue marker to say "Is email and recipient phone important to you?"
<zkoch> Amazing!
SO RESOLVED
<wseltzer> https://github.com/WICG/paymentrequest/issues/32
adrianba: E.g., a message like
"Currently computing shipping"
... Cons are "complex" or internationalization issues
... But useful messages are like "checking inventory"
magda: You can check inventory
out of band.
... I see value in being able to message the user, but am
nervous if too open-ended
m4nu: there is a chatty protocol
that the CG API was using that would enable sending of status
messages
... I don't mind having something in the spec to experiment
with
... something like paymentrequest.updateUserMessage
... proposal is to do that in the spec and ask for feedback
adrianhb: +1 to that proposal...with an expansion
<wseltzer> [there could be security reasons to limit the messaging options]
SO RESOLVED: Include user message feature in spec and ask for feedback.
adrianhb: I have a question about complete() function....do we need more granularity than boolean...or do we need message support as well?
<adrianba> proposal to change complete from a bool
adrianhb: is there a requirement to provide a message (e.g., failure message)?
nick: I spoke with adrianba and
zkoch about this and support it
... I then thought of some scenarios where you need another
state than true/false
adrianhb: I still think we want
to indicate success/failure
... I don't want to go done road of response codes
adrianba: My proposal is
something slightly different - to take Ian's approach of
punting it to the payment app
... with a caveat.
... I think that the possible states that you might call
complete() with might depend on the payment method.
... there might be some payment methods where you are expected
to be definitive about whether it worked or not
... I think it would be fine to create such a payment
method.
... there may be a payment method where you always "never know"
... where you've finished processing for now but you are not
saying that payment has happened (yet).
... time required to finish payment is outside API
... so I think there is a dependency on the payment method.
.... I am proposing that we use a string, therefore,
... and that we decide what the success/failures strings look
like
... but that we not decide what the other strings look
like.
jheuer: What about returning receipt?
adrianhb: I hear you saying "instead of a string you could get back an object that represents something like a receipt"
<Zakim> wseltzer, you wanted to discuss time-check
nicktr: To make 29 March we need a call for consensus around 17 March
(allowing a week for comments)
<ShaneM> I note that we need a shortname.
IJ: I suggest that on 10 March we check in on progress and reset timing expectations accordingly.
<ShaneM> CFC requirement at https://www.w3.org/Payments/WG/charter-201510.html#decisions
m4nu: We have a ton of issues in
the repo that need to be moved into the other repo; heads up to
the editors
... I feel like we will be mostly adding issue markers and that
will be the fPWD
<Zakim> m4nu, you wanted to note that we still need to do a bunch of PRs for issues in WG issue tracker. and to add issue markers, that is - not resolve the issues
adrianba: I would be fine with a
FPWD that is essentially what we have with more issue
markers
... I aspire to do better than that but we'll see
<zkoch> +1 to aspiring
adrianba: I think our highest
priority coming out of this meeting should be to do the admin
work to move the work of moving specs and issues
... to the new repo
... that's my highest priority...I hope we can do that this
week into next week
... because of that I would like to ask for a few days for us
to get that done before people start making pull requests.
<nicktr> q
PROPOSED: NO more pull requests until moved to new repo
ACTION: AdrianBA to move the materials to the new repo
<Zakim> ShaneM, you wanted to offer to assist with ReSpec / pubs issues - EMPHATICALLY NOT AN EDITOR.
magda: Who are our editors
nicktr:
* Adrian Bateman
* Zach Koch
* Roy (PENDING)
* Richard Barnes
Shane: I can help with respec
Magda: Thanks
<Zakim> m4nu, you wanted to discuss PR
m4nu: I am suggesting no big
media outreach around this publication
... we should not broadly ask for merchant input
<Zakim> AdrianHB, you wanted to note unique stakeholder group
IJ: I would like us to hear from developers and merchants; not sure we need a press release but want to take IG suggestion back to marcomm
adrianHB: developer outreach is
different from big press outreach
... we could throw early versions of spec to developers, but we
need to provide quite a good context if we are giving it to
less traditional w3c audiences
Magda: I would like to ask for
security IG review of FPWD
...
... and to use our existing merchant participants for
feedback
padler: For the developer community +1 to getting feedback
<Zakim> padler, you wanted to comment on credibility concerns
padler: living in the financial
industry that if we don't go forward with a solid announcement
we risk credibility issues
... so I favor getting feedback closer to w3c before broad
feedback
<Zakim> Ian, you wanted to talk about other outreach
Ian: What about ETA or other associations?
<jheuer> +1 to padler's concerns
padler: I am concerned that it needs to be more mature
<jheuer> +1 to padler's concerns
IJ: I will take back to w3c marcomm the view that the IG does not think that FPWD is the right time for broad promotion.
ADJOURNED
3 March teleconference
nicktr: On the agenda will be whether we should hold a summer meeting