<scribe> scribe: Ian
/www.w3.org/2015/11/wpwg.ics///www.w3.org/2015/11/wpwg.ics
marcosc: Two big changes
a) Payment Method Change
scribe: pull request 695
<marcosc> https://github.com/w3c/payment-request/pull/695
scribe: this one is to help Apple
Pay support store cards
... Apple supports private label cards
... my understanding is that if you use, say, a Target
card
... the event gives the merchant card information (e.g., in
tokenized form)
... the merchant then can use this information to modify the
total and apply loyalty points
IJ: What is the status of spec and of implementations?
Marcosc: Supported by Apple
already...
... not sure if their support is this API's or their specific
one; but this should be layerable on what Apple has
... still chasing them down
IJ: Any other implementations?
Marcosc: I will implement in
Gecko (but won't do anything for the moment)
... not sure yet about Google, Edge, Samsung
... would be good to ask them, too.
<scribe> ACTION: Ian to ping various vendors about implementation status / expectation around pull request 695
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
b) Retry
marcosc: If you get to the end of
a payment request flow and the user hits "Pay" but there's a
bug in the data, a credit card is expired, etc., or for other
reasons the merchant can call retry()
... before closing the sheet
... that might include selecting a different instrument or
changing payment handlers entirely
... this change implied changes to the state machine
... it was less bad than I thought, but it required quite a few
pull requests
... it's implementable (I have a local implementation that
works nicely)
IJ: And others?
Marcosc: We agreed during singapore to support this, but until people can see the whole coherent proposal in place ..... I meet with Zach today
<Zakim> Ian, you wanted to ask about instrument limitations
IJ: Is it possible change modifiers upon retry?
Marcosc: Yes
... it puts payment request back into "interactive"
... so you can take away modifiers
IJ: I didn't expect instrument level filtering, but did think that error messages could be useful
Marcosc: The merchant provides an
object that has the errors (as smaller objections)
... those errors get mapped to input fields
... in the payment sheet
IJ: Is there anything that should be passed to the payment handler?
Marcosc: Not sure
... maybe you get a new event.
... or could a more specific event.
<marcosc> PaymentResponse.prototype.onpayerdetailchange
Marcosc: We have some specific fine-grain "on change" events....want feedback on whether we should have more fine-grain events or this broader grain approach
<marcosc> Name, email, and phone
<marcosc> i.e. response.payerName
Marcosc: when there is a change, the event fires and you can query value from the response.
IJ: Who do you need feedback from?
Marcosc: From merchants
potentially?
... this is all party of retry.
<marcosc> https://github.com/w3c/payment-request/issues/705
<marcosc> "onpayerdetailschange event handler"
<scribe> ACTION: Wanli to check internally to see if there is a preference for fine-grain event handling or whether onpayerdetailchange suffices
<trackbot> Created ACTION-97 - Check internally to see if there is a preference for fine-grain event handling or whether onpayerdetailchange suffices [on Wanli Yang - due 2018-06-21].
IJ: Any Facebook input?
Roy: Not particularly.
<scribe> ACTION: Ian to ping Braintree, Stripe, and Shopify on this question
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
Marcos: Another change (editorial
mostly) is cleaning up slots
... this cuts spec text
IJ: Any impact on implementation?
Marcos: Not really
... In summary we will have really nice fine grain error
reporting and retry
... e.g., errors re: addresses or payer details
... We should also consider instrument-level error handling
IJ: that would propagate to
payment handler
... On the one hand I can imagine excludedInstruments that is
payment-method specific, but there are some security issues
Marcos: Right now I am just at the use case level.
<marcosc> https://github.com/w3c/payment-request/issues/727
https://github.com/w3c/payment-request/issues/27#issuecomment-337064813
IJ: Have we made changes to help address this (in other ways)?
Marcosc: No
... there's no event, no requestPayerAddress, no
payerAddressChange
IJ: this was related to Singapore discussion of a general purpose address thing
Marcos: We have that in place
now; need to change private constructor to public
constructor
... so the spec has a special section just on addresses
... in the future we can move that to some other independent
spec on addresses
Marcosc: having the explicit request for it that michelle proposes seems good
<marcosc> requestPayerAddress
IJ: I think it needs to be
requestBillingAddress
... propagated also to payment handler
... where the browser is not managing it
Marcos: Opinions vary on whether
the browser should manage it
... relates also to changing payment handlers while in the
sheet
... but right now that's not supported in google's
implementation of payment handler
https://github.com/w3c/payment-request/issues/27
Marcos: It's trivial to add the new event
we can add the requestBillingAddress and the event
scribe: and then in Basic Card we
deprecate the billingAddress being bound to the basic card
response object
... and we redact it and send back the country and zip
code
... in event responses
... and then finally in payment response you get the proper
billing address
... this lets you do privacy sensitive tax
computation
<scribe> ACTION: Marcos to write up this requestBillingAddress + event proposal
<trackbot> Created ACTION-98 - Write up this requestbillingaddress + event proposal [on Marcos Caceres - due 2018-06-21].
UNKNOWN_SPEAKER: we could also leave the response in basic card and not change it
https://github.com/w3c/payment-method-basic-card/issues/49
https://github.com/w3c/payment-method-basic-card/issues/49#issuecomment-372584656
https://github.com/w3c/payment-method-basic-card/issues/49#issuecomment-373411788
https://github.com/w3c/payment-method-basic-card/issues/49#issuecomment-392551778
RicK: It's up to the
merchant
... there are two steps - capture the card data, then
processing
... once they have captured the card data they can determine
how to process
IJ: Is objective info available ot the browser?
Marcos: Realistically no
Rick: Today that doesn't happen in practice
"In Europe, since the start of 2018 regulation requires to ask the buyer to select the brand it want to use when paying with a payment card supporting more than one brand. It is typically the case with CB (Carte Bancaire) in France where card are affiliated to two brands, CB and VISA or Mastercard."
<Rick> q
Rick: I suppose a BIN lookup might be good. But do browsers have enough incentives? But if it were also a 3DS lookup as well, might add additional value to incorporate a directory service.
IJ: Please mention that on the thread.
https://blog.chromium.org/2018/06/chrome-68-beta-add-to-home-screen.html
Please register
https://www.w3.org/2002/09/wbs/35125/TPAC2018/
meeting page: https://github.com/w3c/webpayments/wiki/FTF-Oct2018
IJ: WG meets Monday + Tuesday
28 June