Meeting minutes
See also 23 September minutes.
Mercado Libre presentation
Gustavo Monteiro slides on payments in Brazil / Latam
Gus: In Brazil, the central bank drove financial inclusion through several efforts, including more informal accounts and PIX
… PIX has grown over 700% in three years
… accounts for almost half of the financial transaction accounts in Brazil (but not volume)
… there is another mechanism called EDT which is not a consumer payment method.
… credit resilience mostly due to different funding source and demographics
… the central bank does have plans to evolve PIX in a way that might have an impact on credit.
… this chart includes all channels
Gus: PIX took off in Brazil because it bridged the inclusion gap.
Gus: Now the government wants to release three new flows: in-person payments (tap to pay), passkey-based flows, and support for recurring payments
… these changes are likely to make PIX the almost exclusive rails for Brazil.
… one flow is to scan a QR code and use your PIX app to make the payment.
NickTR: How does merchant know they have been paid?
Gus: Push message to phone
… there's almost no latency
vkuntz: Is there a time limit on the execution time transaction?
Gus: Time limit depends on level of sophistication of the store front
… POS transaction has a timeout...I think it's about a minute.
Paulo: It may be even longer.
… the protocol has very narrow windows
smcgruer_[EST]: We had heard statement or claims that for e-commerce, users saw high latency in PIX payments after returning to the merchant.
Gus: You're not wrong. The latency is not because of PIX but rather the ways the current web flows work.
… this is for in-person payments.
Gus: The central bank has been working with some of the Pays to enable the onboarding of a PIX account into the wallet using passkeys as the identifier for the account.
… if you set your PIX account as your default payment method, you can use tap to pay in-store
NickTR: You would also need to work with the terminal providers.
Gus: There are aspects of tap-to-pay for PIX that are still evolving; we are waiting for the central bank to determine the path.
Gus: We are piloting tap-to-pay
… there's a difference between tap-to-pay and tap-to-your own phone
… it's widespread for merchants to use their own phones as a terminal
… that's what we're piloting right now: tap your card to your own phone.
… for tap-to-pay, that's BAU.
rbyers: Will tap to your own phone work on the Web?
Gus: Not yet; that would be awesome.
Nick_S: Do you get liability shift for tap to your own phone?
NickTR: You'd need to talk to the schemes about that.
(Some discussion of recurring payments plans)
Gus: You'll be able to schedule payments. You will be able to authenticate once and generate a token. The merchant will use the token to request payment according to the frequency.
… the subsequent transactions are merchant-initiated without user interaction
(Evolution of PIX for web mobile)
Gus: Today you have two options when buying online:
a) You are on a desktop and scan a QR code on your desktop screen. Requires two devices.
b) Or you can use copy-and-paste pix. It's clunky but needed because many people don't have two devices.
… so the central bank has decided that passkeys will be the authentication mechanism for PIX transfers.
<Zakim> rouslan, you wanted to ask why copy and pasted instead of deep linking into banking app, e.g., with payment request and payment handler.
Gus: Copy/paste happened because they could not figure out how to do a safe transaction with a single device.
Paulo: Once of the concerns of the central bank was also defaults.
Gus: You need to use the scanner within your bank app in QR code flow
Gus: In copy paste flow, the merchant allows you to copy a string with a button, and then paste the string into your bank app. And bank apps can easily recognize you have a PIX string in your copy buffer.
smcgruer_[EST]: Do bank accounts allow you to screen shot a QR code?
Paulo: Some banks used to allow sharing of PDF of boleto, so I guess it could happen in theory
Gus: I'm not aware that any bank has prioritized this since they expected other flows
rbyers: What about Malware that detects payment addresses and puts its own address in instead?
Paulo: I think there was a scenario like that a couple of years ago (a sophisticated attack).
Gus: Our biggest challenge is drop-offs.
rbyers: All the problems you are mentioning are the ones that came up in discussion yesterday around digital credentials. See Concerns with custom schemes for identity presentment.
Gus: The central bank has been showcasing a passkey flow.
(Slide showing double click - passkey flow)
Gus: the decision to use passkeys has been communicated, but I don't believe the specifications are available.
fahad: How does the merchant trigger the WebAuthn flow
Gus: We don't have those details yet
… but we expect the bank that provides the funding account will provide the passkey
… the central bank wants a passkey per pair of bank account / wallet.
… and the issuer would be the relying party
Ian: When would you expect more details to be available?
Gus: By the end of the year, we will have a better sense.
rbyers: When it shows bank A / Bank B...what if the list is very long?
Gus: The central bank's idea is to show the list of banks for which you are ready to pay. And if you don't see your bank you might see an "Add bank" button.
rbyers: So each merchant would maintain a list of banks for their customer?
Gus: The central bank doesn't want your phone to have a single passkey for all your bank accounts (my current understanding)
… they want the user to clearly consent to each payment initiator.
smcgruer_[EST]: My general thought is that we're looking here at a variant of the Nascar problem.
… to filter we run into privacy issues.
… I'm curious to see what the central bank is thinking and how we might help.
Gus: Because we are both on the seller and buyer sides, we have a few use cases we want to explore
(We move onto some challenges specifically for discussion at TPAC)
(See SWOT slide)
Gus: We have a challenge when merchant is selling at their own origin.
… what we want is to enable the use of saved credentials cross-origin
… we want the UX to be the same whatever the payment method
Jonathan: How do I select methods when on the merchant site?
Gus: We are the PSP.
Gus: We don't want to redirect. We want to recognize you in the seller context, so that the seller can later show the list of payment methods.
Jonathan: Who is the RP?
Gus: We'll have passkeys for the user to authenticate to MercadoLibre.
… that would already be useful to use a pre-existing session to get the right key associated with your account
<Zakim> rouslan, you wanted to comment about user recognition challenges
rouslan: One concern would be tracking. Can you use something like FedCM, WebAuthn, Payment Handlers? If something doesn't work we can work together to improve them.
Gus: When the user is on MercadoLibre we would enroll the user to be able to pay across participating merchants.
Sidd: I thought there might be a "Pay with Mercado Libre" and they would authenticate with you, and then after authentication instruments would be shown in wallet.
Gus: We do have a payment button (especially for outside of Brazil)
… in that scenario, you click the button, you are redirected. if there is an existing session you see your existing wallet, you select an instrument, and you pay.
… but merchants don't want redirects or adding 3p buttons to their checkout
Gus: Topics for discussion:
- How to recognize returning user whatever their original session (web/native) on that device, or the merchant they are visiting
- How do we use the session later to pick the passkey associated with their Meli account, and/or
- How do we use that session later to pick the passkey associated with the payment method they selected?
<Zakim> rouslan, you wanted to suggest fenced frames as a consideration
rouslan: There's an upcoming technology called Fenced Frames that might allow you to embed 3p information in a 1p context without the ability to track
Paulo: Fenced frames cannot communicate to server or parent page?
Rouslan: Correct, you can only read the data that user has stored.
Pablo: We are exploring payment request API for decoupling the integration into the seller from authentication method
… that would allow for native app authentication.
… we think this is interesting.
Paulo: We are also interested in FedCM
Chris: Multiple IDPs are in the works.
rbyers: We have an origin trial going on right now related to this. See FedCM Multi-IDP origin trial (desktop only for now) details.
Paulo: We welcome any suggestions to experiment with them in our checkouts. I expect we'll have multiple solutions and we'll have to negotiate with merchants to see which they prefer.
Jayadevi: PIX sounds similar to UPI. I think there are a lot of synergies.
… there are some interesting features emerging like the "UPI circle" where I can add my daughter to an account.
Jayadevi: I recommend looking at the UPI feature set.
Power Outage and Group Photo
At this point in the meeting (around 10:30am) there was a power outage at the hotel. We did take advantage of the opportunity to take a group photo. We reconvened at around 14:00.
Payment Handers in Chrome
Rouslan's payment handler slides
(Rouslan shows a slide with current payment handler experience)
Rouslan: As a reminder, both web apps and native apps can be used on Android to respond to payment requests.
(Rouslan does a refresher for payment handlers; see the slides)
Ian: Can we pull back from PH API to discuss payment handlers and digital credentials API?
Nick_S: I think that's an interesting topic. It's possible that the work in identity will cause us to revisit payment handler.
Nick_S: There's a lot of value in PH API, including the ability to talk to apps.
… so that's a valuable effort.
… it's interesting in a case like UPI where there may be multiple wallets for a standardized payment method.
Ian: we imagined standardized payment methods (e.g., basic card) with N handlers per payment method, but that vision has not panned out. In practice we see one payment handler per payment method. One in a world of N payment handlers per payment method is the payment handler selection (and debates about topics like "top of wallet")
Rouslan: Furthermore, people could use multiple payment methods per PR API call, but in practice they only use one.
… it would be nice in practice to be able to have a single payment request call referring to multiple payment handlers. But that's probably a long way off.
Rouslan: One topic of interest is "can user activation be implementation specific?"
… paymentRequest.show() had required user activation, but we have seen requests from payment method owners to not always have them, especially when the payment handler shows up after a redirect.
… the compromise in our implementation is to not require a user activation after a redirect, but only one time.
… we'd like to add this to the specification and want some feedback from other browser vendors and PSPs
(Rouslan and Marcos and Abrar will chat about user activation)
<Zakim> nicktr, you wanted to ask about digital credentials app/payment handler cross over (e.g. android-credential-manager)
nicktr: Has there been any experimentation to use the PR / PH handler pattern for credential management?
rouslan: We've seen FedCM as a card selector in a demo
Rouslan: We might want to have "handler" as a primitive - a special window with special properties and security that can be opened in an 1p context in a privacy preserving way.
… that concept we may want to spin out into its own API.
Gerhard: There is potential of using the payment handler as a vehicle to improve the 3DS iframe window.
… the merchant would reach out to ACS in an AREQ. The ACS would say "I would like you to use a payment handler to create this challenge"
… that would require installation and activation of the payment handler instead of the Method URL
… is that a feasible use case for payment handlers?
… the payment handler would return the 3DS cryptogram.
Rouslan: It used to be possible to install a payment handler "manually" by visiting the origin of the payment handler (which would install the service worker). But that functionality has been removed from the spec. It is no longer possible to install a payment handler manually, it can only be installed on the fly.
NickTR: Does the current SPC implementation use a payment handler?
Rouslan: No. It uses PR API but not a payment handler.
Ian: If that's the case, could you allow SPC within a Web-based payment handler if you have an "if statement" in the browser code? I had been concerned about not being able to use SPC within a payment handler since that would mean calling payment request within payment request. But if the browser can detect that this is for SPC, then that should allow for SPC-in-a-payment-handler.
Rouslan: Might be feasible but some small challenges perhaps.
Ian: It would be useful to to be able to use SPC within a web-based payment handler.
… that's more secure and convenient than vanilla WebAuthn in that context.
(Some discussion of using FIDO and selecting credentials v. empty credential list)
Ian: Can you say more about Web Payment handlers in Webviews?
Rouslan: Webviews don't have interfaces provided by the library.
… so we don't think web payment handlers will come to web views, but web views run on android and there is support for android-based payment apps
… so there's more hope that android payment apps will work in web views. That would make sense.
… we might need to change some ways we invoke android-based payment apps, but the key component is that web view host apps would have to provide permission to invoke payment apps.
… for developers who fork web view, what's the typical motivation for that?
SamWeiss: There are a variety of motivations. We sometimes run into edge cases. Initialization performance can be slow, for example.
… one feature we are working on currently is asynchronous browser initialization
… to avoid freezing the UX
Rouslan: Can you say anything about Meta views on payment request and payment handler?
SamWeiss: Payment processing is important for us, and making it efficient is important to us. I don't know that we have positions on specific standards, but we'd like to improve them for the ecosystem.
Rouslan: Does any of this discussion apply to the Webkit web view?
Nick_S: Probably doesn't apply.
Merchant Perspectives
SteveCole: I am here from MAG. Our Membership is large US merchants. We focus on payments through collaboration, advocacy, and education.
… please note that "merchants" are a large and diverse group, and don't necessarily see eye-to-eye on all topics
stevecole: Merchants do want to maintain control over their customers' experiences.
… so it's good to see when the community works in that direction.
… some disclaimers: the "hot topics" comes from a wide and diverse group of merchants. So may be hot for some but not others.
… these hot topics are focused on pain points (rather than "future directions")
… hot topics in ecommerce:
* OmniChannel retail and barriers to seamless transactions
* Pay by bank
* PCI 4.0 readiness
* 1p fraud
SteveCole: One question has been "would there be a pullback from e-commerce in light of the progress we've made regarding covid?" I think the answer is that experiences will become more integrated, with blurring of line between online and in-person
… buy online + authenticate in store created authentication issues.
SteveCole: But it remains a challenge to solve for: authenticating the user and the credential. There are scenarios where merchants have tried to lower their costs (e.g., you presented a card on the web)...you pick up in store and present a different or same card...is that a card present traction?
… I don't see a pullback from e-commerce but rather more integrated experiences.
NickTR: I've spent a lot of time with retailers around this. This is another area where payments and commerce veer into identity.
… work around digital credentials that we discussed may help with the integrated experiences.
SteveC: The ability to identify the consumer is 99% of the battle.
SteveC: You may have seen a recent announcement of a large retailer supporting pay by bank (instant payments). But that raises interesting questions about chargebacks and disputes.
… the functionality that was announced was for online only.
… and the question that's important is "was that the authorized user"?
… PCI 4.0 requirements around multi-factor authentication may be challenging.
… for March 2025
… I think many merchants are not prepared for MFA.
… another area that's huge for merchants is 1p fraud. Although it's not exclusive to e-commerce, it's easier to say "I didn't get it" in remote context.
… the networks are coming up with some approaches for helping understand that a consumer agreed to a payment.
… as NickTR said, it comes down to identity in many cases.
NickTR: In the EU regulatory context, it seems the community encouraging more sharing of data to help combat fraud.
vkuntz: See the speech from Mario Draghi from a week ago and Report on Mario Draghi speech.
Steve: Browser token autofill creates issues for merchants; makes it hard to know their customers.
… single use tokens can also cause routing issues
Steve: 3DS is another area of interest. Some stakeholders think that merchants should be implementing 3DS in a more systematic manner. From a merchant perspective they see inconsistent implementation from issuers.
… within MAG we need to drill down to better understand what the implementation issues are. Is it about decisioning process (probably not for WPWG) or other technical topics (perhaps more in-scope). Another topic is fraud management in general, use of AI and machine learning
Ian: See AI & the Web: Understanding and managing the impact of Machine Learning models on the Web
NickTR: Regarding token autofill, is the issue that it's hard to join transaction due to differing numbers? What about PAR?
SteveC: PAR comes up in our membership. Perspective is that it's not being applied consistently enough to be useful.
Arman: Although EMVCo has published the specification for that, it does not play a role of mandating features.
NickTR: Implementation cost would high.
Sue: For first party fraud, is there an industry where that happens more than others?
SteveC: It's more online than offline. But it seems to apply across industries. Return fraud is a variant of 1p fraud.
… I'm not aware of e-commerce merchant who say it's not an issue for them.
benoit_: What is perspective generally on pay-by-bank?
Steve: It's not yet huge, although there are service providers with (fairly successful) pay-by-bank solutions.
… you have to separate online from offline when talking about pay-by-bank.
… with online transactions, the cardholder is in an environment where the amount is known.
… in offline, you'd need "request for pay" for that to work.
… that would be more challenging from a UX experience, so I think the online space may move faster.
… but there are still latency issues.
… small merchants may face challenges.