<Ian> NickTR: Making good progress since 2015; always good to meet new participants
<Ian> (About 12 people for whom this is the first FTF meeting)
<Ian> NicKTR: Interesting to see proliferation of payment methods here in Singapore
<Ian> ....including local Singapore payment method (Nets)
<Ian> ..QR, biometric innovation
<Ian> [Introductions around the room]
<Ian> NickTR: Great to have TCH here and have a non-scheme tokenization service provider; shows value of standards and open markets. A big portion of the meeting will involve breakouts and then we'll come back and share findings
<Ian> NickTR: PR API and Payment Method Identifiers the most mature
<Ian> ...payment handler coming along
<Ian> ...newer work in tokenization, etc.
<Ian> ...I think our priorities are to get PR API to Recommendation this year, and to move Payment Handler forward
<Ian> Sachin: PR API has been implemented by the browsers, what does it mean in practice to move to Recommendation?
<Ian> marcosc: Candidate Recommendation is the state of the W3C process where we say "This is ready to go; please try it out"...it's a beta testing period
<Ian> ...as part of what we call "CR Phase" we produce tests to get interop across implementations.
<Ian> ....does it work in the real world? Does it work in browsers? Does it meet actual developer use cases?
<Ian> ...we have found so far that we are pretty interoperable but still have a few issues
<Ian> ...and we've also encountered some issues where the real world was different than we thought
<Ian> ....one example is regionCode
<Ian> ...differences between values returned by browsers
<Ian> ...a merchant rep let us know that there were disparities and so we need to take that into account
<Ian> ...specifications keep moving forward
<Ian> ...we've been disciplined in not adding new features, but now we are at a point where we need to freeze the feature set
<Ian> ...merchant validation is an interesting example
<Ian> ...still on the question of "v1 or v2" another topic is "store cards"
<Ian> ...so part of the discussion at this meeting is "in or out"?
<Ian> ...another topic where we need to make a decision is currencySystem (a feature at risk)
<Ian> ...the specification supports ISO 4217 currency codes
<Ian> ...the question was how to handle cryptocurrencies and other codes not yet in ISO 4217
<Ian> ...it's an important use case, but in the end no browser implemented the feature as specified
<Ian> ...so we came up with a proposal to remove the currencySystem bits and leave in its place some text about browser behavior
<Ian> ...meanwhile Ian has been liaising with ISO on the maintenance of 4217
<AdrianHB> Ian: I have been speaking with the ISO 4217 maintenance task force lead about this. They are still working out how to handle alternative currencies.
<Zakim> AdrianHB, you wanted to add that currencySystem also refers to loyalty points etc (not just crypto)
<Ian> AdrianHB: The currency system idea had been - when you present a total, by default the currency system is a code within ISO 4217....the proposal was to allow for codes from other currency systems....and in the API you identify the code and the system
<Ian> ...that wasn't implemented
<zkoch> All those use cases are better served by payment handlers anyway
<Ian> PROPOSED: Adopt pull request 694 (to remove currencySystem and add text)
<AdrianHB> +1
<Roy> +1
<zkoch> +1
<mweksler_> +1
<SachinAhuja> +1
<stpeter> +1
<takashi_m> +1
<anthonyvd> +1
<durga> +1
<Ian> +1
<Ian> [No objections]
<Ian> NickTR: the proposal is carried in the room to remove currencySystem from v1 of the specification; having heard strong support
<Ian> ACTION: Ian to start a call for consensus to adopt the pull request to remove currencySystem
<Ian> Pull request 690: Add regionCode attribute
<Ian> marcosc: Should this be in v1 of the specification?
<Ian> ...we have documentation in the Mozilla Developer Network (MDN) and 2 browser commitments
<Ian> ...regionCode can be free-form input
<Ian> IJ: I thought there was harmonization of data through PR API
<Ian> Anthony: We do some harmonization, but not for autofill data
<Ian> AdrianHB: But isn't there some harmonization of fields across browsers?
<Ian> (Yes, for the address)
<Ian> vkuntz: ISO 3166-2 is a predefined list of region codes; they are linked to the country codes
<Ian> marcosc: The larger question is whether we want to support this
<Ian> vkuntz: I think we should go further...regulatory reporting REQUIRES the 3-letter codes
<Ian> ...so that would imply internal conversion which would be more complex than just using the standard codes
<Ian> zkoch: I hear the proposal is "region; no guarantees on data format" and optional "regionCode, drawing from ISO ... and browsers will provide back if they can"
<Ian> ...but how as a developer would I reason about the two values?
<Ian> vkuntz: When you look at the region codes for the US they are the same as the state codes
<Ian> zkoch: That works well with states with well-defined address systems; that does not work well for countries that have local knowledge built-in
<Ian> ...I think it's fine to have BOTH but I don't think a region code would suffice on its own
<Ian> vkuntz: I think it will suffice
<Ian> marcosc: There are gaps in the libraries we rely on
<Ian> ...the lib address library only is updated every once in a while
<Ian> IJ: Does the spec say what to do when you get both back?
<Ian> zkoch: We can't switch .region to .regionCode
<Ian> AdrianHB: The understanding is that if you get a regionCode it's because the browser provided the user with a drop-down list
<Ian> ...and so the validation on the merchant side might differ
<Ian> marcosc: We still have some edits to do...the core question to work out here is whether to include this in v1
<Ian> anthonyvd: I am looking at ISO 3166-2...if you look at the UK, the regions are 3 countries and other stuff
<Ian> ...is the browser supposed to find the most specific region possible?
<Ian> marcosc: Yes....Belgium is insane
<Ian> vkuntz: But you don't need the region to ship in Belgium
<Ian> IJ: What is the question for devs?
<Ian> ...is there a common library? What is the interop burden?
<Ian> zkoch: And will there be interop?
<asolove> +1
<Ian> AdrianHB: I am hearing this is important for (1) regulatory reasons and (2) shipping accuracy
<Ian> ...the value of the proposal is more accurate data compared to free-form
<Ian> ...the interop question is whether the regionCode data is interoperable across browsers
<stpeter> Ian: audio dropped from Singapore
<Ian> Sachin: The use case we've seen is shipping restrictions
<Ian> ...don't show me some things I can't support
<Ian> Marcosc: That's outside the scope of this discussion
<Ian> MattS: What is the relationship between shipping and billing address?
<Ian> vkuntz: I think the regulatory requirements are around billing address
<Ian> AdrianHB: Any progress on an address object?
<Ian> Marcos: What I did a couple of months ago was to specify in more detail how you create an address object
<Ian> ...we have to put in a couple of sentences and then we can use generic address objects
<Ian> AdrianHB: That impacts matt's question...if the address object is reusable, then billing and shipping would be instances of it
<Ian> MattS: Agreed
<Ian> marcosc: That's currently planned for a future release
<Ian> mweksler_: From a merchant perspective it's useful to have better quality data
<Ian> ...so I would support this
<Ian> ...when we can have something from the standard, use it, otherwise freeform
<Ian> nicktr: Here's what I think I heard....
<Ian> ...there's an appetite to solve this in version 1
<Ian> ...but I'm not sure yet there is consensus about how to solve in v1
<Ian> ...so the WG would say to the implementers "please continue to work on this."
<Ian> PROPOSAL: please work on a regionCode solution and present it to the group
<Ian> +1
<mweksler_> +1
<AdrianHB> +1
<MattS> +1
<SachinAhuja> +1
<zkoch> +1 ¯\_(ツ)_/¯
<stpeter> +1
<vkuntz> +1
Editor's Note: While there was no formal action, the expectation is that the PR API Editor's will continue to work on a regionCode solution.
<Ian> Pull request 695: add paymentmethodchanged event
<Ian> aestes: In ApplePay.js we fire an event when the card changes.
<Ian> ...this event usually just carries the type of card, including debit, credit, prepaid, and store
<Ian> ...this is usually sufficient for merchants to modify the payment request
<Ian> ...store cards pose a special case
<Ian> ...suppose you have a Target card and the user is visiting target.com....we recognize the card is issued by the domain
<Ian> ...we provide the site back enough information to enable the site to look up information about the account (e.g., related to loyalty)
<Ian> Giulio: Not just for store cards; also for co-branded cards
<Ian> ...e.g., united airlines
<Ian> mweksler_: This would be useful to Airbnb
<Ian> ...e.g., for installments
<Ian> zkoch: I think paymentmethodchanged does not solve the core issue, which is about privacy
<Ian> ....we try to not divulge information without clear user consent
<Ian> ...when we open the payment sheet, we don't want to unintentionally fire a specific identifier of the user
<Ian> ....for instance, the user might not have expressed an intention to be personally identified
<Ian> IJ: Isn't the event fired only upon user selection?
<Ian> Aestes: We fire the event automatically in ApplePay if the card is the default
<Ian> zkoch: The Chrome team has hesitated to do paymentmethodchanged for this reason
<Ian> ....we thought for flows like this we could just have merchants tell the user what's going on after the flow
<Ian> zkoch: It's the same reason we don't select shipping address by default. We can't reveal where someone lives without consent. I want to think about whether there's a way to solve for this in a privacy-preserving way, and if we can great, if not we should discuss our options
<Zakim> AdrianHB, you wanted to ask about assigning an origin to payment instruments as an indicator that the data can be shared with the PR API caller?
<Ian> AdrianHB: What about adding a piece of info to the instrument data - origin of the issuer
<Ian> ...this would let the browser know more cleanly know whether to share more information with the site
<Ian> ...e.g., target.com associated with the card
<Ian> ...and only in that instance is the event fired
<Ian> zkoch: Still a privacy issue; the user should have the ability to consent at the transaction time
<Ian> ....as an analogy: In a physical store, although I could use my target card I might still prefer to use cash for some purchases...I want to enable that online as well.
<Ian> AdrianHB: There are two issues (1) When to share information and what information (e.g., origin) and (2) whether explicit consent is required
<Ian> zkoch: We could also make some implementation decisions in Chrome
<Ian> ...I'd like to see whether we can achieve with modifiers
<Ian> SachinAhuja: I am 100% in Zach's camp here.
<Ian> ...revealing identity is risky from a compliance perspective
<Ian> mweksler_: I share Zach's perspective as well
<Ian> ...there's a tension here ... I can see that from a merchant perspective we need some way to enable dynamic choices
<Ian> ...I think we want some flexibility on the merchant side regarding price calculation.
<Ian> NickTR: I think that this issue reflects our choice to mix checkout and payment
<Ian> ...you need to handle the whole checkout experience and figure out how to knock out each event piece by piece
<Ian> ...meanwhile I heard appetite to work on this and so ask the implementers to write a proposal
Editor's Note: While there was no formal action, the expectation is that the PR API Editor's will continue to work on an approach for handling store cards and co-branded cards.
<Ian> Pull request 647: retry and fine grained error recovery for fields
<Ian> marcosc: The Mozilla UX team is concerned that we do not have a retry() feature
<Ian> ....this is something that ApplePay allows
<Ian> ...there's a model based on ApplePay
<Ian> ..this is a bit of a blocker from our UX team
<Ian> ...the merchant would be able to signal errors in the data
<Ian> ...or provide useful info to the user such as "we can't deliver to the address you provided"
<Ian> Shay: This would be great. Without this feature we as a PSP would have to implement it on our own
<Ian> ...so I support this feature
<Ian> IJ: Statements of interest from the browser support?
<Ian> Aestes: +1 for PR API
<Ian> ...ApplePay redacts information prior to authorization
<Ian> ....if you can't ship to a PO BOX, you want to enable the user to correct the address
<Ian> AdrianHB: This is a very card-centric (or at least pull-centric) view of the world
<Ian> marcosc: We would like to have retry() in Firefox
<Ian> zkoch: I need to look more closely at the proposal but I would also support the use case at a high level
<Ian> ...but there's some gnarlyness in the details
<AdrianHB> the issue with retry for push payment methods is that the payment may be complete so a failure that is introduced by the merchant because of an address issue is more complex
<Ian> IJ: Any conversations with Microsoft/Edge?
<Ian> marcosc: Not yet
<Ian> IJ: I am again hearing interest
<Ian> Marcosc: but this is a big change; this changes the state machine
<Ian> ...the API was not designed to be retry-able
<Ian> ..we don't yet know all the bits that we might need to change
<Ian> marcosc: I am making a "this will be challenging" noise that needs an emoji
Editor's Note: While there was no formal action, the expectation is that the PR API Editor's will continue to work on a retry method.
<Ian> Payment Request CR Exit issues list
<Ian> There are 10 issues
<Ian> ...so we are close
<Ian> ...and there's been significant discussion
<Ian> ...and we also need to put together the implementation report
<Ian> IJ: Estimate of when this will be done?
<Ian> marcosc: I hope by TPAC (October 2018)
<Ian> IJ: There are numerous ways to help by contributing to the test suite or editorial proposals
<Ian> marcosc: We add a new test for each feature we define
<Ian> ...test review also welcome
<Ian> ...documentation on MDN is welcome
<Ian> ...we also seek implementation commitment
<Ian> IJ: Any upcoming release schedules to be aware of?
<Ian> Marcosc: November is one of them
<Ian> ...I hope that by Nov we have interop across all the browser engines. It's amazing how fast we have gotten there.
<Ian> [Break]
<Ian> IJ: Any obstacles to getting Payment Method Identifiers to rec?
<zkoch> No
<Ian> [No obstacles mentioned]
Basic Card Issue 49: Brand Selection
<Ian> NickTR: The particular use case being described is co-branded cards can be processed on different rails, e.g., Carte Bancaire or visa/mastercard
<Ian> ...the question is what information is necessary to give to merchant to allow for appropriate routing
<Ian> ...analogous to debit routing
<Ian> ....but this applies to multiple use cases where there are multiple schemes
<Ian> ...issue raised by Gildas le Louarn
<Ian> AdrianHB: My understanding of the issue is that regulations force the merchant to give the user a choice
<Ian> ...the user has to make a choice, which in turn requires the merchant to recognize the co-branded card
<Ian> vkuntz: In france it's even more complicated
<Ian> zkoch: I don't think we should solve this. There are lots of schemes in the world that Chrome doesn't know about
<Ian> ....our stance is that there's a number and if we can validate a card (e.g., as a Visa card) we will but for anything else we punt to the merchant
<Ian> ...In that case I think we should pass the number back and let the merchant deal with it
<Zakim> MattS, you wanted to propose MAY
<Ian> MattS: I agree with Zach that this should not be a requirement, but it could be a differentiator for payment handlers to be able to present information about the network where the merchant should route the payment.
<Ian> ....so this would be an additional field in the payment method response data for payment handlers to differentiate themselves
<Ian> zkoch: I want to clarify - you are asking the USER how the payment should be routed?
<Ian> MattS: Not exactly. As an example, suppose I have a card that says Carte Bancaire on the front and Visa on the back
<Ian> ...you might choose a particular rail based on incentives
<Ian> ...I think we should enable the choice
<Ian> zkoch: So the regulation says "For merchants where the regulation applies, ...."
<Ian> MattS: I was not speaking about regulatory requirement, I was thinking about competition....you should allow users to express a preference where it's possible to express one
<Ian> Zkoch: I am trying to clarify the use cases
<Ian> AdrianHB_: I am hearing Zach say that it would be weird for the user to be presented with that choice.
<Ian> MattS: In terms of usability, if I were to choose a payment handler from China Union Pay (CUP), it would be reasonable to expect that the data would pass through as a CUP card....
<Ian> ....expressing that the payment SHOULDN'T be done that way would be useful
<Ian> zkoch: As we consider whether we choose to adopt a change, I want to establish how important this is.
<Ian> MattS: I don't think this would prevent adoption, but without it I think it would lead to a worse payment experience.
<Ian> ...suppose they get a PAN back and they need to figure out what to do, but the wrong experience is for the user to expect one approach and the merchant picks another
<Ian> AdrianHB: I had understood the regulation to say the user must be presented with a choice
<Ian> MattS: You may see default behavior whatever the regulation says
<Ian> mweksler_: I am hearing the question whether the choice should be mediated by PR API or the merchant
<Ian> ...I am hearing MattS suggest that it's optional
<Ian> MattS: The proposal is to add selectedNetwork and selectedType fields (optional) in the response data
<Ian> AdrianHB_: These would be specified in the Basic Card specification
<Ian> MattS: My expectation is that the browser would not do anything, but third party payment handlers could
<Ian> AdrianHB_: Inferring the high-level scheme is easier than other deeper data.
<Ian> nicktr: I think this is in PSD2 as well.
<Ian> IJ: the relevant regulatory text for Europe. In Article 52(2)g of PSD2, you get a pointer to Article 8 of EU reg 2015/751.
<Ian> Which says: "Payees shall retain the option of installing automatic mechanisms in the equipment used at the point of sale which make a priority selection of a particular payment brand or payment application but payees shall not prevent the payer from overriding such an automatic priority selection made by the payee in its equipment for the categories of cards or related payment instruments accepted by the payee."
<Ian> Nicktr: I agree with Zach that it seems odd, but my understanding is that the consumer has to be presented with the choice of how the transaction is routed
<Ian> ...I think there will be a time in the EU payments market, where, irrespective of the acceptance brand on the front of the card, the user will have a choice for routing
<Ian> zkoch: I understand. There's a developer consistency issue....no matter what you are going to need to build the default UI
<Ian> ....if the regulation exists, the merchants need to provide the backup UI to handle it
<Ian> MattS: I think this leads to a better UX if the payment handler can provide it
<Ian> nicktr: We are also having to deal with this in-store
<Ian> ...at the moment, the first digit gives you a hint about network (plus 5-series / 2-series for MC)
<Ian> ...but with tokenization it's become more complex
<Ian> ...so even in the physical world the first thing the terminal may have to do is figure out what card product it is and then potentially present UI to the user.
<Ian> ...I think MattS is right here...having this as optional in Basic Card (for population by handlers) is the right approach
<Ian> MattS: We could leave this out in v1
<Ian> ...I think we should do that
<Ian> ...but I think we should make it optional today to avoid divergence
<Ian> ...and then once we get more experience take it out or adjust it
<Ian> AdrianHB_: I think that one way to think about this is that the output data aligns with the input data.
<Ian> IJ: The Credit Transfer and Tokenized Card Payment specs have a "this enum value was selected" field in the response
<Ian> David: In the US, the merchant / not consumer's decision about routing.
<Ian> AdrianHB: Note that the data should be neutral; what the merchant does with it may vary by regulation
<Ian> Ian: It is my expectation the user would not be presented with a choice in some contexts; the merchant makes a decision on how to use the data
<Ian> AdrianHB_: But you don't want merchants to do things inconsistent with user expectation
<Ian> Anthonyvd: The payment handler gives the user the choice
<Ian> ...the sticky question is none of the parties knows what will happen but the user has to be presented with a choice
<zkoch> Given this complexity, it feels like this goes squarely into the "merchant needs to do something special" category. IF Payment Handlers take off and this becomes a thing, we can add it then. It's fairly simple.
<Ian> ....and the merchant deals with it
<Ian> AdrianHB_: Where we are getting to in API is difference between "selectedNetwork" and "allowing the user a choice of network"
<Ian> MattS: We could provide for a ignoredFields option in PR API
<Ian> ...so that browser does not collect data
<Ian> ...I still think today we should add MAY to basic card and in v2 add ignoredFields
<Ian> marcosc: I think we should refrain from adding fields until need is clearer
<Ian> zkoch: I think where merchant choice is concerned, we should allow them to deal with it. If payment handlers take off, and there is a need, we can easily add it.
<Ian> ...right now it is raising more questions than answers.
<Ian> ...merchants will recognize when it needs to do something and other providers likely to step in to offer service
<Ian> AdrianHB_: I agree it's not as simple as adding optional response fields. I think we need further study on impact
<Ian> NickTR: I think it's fine to proceed without adding today, but I think MattS is correct that maybe what will happen is that owners of payment methods will write their own specs
<Ian> ...but that may not be such a bad thing
<Ian> ...e.g,. an EU based scheme that has to do this will write their own scheme for that geography
<Ian> ....and that would make me happy
<Ian> MattS: If a merchant says "I accept basic card", people will accept basic card won't be able to accept extended card since we don't have a class system
<Ian> NickTR: the regulation requires that a mechanism exists for the payer to be able to override
<zkoch> ⊙_ʘ
<Ian> ...if you are going to do that in Payment Request, then the handler needs to provide a mechanism for doing it
<Ian> AdrianHB_: I am hearing this is a regional requirement; so should it be in basic card or in a regional scheme?
<Ian> NickTR: I am hearing little appetite to include it in basic card
<Ian> AdrianHB: We might also want to explore what a scheme specific payment method and how it might deal with this
<Ian> marcosc: I propose we close the issue after the FAQ entry is written
<Ian> AdrianHB_: The conclusion is "not for basic card but could be for other payment methods"
<Ian> MattS: I would not support "no v2 for Basic Card" ... we could add optional fields
<AdrianHB_> @MattS +1 not closing the door on a vNext of Basic Card, although I'd love us to find other ways to solve these kinds of issues (e.g. issuer payment handlers or scheme specific payment methods)
<Ian> ACTION: Ian to work with MattS and Vkuntz to write a FAQ question for the developer portal on addressing issue 49
Basic Card Issue 5 - Leave Off Unneeded Information
<Ian> marcosc: When you return a basic card response it includes billing address
<Ian> ...apple pay has a way of redacting fields for privacy reasons
<Ian> ...would be nice for basic card to be more privacy preserving
<Ian> IJ: Is this the merchant saying "I don't want these fields?" (Cf Matt Saxon's previous proposal for ignoredFields, e.g., CVV)
<stpeter> IMHO this is more about the browser putting protections in place for its users, not users or merchants making decisions about what will and will not be revealed.
<Ian> MattS: I think ignoredFields is generic across payment methods
<Ian> IJ: I think that this is still payment method specific since you don't generally have data fields to exclude that are the same across payment methods. This means any exclude instructions would be part of the payment method specific data
<Ian> anthonyvd: What is the advantage of this compared to the merchant ignoring.
<Ian> ...is the use case compliance?
<Ian> vkuntz: VAT is one use case
<Ian> Zkoch: In PR API we don't know the card number; we need to use CVV to unlock it...that's a chrome-specific implementation detail. The user experience argument is difficult ...we'd like to ask the user to provide billing address one time (whatever the user wants)...the privacy argument is compelling...but you've established user consent. You're not offering new details...therefore it seems like a minor thing to focus on. An exception would be digital goods. I think it's fine for us to say that there are certain fields we won't return by default. When we made this decision we looked at a large variety of systems and 99% of the time systems require billing addresses. I think doing something more extreme would be a broken experience for merchants. We don't want mozilla and chrome to offer very different experiences
<Ian> MattS: I think we have a view from the W3C Privacy IG that we should not return the data and we've made a decision to go against that
<Ian> mweksler_: Does returning the CVV always create a burden on merchant?
<Ian> IJ: What kind of burden?
<Ian> mweksler_: Are there cases where you are in an environment where they would not want the cvv?
<Ian> ...they don't want access to the data...I'm not sure this is a thing
<zkoch> I don't think there's a difference here, but also not a PCI expert
<Zakim> AdrianHB_, you wanted to point out inconsistency between the PaymentRequest.PaymentOptions and the lack of granularity in the request on BasicCard
<Ian> AdrianHB_: In payment request API we explicitly indicate what stuff we want in the shipping address.
<Ian> ...we say "I want phone, email address"
<Ian> ...but we don't have the same granularity in basic card
<Ian> ..what if the opposite were true - the merchant says what they want from basic card?
<Ian> zkoch: There were different reasons for this, e.g., digital goods v physical goods
<stpeter> My feedback is: our user research at Mozilla indicates that users are quite leery about exposing more sensitive information like their phone number. If they know the phone number is needed for shipping purposes they're more accepting. Gathering this data (or exposing data that's really not required) will legitimately raise privacy concerns among a broad swath of users - especially these days.
<stpeter> Further feedback: I'll also note that there's no method by which the merchant can specify why any given field is being requested (e.g., "we need your phone number to contact you if there are any problems with delivery"). For some users, being asked for phone number without a legitimate or putative need might be a cause of shopping cart abandonment. This would be worth researching with users.
<Ian> zkoch: What is the core problem we are trying to solve?
<Ian> marcosc: For Mozilla it's a privacy's issue.
<Ian> AdrianHB_: I interpret it differently - if you send back a billing address, why send a phone number?
<Ian> zkoch: If that's the problem, we can address that.
<Ian> marcosc: We could walk back what we respond with in basic card for billing
<Ian> ...and make recommendations for user agents
<Ian> ...so then the question is...is there any reason to send back the other data?
<Ian> AdrianHB_: my proposal would be to do it consistent with shippingAddress.
<Ian> zkoch: I don't think it applies in the same way
<Ian> zkoch: Phone and address are not sent back in the same dictionary
<Ian> ...a purchaser phone could be different from shipping address phone
<Ian> zkoch: What does Apple do?
<Ian> estes_: We have additional details to enable the merchant to request billing address. We did this for privacy.
<Ian> giulio: We tell merchants to only request what's needed
<Ian> zkoch: I would argue that Apple Pay demonstrates what we wanted to happen - payment method has particular needs
<Ian> zkoch: I think we can strip phone number by default
<Ian> marcosc: but there are cases where you may need the phone number
<Ian> AdrianHB_: I propose we take this in two phases (1) default to exclude phone and (2) propose API changes to allow return of phone number
<Ian> ...so the default is the same dictionary but phone is empty, and down the line you allow explicit requesting of phone
<Ian> zkoch: I think chrome can strip phone if that would make people happen
<Ian> [Marcos writes the proposal in github]
<Ian> MattS: Today shipping address is in PR API and billing address is in basic card.
<Ian> ...yet I think billing address is required for most if not all payment methods and elevating it to PR API would be useful
<Ian> vkuntz: VAT needs to be adapted in EU based on billing address
<Ian> ...there's a different VAT that's applied e.g., in Germany or Belgium, independent of payment method
<Ian> marcosc: What we need is a way of constructing objects that can represent a billing address.
<Ian> ...we don't have a payment address constructor yet
<Ian> MattS: To be clear, this is handled in checkout flow before PR API...they still need to capture it before PR API
<Ian> ...and the merchant needs to decide whether to capture up front, and decide what to do if they get a different address through PR API
<Ian> AdrianHB_: I think this makes sense from a business perspective; not sure what the implementation cost is.
<Ian> AdrianHB_: Who is open to elevating billingAddress to PR API?
<AdrianHB_> [zach ponders]
<Ian> marcosc: In Apple Pay where does billing address come in? When do you need it?
<Ian> ..seems to need to shift to payment request
<Ian> zkoch: You would need an onbillingaddresschange event; not specific to cards
<Ian> NickTR: So the question is whether we include in v1 or this moves to PR API in v2
<Ian> AdrianHB_: While additive, it still requires merchants to look for data in another place
<Ian> ...that may not be a bad thing
<Ian> vkuntz: Another use case - sanction screening
<Ian> AdrianHB_: I think we have a concrete business motivation...
<Ian> marcosc: How many merchants would be impacted by this?
<Ian> MattS: Why is this new? It's just moving it?
<Ian> ...you want to change this before moving to REC.
<Ian> ...merchants will have to deal with two versions of the API
<Ian> ...the more successful we are, the bigger the problem gets over time
<Ian> ...I think the right way to change this is before PR
<Ian> anthonyvd: is it always the case that billing address of credit card is used to compute VAT?
<Ian> NickTR: VAT is computed from shipping address.
<Ian> anthonyvd: I don't think it's as simple as removing from basic card. Suppose I have a Canadian credit card and move to the UK
<Ian> NickTR: It has to do with where the invoice goes (which remains Canada not the UK in your example)
<Ian> Giulio: I don't think it always works that way
<Ian> NickTR: But that's the regulatory environment in which EU operates
<Ian> MattS: It's bound to the credential.
<Ian> NickTR: If you move and don't change your billing address...that may be an issue for you
<Ian> Dave: The same user could have multiple billing addresses.
<Ian> AdrianHB_: If the address is bounds to the instrument, maybe it does not belong to PR API
<Ian> MattS: I think we have a consistent dictionary, but the details might vary by payment method
<Ian> MattS: When I change billing address without changing payment method, is an event fired?
<Ian> zkoch: Right now no event is fired. Maybe the way to address this through onpaymentmethodchange event
<Ian> ....this would work for basic card in the browser but not URL-based payment methods
<Ian> ...I don't know how to build this UI to a user in a way that makes sense
<Ian> ...in the current world it just kind of happens
<Ian> AdrianHB : But if the user changes billing address, that data needs to get back to merchant
<Ian> zkoch: What we said before was that this was a problem for merchants to solve
<Ian> IJ: Could retry() be useful here?
<Ian> zkoch: that's not a bad proposal
<Ian> ...we can think about retry() and onpaymentmethodchange and see if we can solve those together
<Ian> ...we might be able to solve the use case without the UI complexity
<Ian> MattS: I think that this approach would address some use cases but not all the ones I had in mind.
<Ian> ...if we could define an address usable across payment methods, that would also be satisfactory
<Ian> marcosc: I am working separately on the elevating of the object
<Ian> MattS: If we decide that the dictionary is the right approach, anybody can use in their payment method, and that doesn't break in v2
Editor's Note: It seems there are two actions to address this topic: explore whether a retry() method is useful and define a general purpose address constructor that could be used across payment method specifications.
Editor's Note: The essence of the discussion was that we are still working on Basic Card topics, and thus it is too soon to discuss publishing Basic Card as a Note.
<Ian> [Lunch]
<scribe> scribe: nicktr
<Ian> [Demos by Anthony]
<Ian> Anthony: We use a fictitious BobPay payment method
<Ian> ...it's a sort of wallet where you can pay with both basic card and also the BobPay payment method...this is all web-based
anthony: here I am using bobpay
ian: I note that the Bobpay content appears in a modal window, just like the "native" implementation
zach: colour is set against the payment handler
marcos: what's in the details?
anothony: dev stuff
... demos bob pay
... payment handler is responsible for crafting response
anthony: now to "just in time" handlers
ian: Chrome's implementation of "just-in-time" registration of payment handlers leverages the payment method manifest specification, essentially creating a new distribution channel for payment handlers as part of the checkout flow.
sachin: Can a payment method have multiple handlers?
zach: Yes. The Payment Method owner determines which payment handlers are authorized to service the payment method. The Payment Method Manifest lists the authorized payment handlers.
sachin: If you have different payment methods which don't have a default install, how does the browser react?
anthony: This is only supported for URL-based payment method
zach: But the user can go to individual sites to install service workers for W3C-defined payment methods (identified with short strings).
<asolove> * sure
<Ian> anthonyvd: Currently for the user there is no diff between "already installed" and "not yet installed" in the display of matching handlers. That's because installation is transparent to the user
nicktr: Is this available in the current chrome canary release?
<Ian> anthonyvd: Yes
<Ian> IJ: Where is it documented what flags to set in Canary to make this work?
<Ian> anthonyvd: There is no documentation outside the list of flags. Look for flags that have "payment" in them. We don't document flags but it's web payments and payment service workers currently
<Ian> Harjender: How is the user identified?
<Ian> anthonyvd: Chrome is not doing anything, but the Web site can identify the user
<Ian> Giulio: Is there a list of *Pays that are ready to implement payment handler?
<Ian> IJ: A number of companies expressed interest at our face-to-face meeting in Chicago last March: Mozilla, Worldpay, Ripple, Gemalto, Digital Bazaar, Facebook, and Klarna. Since then we have heard additional expressions of interest from Amex and Mastercard, and I have spoken with other organizations as well.
<Ian> AdrianHB: Payment handlers can close the loop between issuer and acquirer
ian: Another use case from Capital One where they generate a unique card number by domain. Capital One's payment handler could support 'basic-card' and return (non-static) PAN information. This is an illustration of payment handler innovation that would require no change on the merchant integration side (other than to support 'basic-card' in the first place.
ian: Payment handlers are also useful for URL-based payment methods, where browsers may not yet implement the payment method in the browser.
ian: When you install new handler, my expectation
is that the handler supplier (e.g. your bank) will authenticate
you
... and this could use web authentication
... I have chatted with Berlin group and web authentication
about a possible prototype
anthony: here's a video - with
the authentication flow
... use case is payment handler with authentication
... authentication is by fingerprint on android
<Ian> [Demo of adding WebAuthn to the mix]
<Ian> AdrianHB: What will the UI look like if you don't call openWindow?
<Ian> ...one use case we envision is that the payment handler calls a remote service that does a push to your phone where you auth to your phone
<Ian> ....what happens in the UI in that case?
<Ian> anthonyvd: PR API on desktop would show you a spinner in the modal
<Ian> ...the really smooth part would be this - if you have just one payment handler installed, chrome will do the skip UI call
<Ian> ....if the merchant doesn't address a shipping address etc and requests payment from a URL-based payment method, and they just accept that one, and we know the handler, then we don't show the sheet; we just show the payment handler
<Ian> ...that's a very specific use case, and requires some coordination, but it's the smoothest user experience that we can envision
<Ian> ...e.g., if merchant just accepts Google Pay, they just declare that support through PR API...and the service worker can finish the request without showing UI
<Ian> ...and you can know this through canMakePayment()
<Ian> ...plus the flow smoothly degenerates
<Ian> estes: How does the payment method owner authorize payment apps?
<Ian> Ian: Payment method manifests
<Ian> Edenchuang: How does the browser find the name/icon?
<Ian> Ian: Web app manifest
ian: Payment method manifest is used to authorize domains to distribute payment handlers. Web App Manifest is a more general specification (published by the Web Platform Working Group) that allows domains to describe artifacts associated with the domain, such as a name, logo, theme color, background color, etc. The Web App Manifest specification makes it easier for browsers to provide developers with the means to create user experiences for Web apps that compare with native apps.
<Zakim> nicktr, you wanted to note merchants, security and current experiments and to say web app manifest spec in IRC above
<Ian> nicktr: Somebody asked about whether the domain would be merchants...I think that some merchants will distribute their own payment handlers (and have their own payment methods)
<Ian> ....I'm very keen on this approach generally since it gives more security about payment handlers...you can put these authentication pieces together
<Ian> ...Worldpay has been experimenting with payment handler API + web authentication
<Ian> ...and microsoft hello
<Ian> SachinAhuja: I think it would be better for users to see instruments rather than just handlers
<Ian> anthonyvd: That was a conscious design decision
<Ian> zkoch: It complicates the UI to a considerable degree....
<Ian> ...we have a userHint field in Payment Handler API
<Ian> ...that can be used e.g., to give users more hints about what they will find
<Ian> ....we prefer to get experience and see what payment handler implementers want
<Ian> IJ: We've heard Mozilla say that they might experiment with showing instruments on desktop
<Ian> marcosc: Personally I would rather not show instruments
<Ian> ...we are also not convinced we want to show web content
<Ian> ....if we show web content, then instruments can go away
<Ian> ....they can be handled by the payment handler
<Ian> AdrianHB: The API is designed so that there are methods, instruments, and handlers, and those are separately defined
<Ian> ...those exists as data that the browser has available, and the browser UI can make use of it however it wants
<ian:> Ian: It would be nice to know if we're going to get more support for payment handler API from other browsers (Chrome, Samsung, and Mozilla have expressed interest; still want to hear from Microsoft and Apple)
<Ian> I put together a slide deck on payment handlers that shows changes since TPAC, some key issues that will be discussed in the breakout on payment handlers tomorrow, and other topics that we don't have time to cover right now.
<Ian> NickTR: I think Payment Handler has seen the most development since TPAC
<Ian> [Time for breakouts: 3DS in the same room; Payment Request API Editors elsewhere]
<Ian> Ian's slide deck summarizing 3DS opportunities
<AdrianHB> MattS: Additional con to opportunity 2: JS is updated more regularly than browser
<asolove> And updated by different parties! In the current spec, each issuer can experiment with collecting different data. Issuers might not like the one, unchanging set of data browsers want to send them.
<AdrianHB> SachinAhuja: If this works it's great but doesn't preclude 3DS2 as specified
<AdrianHB> Ian: Correct
<AdrianHB> MattS: PSD2 requires the acquirer to also do Strong Customer Authentication (SCA) sometimes
<AdrianHB> ... could complicate the flow if we use issuer PaymentHandler
<AdrianHB> Ian: The data being exchanged is still TBD so we may need to dive into the details of the flows
<AdrianHB> MattS: This is a complex exchange, not to be underestimated
<asolove> I think this proposal is the browser implementing the "3DS Requestor UI", which is an existing slot in the spec. It would require EMVCo certification.
<AdrianHB> NickTR: Can the browser provide the data required to get a risk analysis?
<AdrianHB> Ian: Not all of it but they could at a minimum submit data about the user to the risk analysis systems and pass the result back to the merchant
<asolove> I want to be clear that I think this is slightly different than what I suggested :) We need a fresh auth per-transaction for SCA.
<asolove> Ah, indeed.
<Zakim> AdrianHB, you wanted to ask how this differs from issuer payment handler?
<AdrianHB> Ian: Not clear if this would be very different.
<AdrianHB> AdrianHB: Could we get browsers to explicitly favour issuer handler over stored card where possible?
<AdrianHB> Ian: I believe Chrome do this already through ordering of instruments
<asolove> The motivation here is if browsers are uncomfortable loading the 3ds2 method_url, this gives us another way to let issuers do fingerprinting.
<AdrianHB> dave-tch: What does the network do in this case?
<AdrianHB> ian: this is an optimization where the payment handler is distributed by the network instead of the issuer
<AdrianHB> giulio: in a world where the issuers sign up en masse would the merchant have to explicitly name them all?
<AdrianHB> ian: no this is abstracted away behind basic-card
<AdrianHB> giulio: if an issuer implements payment handler, how does it get into the ecosystem
<AdrianHB> ian: 1. user visits the website of the issuer and they install it
<AdrianHB> ... 2. Just-in-time (JIT) install could help but it is not for basic-card
<AdrianHB> isaac: does the use of an issuer payment handler mean liabiltiy has shifted
<AdrianHB> ian: depends on the deployment
<Zakim> AdrianHB, you wanted to propose that EMVCo provide a psuedo-payment-method manifest for basic card that maps BINs to issuer origins?
<AdrianHB> AdrianHB: Can we leverage the 3DS directory service to allow browsers to lookup issuer payment handlers using the PAN/BIN of the cards they have on file
<AdrianHB> Roy: Are there any payment handlers doing basic-card?
<AdrianHB> Ian: Yes there are some
<AdrianHB> dave-tch: I think issuers would take issue with networks being responsible for authentication?
<AdrianHB> ian: that is true but we are also trying to solve a distribution problem
<AdrianHB> ... this is not an attempt to take auth away from issuers
<AdrianHB> dave-tch: using an open standard, where a large issuer wants to solve this alone they should be allowed to and a smaller issuer may leverage tools from networks
<AdrianHB> ian: yes, these opportunities are not mutually exclusive
<asolove> For most merchants, JavaScript-free won't work because the PAN entry needs to be on a different origin to avoid PCI issues
[Ian finishes his presentation. Brian Piel starts his (remotely); see Brian Piel slides]
<Ian> Brian: We'd like to pull 3ds together with PR API to get a streamlined user experience
<Ian> ...why 3DS2? higher approval rates, reduced fraud, better user experience
<Ian> Brian: Some caveats:(1) merchants must enroll in 3ds (2) merchants have specific data to share (3) payment handler should provide 3ds client functions as defined in 3DS2
<Ian> ...merchants need to be able to say "This needs to be a 3ds2 transaction" (not the consumer)
<Ian> ...the first functionality is to provide data for frictionless flow
<Ian> ...the second is to provide the challenge UI
<Ian> [Slide 5- browser native support for 3DS2 flows]
<Ian> Brian: In this flow, the merchant sends an endpoint to the browser, which does a POST to the issuer's backend
<Ian> ...data is then returned to the merchant which does the actual 3DS call
<Ian> ...what the browser did was gather data by talking to the issuing bank
<Ian> https://vimeo.com/264986694/bf996bbc41
<Ian> challenge flow vid => https://vimeo.com/264983767/0aef50759d
<Ian> Brian: The UX is standardized
<Zakim> asolove, you wanted to ask who implements the last step in that demo that shows the challenge modal? Is the proposal that the browser do so, or a specific payment handler?
<Ian> asolove: Is the proposal that the browser controls the UI and showing the challenge page?
<Ian> ...or that there's a payment handler that opens the UI?
<Ian> ...or the merchant site is responsible for opening the window?
<Ian> Brian: It's a frame that's opened. It could be the merchant opening the window before calling complete()
<Ian> Asolove: what is being proposed here for PR API integration?
<Ian> ...is the idea that the browser is responsible for showing the window?
<Ian> ...or that the browser returns a payload to open the iframe?
<Ian> Brian: The proposal is that the browser would initiate the flows and render in browser UX
<Ian> Brian: There are also payment app versions of this
<Ian> ...in these flows there is less for the browser to do
<Ian> https://vimeo.com/264654981/0e0484b390
<Ian> MattS: I have seen "browser initiates" and "native payment app"...but have not seen web-based payment apps.
<Ian> ....is anything preventing web-based payment apps from doing this?
<Ian> Brian: I don't think there's anything that would prevent a web app from doing this
<Ian> [Slide 9]
<Ian> Brian: One thing for consideration....there are native app flows and browser flows that are different but the data is common
<Ian> ...the requirements for the challenges are different
<Ian> ...within a native app, the challenge is fully data-driven...the SDKs are standardized and the UI is managed by the SDK
<Ian> ...JSON data element driven UX
<Ian> ...browsers could leverage the data elements for their native UXZ
<asolove> what was the question? can barely hear
<Ian> NickTR: Does anybody have prototype of web-based payment handler that is doing 3ds2 flows?
<Ian> asolove: You could easily to a prototype with an iframe, but you can't do the interesting point yet with the current specs
<Ian> nicktr: Why can't endpoints be available to a native web app?
<Ian> ...what I'd like to see is the 3ds flow with a web-based payment handler
<asolove> 3ds2 endpoints aren't currently available to anyone
<AdrianHB> What exactly is not available? The specs or a test environment?
<Ian> Rick: We don't have the endpoints yet
<Ian> MattS: I've seen four videos; are those "real" or just mockups?
<asolove> Test environment
<Ian> AdrianHB: There's no publicly available test environment
<Ian> Sachin: These are mockups
<Ian> ...if there is interest the next step would be "real" (in a test environment)
<Ian> Ken: Amex is interested in web-based payment handlers helping with the integration of 3ds2 into PR API
Editor's Note: The plan had originally been for the 3DS breakout to prioritize a set of opportunities for discussion with the browser vendors (and others who attended the PR API Editor breakout session in parallel). However, we ran out of time and so postponed the "discussion with browser vendors" to a breakout session tomorrow. See the report from the second 3DS breakout.