Meeting minutes
Facilitated Payments Links
Ian: Our recently approved charter enables us to take up the proposal "Facilitated Payment link type in HTML." To help swap back in the context for the proposal, see Comparison of Wallet Technology on the Web. Today the Chrome Team will remind us of what the proposal does and its implementation status.
smcgruer_[EST]: We spoke with stakeholders in various parts of the world about painful user journeys involving handoff from browser to another device, typically via a QR code. Often relates to push payments, but not always.
… Payment Request covers this space but one thing we heard from merchants
… was that it was not feasible in some cases to use a full JavaScript API, but also because a lot of the flows are server-to-server concept.
… and so the merchant site is not in a position to received information (which it would get through PR API) and then hand it to a server.
smcgruer_[EST]: So Facilitated Payment Links is declarative in the head of the HTML document. The browser can hand off the data to a payment app, whether the directive is for a specific app or a generalized method that can be handled by multiple apps.
… the browser can help the user get to the app, or "do nothing" if the user has no relevant app.
… one question has come up that we want to explore further: "can the apps be "payment apps" in the Payment Request API sense?"
… Chrome has shipped support for this API for a variety of payment methods (mostly in southeast asia, and we can learn from that)
nicktr: A key use case is avoiding the need to scan a QR code when it's displayed on your mobile phone
smcgruer_[EST]: We have also seen flows where users are expected to have 2 phones, which is painful
gkok: What are the payment methods already supported? And can we test it?
Rouslan: DuitNow, ShopeePay, Tngd, PromptPay, and Momo.
gkok: We support two of the methods that were mentioned by Rouslan. If you have traffic info about existing merchants, that would be very helpful.
smcgruer_[EST]: At the time of purchase where you would render different options on the screen, you would have links in the document head, and the browser can read that info and offer to the user (without telling the merchant) the app
Sharanya: Is it possible to indicate a specific payment instrument as part of the handoff?
smcgruer_[EST]: That is likely dependent on the payment method, but it's likely possible
… personally I think about it as one step earlier "selecting a payment method"
nicktr: Or "selecting an application."
smcgruer_[EST]: But I think the API is pretty agnostic.
Juan_Pablo: Suppose I'm a merchant. I would offer a set of payment methods in the page but also links in the head of the document...And the browser would show the options in the head of the document?
… how does the merchant know whether the user has selected a payment app?
smcgruer_[EST]: We assume both buttons in the page and also these links in the head of the document. In the case where no links match, the user is just looking at what the merchant provides in the page.
Juan_Pablo: If there is a match and I can choose an option, because the merchant site doesn't know that the user is going through that flow, how do we prevent that the elements on the page from being used by the buyer.
… e.g., accidentally paying through 2 channels since the backend payment is asynchronous.
… would we block the web site UI until a link resolves
smcgruer_[EST]: That's a good question. That's something that can already happen today with payment methods shown in a page.
(See slides from January with some user flows.)
smcgruer_[EST]: Good question whether it would be useful to address the question of informing the merchant (but in a privacy-protecting way).
Juan_Pablo: This is the first time I hear of a mechanism where the merchant does not get a signal.
(We invite people to make suggestions and raise issues in the issues list for this API.)
smcgruer_[EST]: the asynchronous part is very common in push payment flows
Juan_Pablo: The merchant triggers the QR code so has some awareness.
Albert: I think this describes one of the biggest challenges we see in the 3DS space (where we need to get the user to an app to authenticate)
… are you thinking about integration to 3DS and sandbox requirement?
gustavo: I've asked the EMVCo 3DS WG about this. I think the problem related to iframe
Dan: Are there events that are subscribable that come with this flow?
smcgruer_[EST]: Not right now, but that's a good idea. It could be interesting to tell the merchant some things with browser-fired events.
… e.g., we can throw and event to the page that "the user has selected a thing" and an event later "the user is back"
… but what usually happens is that the second you land in an app the first thing the app does is to take a transaction id and talk to the merchant.
Sami: From a 3DS perspective, we do have a sandboxing requirement with some parameters allowed. The 3DS WG is working on this.
… currently we block calls to apps
… but we are evaluating this for out-of-band access
… we came across this during EUDI wallet situation (same use case of same-device). It would be could to continue this discussion from that point of view as well.
… we are looking at this specifically in the auth app from the merchant side, but not the payment context situation
Ian: the fact that it's declarative may make this easier to permit in 3DS
Sami: But if something happens outside of the 3DS request/response flow and outside of iframes, it's not a 3DS issue
Gerhard: I am hearing interest in taking this up. Sounds like something we should discuss and pursue
… I like that it is making the front end easier for the merchant to flow things in
… the link would be a good way to tie into existing assets we have.
<smcgruer_[EST]> +100 !! :)
Gerhard: so linking up with payment handlers is intriguing
… sounds like the 3DS flow could happen within the payment app
… there are some cases where the merchant doesn't know the card, and this could help in those cases.
… a concern: the merchant needs to pass information to the wallet (e.g., transaction id). I may need to show some information to the user in the merchant page after the payment has happened.
… e.g., how handle a decline
smcgruer_[EST]: I am a big proponent of the idea of hooking this up to payment handlers.
… it doesn't work that way today but I'd like to move it in that direction.
… I agree that when the user returns to the merchant page after payment, I think it would be a big bonus that there's some sort of optional event that's fired (e.g., on the link element) when payment request has finished and here's a bundle of info
… we'd get that through the payment handler API
Ian: What about SPC? Could be used in a custom tab in a native app, or supported in a web based payment handler.
Ian: As far as next steps, my expectation is that we will issue a Call for Consensus to formally take this up. Stephen, are there any reasons on the Chrome side to wait before issuing the CfC?
smcgruer_[EST]: No timing requirement from the Chrome perspective.
Nick: Since people are still rejoining the WG after the recharter, I expect we will wait a bit before issuing the CFC.
Ian: I would expect to start the CfC mid-September.
Rejoin!
Ian: I will also take this opportunity to urge organizations to rejoin the WG after the rechartering. (We then walked through the list of participants to remind some of the people on the call of the need to rejoin.)
Action review
Ian did his => w3c/
Daniel did his => w3c/
Upcoming meetings
No meeting: 11 September
Ian: We do plan to meet on 25 September and will talk about w3c/
... We are also starting to work on the TPAC agenda and welcome your suggestions and offers to do presentations or lead sessions.