Nick: This will be our last main
call of 2020
... We announced return of PR API 1.0 to Candidate Rec
Nick: We made substantive changes
(to remove features) so cycled back through CR en route to
Recommendation
... the next step will be Proposed Recommendation (final review
by W3C membership; dot the i's)
... then Recommendation expected mid-March
... we also extracted MerchantValidation event as an
informative Note (since only implemented in Safari)
Nick: I think this is Lauren Jones' first call. Welcome
Lauren: I participated in this
group while at Payments UK / ISO 20022 RA. recently rejoined
with Huawei
... looking at payments innovation in QR and PR API
QR code use cases doc (new from NickTR)
NickTR: I've cataloged 4 main
categories of use cases
... and expressed this as a "quadrant" in the new resource
...rows: 2 devices, 1 device
...columns: QR-is-URL, QR-is-not-URL
NickTR: On "single device" use
case where QR represents a URL, Web site can make the QR code a
link.
... the "Unhandled" use case is single device where QR code is
not a URL
... so is there a browser capability that would be useful in
that case?
IJ: We could say in point three that the QR code provider should make it a link
Gerhard: I like the visualization
of the permutations
... we have been wondering "how much easier should we make it
compared to today"
... my question is "how much could the payment handler
help"?
... it may be that we want to offer a payment request
capability where the merchant doesn't need to know that there's
a QR code
... e.g., I"d like to get this type of account details...
... and potentially the browser could create the QR
... if we could say that "there's a link" then all of this can
be supported if the merchant chooses the QR
... but that leads to proliferation of QR codes
... so the model could be that the merchant accepts N payment
method types, and the browser and/or payment app helps resolve
it
NickTR: So the merchant calls PR
API and accepts, say, Alipay
... then it's either the merchant or the PSP that will generate
the QR code
... do you want it in the payment sheet/
Gerhard: It's more a question that, as a Merchant I say I accept the payment method and the UX is left to others
IJ: Does the user see an Alipay button or a QR code
Gerhard: Two paths possible: (1)
EMVCo can embed multiple QR codes in a single package
... so the browser can look for a relevant payment handler OR
generate a QR code so that a separate device can be used
NickTR: That question of "putting the QR code in the sheet" has been mentioned by Adrian
<benoit> browser crashed... brb
IJ: I am hearing that basically
the browser responds with a QR code instead of launching a
payment app for a given payment method selected by the
user
... how does the user know they will get a QR code?
Gerhard: That could be a user
choose when selecting to pay
... e.g., choose that button
... I'd like to hear from merchant/PSP
... It would be good to hear from the merchant side. From the
issuer prospective, we'd like to not have to ask each merchant
to implement solutions specific to us (a particular issuer)
benoit: We may wish to abstract
away from QR codes; there might be new technologies moving
forward.
... this is a "passive challenge"
... the thing that is displaying the QR code is passive to the
device that's receiving it
jonathan: The NFC forum did a spec for passing a QR code in an NFC.
Gerhard: Ian touched on
something....we're assuming that there is no payment app
installed on the first device (e.g., merchant at cafe with an
iPad)
... the merchant calls PR API with Alipay...there's no payment
app...so the browser consults the payment method manifest
... and the payment method manifest has information about
support for QR
... and the browser could interact with Alipay to get the QR
code
... so the payment handler is "remote"...on the second
device
... I don't know whether that's a sufficient enough
advantage
(Ian is not sure there's a big advantage over Alipay just rendering a QR code after the user clicks the Alipay button)
NickTR: So the use case is where
the user is checking out on a device where there's no Alipay
payment handler. The browser does a "Just in time" handler that
displays a QR code.
... you'd not close the sheet until the QR code has been
processed
<nicktr> https://github.com/w3c/webpayments/issues/257
(Ian summary: Seems like there is some interest in how to handle case where there is no payment app for a payment method...and whether we can facilitate the display of a QR code, e.g, via a JIT payment handler)
<Gerhard> Thanks for the writeup Nick! Nice place to collaborate.
Proposed: No meetings until 21 January
NickTR: Our next regular meetings would be 24 Dec and 7 Jan (but we'd not have done much before then)
RESOLUTION: next Thursday call is 21 January
<Gerhard> +1 for that
<jv___> +1
NickTR: Thanks to everyone for
their participation this year.
... we are moving the spec toward Rec
... we had two successful extended meetings and a code-a-thon
this year
... SPC is generating excitement
... thanks to all
... especially Adrian, Ian, editors, implementers,
contributors!
... We'll solve all the payment problems in 2021!
[Cheers]