Web Payments WG

PR API

Nick: This will be our last main call of 2020
... We announced return of PR API 1.0 to Candidate Rec

Announcement

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)

Timeline to Rec

Introductions

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 codes

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.

Meeting schedule

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]