Web Payments WG

<scribe> Scribe: Ian

Discount codes

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

Tokenization and encryption

<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

Any PR API editor updates?

NickTR: Any updates from the editors?

Roy: None from me

<nicktr> ian: other FYIs

Random

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?

Next meeting

14 June

NickTR: Regrets