<scribe> Scribe: Ian
NickTR: Context: pre WG there was
a lot of discussion about coupons and vouchers
... when we launch WPWG we decided discount codes would be out
of scope
(In addition, we said so in the charter. We updated our new charter to include discount codes.)
NickTR: But we are hearing that
discount codes are an important utility.
... but I think it's a big change at this time as we seek to
get to Rec
https://github.com/w3c/payment-request/issues/145
<Rick> q
NickTR: Would be good to hear opinions
Rick: First question - is the
final amount sent by the merchant in the PR API?
... depending on where the credentials come from, they might
need to know what the FINAL amount is, not the amount after the
discount code
... might have an impact on the authorization
... you can either (1) have the merchant get details before the
API or (2) let the merchant understand that this is the
subtotal and if the final is different, could impact auth
... imo, probably up to merchant to get the code before the
API
<nicktr> ian: let me frame this
<nicktr> ...first of all we didn't jump into this is that they're not reusable across transactions unless addresses, for example
<nicktr> ...today, merchants collect before the transaction
<nicktr> ...so the question is whether we can facilitate an easier experience with our existing event model
<nicktr> ...ie total gets updated just like when addresses are updated
https://github.com/w3c/payment-request/issues/145#issuecomment-387305939
<nicktr> ...marcos did some modelling (as link above)
Krystosterone: We can chime in on
experience presenting discount code prior to PR API
... main reason for abandonment is that it's preferred to show
discount codes at the end of the checkout experience.
... having the discount code in the sheet we think will reduce
chances people go off to look for the code and instead pay
right away
nickTR: My sense is that this is a feature that is "desirable" .... we want to understand if it's critical, and whether it should affect our getting-to-rec timeline
stpeter: How do shoppers use
these? I understand your comment about late binding
... how do users behave...do they go off to look for codes?
krystosterone: If you put
discount code field at the front, people leave to find the
codes
... but at the end of the UX, the research shows that users are
less inclined to go off because they are already comfortable
with a price for which they have given credentials
stpeter: If the shopper goes off they might wander off.
krystosterone: That's our concern, yes.
<Rick> q
stpeter: The broader question -
what does experimentation show?
... outside of shopify, have others done experiments?
... if merchants need this and say no, we're "dead in the
water"
<nicktr> ian: we should keep asking for data points to confirm level of dropout
rick: It's one thing to capture the code information on the sheet; another thing to validate it
(Ian thinks this connects to retry)
NickTR: Rick's comment touches on
the "chatty api" topic
... this gets particularly interesting where vouchers and
discount codes cross over into other payment methods
... you could solve for this (in theory) by treating each
voucher as a payment method; but we'd need to support split
payments
... what if this involves re-engineering the API and event
model
... is it better to publish early with fewer features or wait?
In the spirit of agile, I would personally prefer continuing
forward with what we have, then turn to this feature in 1.1
rickw: Does this apply to gift
cards?
... are they treated distinctly?
nicktr: Gift cards are handled as
cards (basic card)
... those can be treated as a payment method
... it's where you get the merchant of payment method + coupon
that it's more complex
stpeter: I agree with NickTr;
let's ship and iterate
... suggest shipping to get adoption rather than wait
longer
<nicktr> ian: i would not put up a mission accomplished banner yet but there are signals for optimism
<nicktr> ...and lots of implementers
<nicktr> ...I think it's valuable to have this feedback
<nicktr> ...which are indicators that we're not yet done
<nicktr> ...there seem to be opportunities to improve privacy and security too
<nicktr> ...there is a fatigue risk but we have the most members of any w3c working group currently
stpeter: We will be more actively
reaching out to merchants
... we need to think carefully about what to include at this
point
NickTR: My sense is that although this is an important feature, I am not hearing consensus that we should stop the current direction,
but we should (1) experiment and (2) come back to it
scribe: let's experiment informed by dialog with merchants
krystosterone: I agree with
that.
... I am more optimistic. :)
... PR API is speeding up time to completion
... +1 to continuing this path and iterating
<nicktr> ian: this is mostly an FYI
<nicktr> ...we had a good F2F in Singapore
<nicktr> ...Mastercard did some work on a crypto spec
https://w3c.github.io/webpayments-methods-tokenization/index.html
<scribe> New encryption spec:
https://rawgit.com/w3c/webpayments-crypto/gh-pages/index.html
<nicktr> ...the tokenised spec has sensitive and non-sensitive data and advocates an approach for an encryption spec which can be re-userd
<nicktr> ...there is already a pull request from AHB
<nicktr> ...I ahve an action to update the spec with the wiki spec
Tokenization algos:
https://w3c.github.io/webpayments-methods-tokenization/index.html#interfacing
<nicktr> ian: we have some new text to bridge the family of specifications
<nicktr> ...I have taken a stab at elaborating those algorithms in anticipation of implementing this
<Rick> q
<nicktr> ian: I wanted to raise awareness and our next meeting is 12th June
https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenusagetype-enum
<nicktr> ian: we documented 3 uses for tokens
<nicktr> ...so the question is what does the merchant say to get back the right token
<nicktr> ...part of the answer is that we anticipate Card of File use case and we broached a more advanced version where merchant can express preferences (one-time, CoF etc)
<nicktr> ...however we have not explored that yet
<nicktr> ian: the second topic is what can people do with the data that they get via PR
<nicktr> rick: so I'm hearing this is not all defined yet
NickTR: Any updates from the editors?
Roy: None from me
<nicktr> ian: other FYIs
https://www.infoq.com/news/2018/05/firefox-web-authentication-api
<nicktr> ian: I want to draw attention to firefox implementation of web authN
https://caniuse.com/#feat=webauthn
<nicktr> ...peter - is this behind a flag?
<nicktr> ...web authn is in edge, FF and Chrome and in technology preview of safari
scribe: under consideration in webkit
NickTR: AOB?
14 June
NickTR: Regrets