<scribe> Scribe: Ian
NickTR: I look forward to seeing
you all in Japan
... please note that registration has closed
<nicktr> https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation
NickTR: We have a list of things to read:
https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation
<nicktr> ian: Group dinners
<nicktr> ... there are 41 members of the group registered plus observers
<nicktr> ...we may have 50-60 participants
<nicktr> ...we would like to have a dinner together on Monday evening
<nicktr> ian: anyone have preferences?
IJ: I expect to seek a Japanese restaurant
IJ: I think we are one Safari fix
away from implementation report
... There is a proposed privacy enhancement:
https://github.com/w3c/payment-request/pull/873
IJ: What are the opportunities lost by not advancing to Recommendation for another 8 months?
<nicktr> scribenick: nicktr
IJ: I expect we will discuss at the F2F
<Ian> scribenick: Ian
Rouslan: For us, the
Recommendation status is not critical to us; draft spec is good
enough for us to implement.
... once the spec is modified to accommodate the needs of
privacy reviewers, we will implement it in due time. But we
will do so carefully.
nicktr,
nicktr: From merchants I speak with, I think that not going to Rec can be a drag on adoption
IJ: Group motivation is another topic
<Zakim> AdrianHB, you wanted to talk about complexity of parallel work
AdrianHB: Management of versions
in parallel adds complexity and overhead.
... I think if we can continue working and forging ahead on new
features we should do so as simply as possible.
nicktr: What is the impact of delay on rechartering?
Ian: I doubt it
<Zakim> nicktr, you wanted to ask about whether it has a bearing on rechartering?
<nicktr> ij: I don't think it's significant on rechartering
<Zakim> danyao, you wanted to clarify parallel work comment
<scribe> scribenick: Ian
danyao: As we develop Chrome we
focus on backward compatibility, so that should assuage
merchant concern.
... I want to avoid feature creep
<AdrianHB> +1 to avoid feature creep
<nicktr> +1 to avoiding feature creep
Proposed: No other features than the privacy feature will be considered for PR API 1.0
<nicktr> +1
<AdrianHB> +1
<danyao> +1
<rouslan> +1
<AdrianHB> clarifying comment: it is hard work for the group to manage parallel work on the specs if we have a v1.0 spec that is a trying to go to CR and another that is documenting new features
<nicktr> I strongly support this - we need the privacy improving feature to get through the CR milestone but nothing else
Danyao: We are committed to finishing PR API 1.0 features before we start on 1.1 features
<benoit> +1 for PR feature lock
Issue 879: SKUs instead of totals
https://github.com/w3c/payment-request/issues/879
Rouslan: This is a new feature
(so 1.1). We want to have better integration of Web sites with
Google Play.
... we want to expose the Google Play billing capabilities to
Web sites
... merchants enter information in a Google Play database; they
get back SKUs.
... when people want to buy things, merchants provide SKUs and
the payment handler shows the price (that was stored in the
database)
... so a proposal for PR API is to include an alternative where
total/currency is replaced by an SKU.
... the SKUs would be origin-bound.
... so we'd need to add a method to PR API (e.g.,
getDisplayedItems) and would require us to make the total more
complex, like "currency/amount OR SKU"
<Zakim> AdrianHB, you wanted to can we just pass in a Promise as total that must resolve to a valid total object?
AdrianHB: If we wanted to make this slightly more generic...you are I believe getting a total asynchronously. Do you think we could decouple those further, e.g., pass in a promise for a total, and how the promise resolves is distinct from PR API.
Rouslan: We have considered that idea. There might be a server endpoint where the merchant could fetch the amount based on SKUs. However, we feel like it could make the world more complex since people would have to use a second API to translate SKUs.
<nicktr> will take comments to the issue - I think this moves PR away from payment and into a commerce API. It's hard to imagine a payment request that doesn't specify an amount and currency
IJ: I am guessing "list of SKUs" as input
nicktr: I think we need to think carefully about this; currency/amount are fundamentals of a payment. It feels like we might be moving farther away from a "payment request"
https://github.com/w3c/payment-request/wiki#payment-flows
Issue 407: More restrictive hasEnrolledInstrument() for autofill data
https://github.com/w3ctag/design-reviews/issues/407
Rouslan: Chrome is currently the
browser that implements Basic Card using its own autofill
data.
... in this data, Chrome is acting as a payment handler
... in general we don't standardize UX
... but there is one behavior we'd like to introduce that might
alter the expectation about what Basic Card does
... we are not sure if this is a browser-specific optimization
or whether it should be standardized.
... the behavior we'd like to change for Basic Card is, when
you call hasEnrolledInstrument(), it will return false() unless
the card is really ready to pay (e.g., all data is present,
card has not expired, etc.)
... we really want true() to represent a happy path and high
chance of conversion.
scribe: so the request to the
group is whether this behavior should be part of the Basic Card
spec or whether it should be implementation-specific.
... might be good to be in the spec for consistent UX
... but if we put this in the spec, this ties browser hands
<AdrianHB> ian: first reaction, "What's the definition of hasEnrolledInstrument?". Is this payment method specific? I hadn't thought about it that way?
<AdrianHB> ian: you raise questions about variability that is related to how payment handlers behave.
<AdrianHB> ... how explicit would we be in sepcifying this behaviour?
<AdrianHB> ian: If it's in Basic Card how would we define things like "valid billing address"? We have had issues in the past around determining things like card type from BIN
IJ: I would need to see definitions.
Rouslan: I am favor of NOT moving this into Basic Card. :)
<Zakim> danyao, you wanted to comment on hasEnrolledInstrument for basic-card
Danyao: My mental model is that
Basic Card defines a schema.
... I think the minimum expectation is "true()" means the
payment handler can return an instrument to the best of its
ability
<AdrianHB> +1
Danyao: ..what we are fixing in Chrome is that an expired card would not work, so we should allow the payment handler to make the decision.
<benoit> +1
Danyao: the spec should focus on data and allow the payment handler to do what it does best.
AdrianHB: I am agreeing with
Danyao and Rouslan, although I would add to that that if we put
any text in the Basic Card spec, we could do so as informative
text.
... I would take it further to say that it's probably
appropriate for the behavior of a payment handler to be defined
in the payment method spec.
<Zakim> AdrianHB, you wanted to ask if it makes any difference since basic card spec is a note
AdrianHB: I think we should make
clear in the PR API spec that there's no guarantee you'll get
something back even if you requested it.
... If it's possible for a payment handler to return shipping
address or email addresses, then it's impossible for them to
reply to hasEnrolledinstrument() with true unless they have the
data.
Rouslan: This is a behavior we
want to provide for autofill data only
... it would not be relevant for third-party handlers
... so maybe that's the decision-maker: if it's autofill
specific, then it's not part of the spec
"The CanMakePaymentEvent is used to check whether the payment handler is able to respond to a payment request. "
IJ: I would add some verbiage to
tell payment handlers that they should respond true when the
user really is ready to pay.
... and that may be payment method specific and rely on other
circumstances
Danyao: I think Adrian's point is that the mediator should not be overly restrictive. I agree. But payment handlers should have flexibility to be more restrictive.
<AdrianHB> +1 to continue on GitHub. Can we log an issue or should we comment on Rouslan's Gist
Danyao: I am ok with with a non-normative note in PH API that says "ready to pay and may vary by payment method and context."
<nicktr> to danyao's earlier point, the payment method specs should define the data model and behaviour specific to each payment method, so the "right thing" should be defined there
Face-to-face!
<AdrianHB> https://github.com/adrianhopebailie/web-monetization/blob/master/explainer.md
AdrianHB: We did a big update to the explainer.
<AdrianHB> https://github.com/adrianhopebailie/web-monetization/blob/master/sending.md
AdrianHB: there's a nice synergy
between the design and PR API
... we plan to send monetized payments via PH API as-is
<nicktr> that's very exciting
Ian's interview with Stefan Thomas on Monetization
<benoit> very cool
AdrianHB: See you in Japan
<benoit> "coil hype machine" should absolutely be a thing ;)