Web Payments WG FTF

23 Mar 2017


See also: 24 March minutes · group photos · IRC log


AdrianHB, Alan, CyrilV, DickHardt, Frank, Guy, Ian, Ken, Kris, Li_lin, MattMiller, MattS, Max, Rouslan, Roy, Stoyan, Tommy, adamr, dezell, jeanyves, jeff, ltoth, manu, marcos, mathieu, mattSaxon, michel_cc, michelw, mike_mastercard, molly, mweksler, nicks, nicktr, oyiptong, padler, schuki, todd, todd_a, zkoch, AlanSamsungPay, jiajia, ketels, Katie_Haritos-Shea, DavidM_GSMA, fdold, matt_miller, vkuntz, Mahesh
ian, manu


  1. Welcome
  2. Update from the payment request API editors
  3. Implementer updates
  4. Demos
  5. EMVCO Update
  6. Payment Apps Update
  7. Review of Day One Issues


[Nick welcome + invitations]

Nick: Goals for the next two days - understand whether we are ready to request PR API, PMI ready to move to CR
... and also whether payment handler API ready for FPWD
... and also advance payment method specs

IJ: I will review the process bits on Friday. Goal is to understand what the todo list is before launching the call for consensus
... which will last 7 days

Update from the payment request API editors

Zach presentation

zkoch: I am a fast talker.
... Since we last met:

- marcos joined as an editor, domenic also joined as an editor

- cheers for adrian bateman

- merged 65 pull requests

scribe: they did not fundamentally change the shape of the API

<scribe> ...closed around 100 issues

[Biggest changes]

scribe: one of the first breaking changes in a while was made yesterday - updateWith now returns a promise that can be rejected.
... it used to be that we failed silently if weird things happened (e.g., negative totals)
... we shipped a fix where a promise can be returned that can be rejected after validation
... did not have an impact on merchants already using the API.
... we added "id" for push payments
... help with reconciliation
... one of the biggest new functions was the addition of canMakePayment()
... discussion was about how to balance merchant desire to create good UX with privacy
... the canMakePayment() function returns true if there is an active payment instrument available.
... and in the spec we suggest that UAs mitigate the privacy concern. ... google's implementation does rate limiting
... I think that CR will inform our implementation choice, and we can revisit it

AdrianHB_: Do you see that becoming deprecated in the long run?

zkoch: No.

alyver: There is value in canMakePayment() because the merchant may wish to know whether the method that returns the most value is available

zkoch: (Continuing)
... for iFrame support we added allowpaymentrequest attribute
... trying to be forwards-compatible as well
... lots of editorial changes to the spec, removing ambiguity, etc.
... Boris from Mozilla raised a bunch of valuable issues; and Domenic and Marcos have been knocking them out

[Getting to CR]

zkoch: I'd like to review the issues that the editors feel are the most important to address. Also want to hear if you have some
... we have a CR milestone

[Issue 462]

zkoch: This is on multiple PRs at once; not a big issue but it is open

[Issue 360]

zkoch: What should happen during navigation away....
... e.g., window closes down, or a navigate event
... we think we have an answer in the discussion on the issue itself...just awaiting some clarification
... so we are far along on this one

[Issue 327]

zkoch: This is an I18N issue; we are waiting on Marcos

Marcos: It's both RTL and language of labels.
... we are going to push that back to WebIDL...we created an object that all APIs can use

[Issue 309]

Multiple modifiers behavior

zkoch: We have this thing paymentMethodModifiers...you can alter the price or line items on a payment method specific basis
... we need to clarify what happens when there are more than one
... either first one wins or throw an error
... we just need to be explicit in the spec

[Issue 464]

zkoch: supported methods as enums or URLs

IJ: About matching semantics

marcos: It's a minor issue; just needs to be fixed

zkoch: We also have some editorial issues (439)

[Issue 229]

zkoch: On guidance text regarding user consent
... what should we say about user consent....(AdamR issue)
... the issue is "what does it mean to grant user consent"
... One view is that the spec says consent is necessary, but now how it's granted
... we can't be overly authoritative on how
... part of the question in this issue is how much guidance do we give.
... other than 229, I think the editors are clear on how to resolve the other issues

[Zach shows currently language; question is whether sufficient or whether more needs to be said]

MattS: One of the issues that I raised relates to this issue. I raised an issue about "interaction." The spec is written in a sense that assumes some human interaction.
... it is my understanding that consent can be granted beforehand. And a call to show() could return data without user interaction.

Marcos: I agree with Matt's view that prior consent can be granted without requiring user action on every transaction

zkoch: I agree that the spec might not need to constrain "must have an interaction"; ok to review the spec to ensure that's the case.
... how it works in practice is a separate matter.

Ryladog_: Regarding consent; jurisdictions may affect what is required
... data protection requirements may vary by jurisdiction

adamR: Mostly I wanted to say I agree with MattS that we allow the streamlined payment in order to be competitive with one-click card on file experiences
... I think the spec should call out the use case

Marcos: Yes, we can add an informative note describing the use case

NickS: But the spec should not mandate it

zkoch: Ok, I've added it

padler: Some services require reporting as part of transactions. Might be interesting for merchants to specify the jurisdictions they are bound by and data would be affected by jurisdiction

AdrianHB: Interesting requirement but a new one

padler: Might be an additional hook

zkoch: You can file as an issue and we'll mark it as non-CR blocking

<scribe> [Pending pull requests]

[468 is minor]

[455 is about I18N]

Marcos: I need to do the work on 455; not much to do

[450 on accessibility]

marcos: The proposed text is overly generic
... I think as we gain implementation experience, we will see issues come up
... implementations are already pretty accessible; I think we need to be able to identify what the key things are; those things will emerge naturally as we gain implementation experience.
... and we don't need generic statements

mattS: I am not sure that the matching algorithm is detailed enough.
... so I would like to review that
... do implementers think they can implement the spec consistently?

AdrianHB: I have an action to call out in the spec (with next text) to say that payment handler will be used for the extension point

IJ: I agree with Marcos re: accessibility. My proposal is that we not include generic text. Instead, we should consider the mapping proposal separately (from Chaals) but ensue it is non-blocking for CR. We will also put practical info on the developer portal to help developers do things the right way ito security, regulations and accessibility. I think the developer portal is the place to put practice guidance. Please join the merchant adoption task force to help us work through practical guidance (e.g., about accessibility).

zkoch: The question is "what is useful"

IJ: There is no expectation IMO that we must make generic statements. Concrete requirements have value. Otherwise, guidance should go in the developer portal

MattS: have we made enough progress in payment apps to determine stability of PR API?

Ian: That's my presentation tomorrow; I believe the answer is "we don't have any breaking changes"

zkoch: Most of our changes to date have been small changes; I have gone over the big changes so far in my presentation.

MattS: When I read the spec, lots of the language is pull-payment centric

marcos: Going to CR is an important milestone but it's not the end of the world. :)
... We can freeze PR API and then layer (v 1.1) based on experience
... we can get very interoperable over the next year while we work out payment handler
... I like the layered approach
... I am hopeful that that is the approach we take

Ken: Regulatory activity is increasing globally.
... e.g., in Hong Kong, payment schemes for users in HK, or when the merchant is in HK, that data has to stay in HK
... they haven't yet addressed cross-border payments
... unlike PCI (a minimum threshold), there is no group looking at minimum for data protection
... I think it will be challenging to say anything else other than in a developer portal

manu: This is not an argument against CR, but I think it's naive to layer on PR API. We don't have experience with implementation of payment handler
... we might want to get some implementation of payment handlers (even with polyfills)
... I do not think that should block us from getting to CR

Marcos: I expect we'll sit in CR a year or two

NickTR: This session is to bring people up to speed...we have a good chunk of time tomorrow afternoon to sew all this together

<jean-yves> In addition to Ken's remark, FYI such a regulation, compelling to keep data locally, is on the way for several african countries, under decision of African central banks

rouslan: I think we can go to CR and have a living spec

AdamR: If we go to CR, I don't want that to be a reason not to make changes based on payment handler experience
... I am most concerned is that we will end up a spec that is incompatible with how we implement payment handlers

zkoch: We have a number of other editorial issues we consider non-blockers; feel free to tell me if you think differently

Marcos: Contributions welcome
... and getting help to close issues will speed us up

VAT Address Collection

zkoch: Editors were asked to figure out how manage digital goods price changes (for VAT)
... Roy (Facebook) is going to look into this more in detail
... the issue is without an address, you can't determine the total
... it can be dealt with by merchant by asking for billing address up front
... WG said "we think this is important"
... the Editors concluded after review that we are not going to try to get this in right now
... there needs to be a lot more spec work to make this possible
... there's no longer a shipping component, which means we need to clarify the behavior
... FB is most interested in this, and propose how we alter the spec

<manu> Ian: One observation is that the new W3C process would allow, if in six months, there are implementations starting to do this, and we can add that to spec, it's easier to revise a CR under the new W3C Process. So rather than say for this particular issue "v2" let's wait to see what we have in a few months and choose the best process for integrating the feature.

zkoch: from a payment request perspective, the merchant can update shipping options which allows price update (based on events) before user pays
... shipping is optional, you can do outofband data gathering as needed

Alan: I have another cross-border issue - I raised this last night at dinner. The payment manifest file does not appear to have good support for instantiating a market or country specific application

zkoch: Tomorrow we'll discuss the payment method manifest spec...we can add that to tomorrow's agenda

zkoch: Did I miss anything?

In-Store Pickup

marcos: What happened to store pickup?

zkoch: We have request shipping (a boolean). We added the notion of a shipping type...it basically updates the label in the UI
... one does not ship a pizza. You deliver a pizza
... we left out "store pickup"
... as an example, consider a hardware store that allows store pickup
... one challenge is that this chain could have store locations around the country
... flows get more complicated than what we have affordance for
... so for the moment we have punted....
... we recognize that it's a feature merchants might want...but it's complex, and it does not make sense to push into shippingOptions
... would not be good for the UX
... we don't have a huge demand for this, so we've decided for now to punt on it
... I realize Apple has store pick up and NickS can tell us about their experience

NickS: It's tied up in our UI. Shipping method and shipping fields are two things
... in our UX it can be made to make sense
... not many people use our feature; I'm ok if we leave it out for CR

<Zakim> nicktr, you wanted to note British English/American English diff

nick: You wouldn't talk about shipping address in en-uk
... I get that there's a semantic difference here

<GuyB> Have the opinions of the big box retailers, walmart and costco been considered on the store pickup? The primary online merchants are not the right audience to ask about this

Nick: I think the language in the spec should speak to the difference

<Zakim> MaheshK, you wanted to provide merchant feedback on store pickup

MaheshK: our experience - when user chooses store pickup, the user should pick the store
... for some merchants, people can do store pickup for some items in the cart and some items in store

<GuyB> It also is a growing method for restaurants

zkoch: So I am proposing we punt on the following topics (1) VAT (2) in store pickup

AdrianHB_: I think that people who want us to support the use case would help us most by making a concrete proposal.
... even while we are here

Payment Method Identifiers

zkoch: In general there has been less work on these; I think we have less work to do on both of them. They are much much simpler
... PMIs are short strings (W3C) or URLs
... We have some editorial fixes to make

[Issue 8 on equivalence]

<manu> Ian: What does "handle failure" mean?

Marcos: Fetch mechanics

Ian: We need to review the dependencies

[Issue 26 - link to registry of short names]

zkoch: Ian proposes we link to a W3C page with the list of short string PMIs published by the WPWG.

marcos: Let's include them dynamically in an informative note

Ian: +1
... I am aware that there is some disagreement about what short strings should go in the identifier list

nickTR: I think the short strings are a hack; I still think we should use URLs

Basic Card

<manu> Ian: What is the reluctance with supported types?

zkoch: Note that supportedTypes may be difficult to implement in practice (by payment apps)

<GuyB> Does PR API allow for the potential of merchant routing choice in case that carries over to the web in the U.S.?

<Ian> No.

Payment Method Specs as Recs or Notes?

<manu> Ian: I had intended to raise this as a spec bug, but I'm hearing that people may want to reopen the discussion. Come back to me while I dig up the history.

Implementer updates

Chrome on Android

rouslan: We are working on third party payment app integration

adrianHB: Where would you show the origin if payment request originates from an iframe?

Rouslan: We have talked to security team, and one option is to show top-level origin AND iframe origin
... we are not sure what the value is to the user of seeing the iframe origin

marcos: how do you prevent forgery?

rouslan: Safe browsing initiative.
... user can override, but currently payment will not work if overridden

zkoch: Very hard to make an unspoofable UI in mobile...we accept that and have other mitigations in place
... users not aware of differences

Chrome on IOS

rouslan: We have an early IOS implementation; no flags; you need to do a build

nicktr: Can you used third party web-based payment apps with canary yet?

Rouslan: You can do it on android with android native payment apps
... if you flip a flag
... you cannot do anything sensible yet on web-based payments

AdrianHB_: There is also Tommy Thorsen's modified Chromium build. (Editor's note: We refer to "Tommy's build" multiple times during the meeting.)

<Zakim> nicktr, you wanted to ask about third party payment handlers in Cananry

<Zakim> manu, you wanted to ask about how Web Payment apps are expected to be displayed.

Manu: What is the experience anticipated for web apps?

Rouslan: Web app will define one or more instruments

zkoch: We are working on concepts

Manu: We used a polyfill looks like what rouslan has
... but the "danger" is whether you add credentials into a spoofed window

Rouslan: Safe browsing initiative should help us out as well with spoofing issues

Mahesh: Your desktop UI did not ask for CVV.

Rouslan: I didn't show that in the demo, but it does ask for CVV.

Mahesh: For the IOS...the view?

Rouslan: Objective C native interface
... we have a fullscreen overlay that hides everything when you are making your payment

zkoch: There are strange things that happen with polyfills....

scribe: we are trying to work through it but may need to limit at the beginning

florian: What about click jacking protection?

rouslan: Not part of the spec, but something we are looking at. We use 400-500ms delay as an example. What do you think?

Florian: Page can be in the background.
... so it needs to be a "delay while the window is in focus"

rouslan: Makes sense

florian: What prevents merchant JS from clicking the button

rouslan: It's objective C; merchant cannot access it
... One thing that's interesting in IOS is that it's completely accessible ... so we don't trust the JS...we inject into objective C and validate there
... merchant doesn't have access there so we trust it more

IJ: Florian, how would the merchant's ability to push a button from code differ from what can be done today?

Florian: Risk goes up if it's a one-click process

Rouslan: There's definitely a trade-off

zkoch: Right now in Chrome, you can't end up in this scenario
... if a payment app goes down the route of 1-click or no-click, this is a risk that you assume.
... I think to go to a UI-less payment flow exposes you to this vulnerability, but you are forced into the UI.

Florian: My concern is tricking the user into clicking

Zkoch: We talked about this in our issue about deconstruction. I think our proposals mitigate this risk; please check out the issue

oyiptong: Can you show me the flags that you need to show for desktop

<zkoch> chrome://flags

<zkoch> Experimental web platform features

<zkoch> Web Payments

<Zakim> manu, you wanted to ask if the "polyfill" is only for native payment apps right now.

<zkoch> (you can’t link to chrome:// pages, so you’ll have to type in manually)

manu: You said there's an objective C polyfill....

Rouslan: The polyfill is JS that calls into Objective C on IOS
... there are no native payment apps in IOS

zkoch: We only do stored cards for Chrome on IOS

Max: Do you implement canMakePayment()?

rouslan: Yes

world deployments, at times the user installs Alipay as an android app, and sometimes they don't

scribe: when the user installed Alipay we want the API to invoke it
... if the user doesn't install Alipay, we want browser to use Web app

Rouslan: Doesn't work currently but a great implementation idea

[From the trenches]

Rouslan: There have been questions about adding new card network identifiers
... questions - should we distinguish global from country-specific?
... how to reduce friction?

Rouslan: Chrome security team may push back on arbitrary string matching
... but the preference is to strictly parse and when doesn't match a known string we throw it away
... so right now people need to do a pull request on chromium project.

adamR: Can you be more confident with a regexp?

Rouslan: No, more of an enum.
... restrictions are a point in your favor, e.g., max length no numbers, etc....we might do that.

IJ: This is the first time we've heard that "there might be a way"

Rouslan: Web payment app spec is in flux; please join the task force!

IJ: +1 to get involved in the task force.

<nicktr> +1

Rouslan: One thing we have encountered in early versions of payment request API was that it was vague and additional review was valuable
... so we have appreciated the additional details in the spec!
... another point that echoes that is that the spec does not always restrict the shape of data that would make it easier for merchant to communicate with any browser in the world. (e.g., phone number formats)

scribe: I believe we agreed eventually to use an IETF format. I think restrictions like this are very useful for merchant web sites to be sure to get data in the form that they expect

<zkoch> (we’re about halfway through, so just want to make sure that we get to Roy)

IJ: Can you write the spec in a way where there are benefits if you do something one way, but some flexibility

Rouslan: Mozilla proposed that....but we want to push in a particular way

Marcos: It helps to have an agreed to standard, but may be useful to to have the flexibility
... It would be useful to hear back from people on formatting of labels

<nicktr> I don't think that the spec actually specifies the phone number format - can someone point me to where it does?

Marcos: in Mozilla's prototype the "USD" is on the other side of what Google displays
... for additional consistency, it would be helpful to provide guidance to developer on how to display labelos

NickS: Guidance makes sense; would not put requirements in the spec. In some cases you may default to the OS

(IJ adds notes to the dev portal to return to this later: https://github.com/w3c/payment-request-info/wiki/DeveloperGuides)

adamR: If we don't go down the path of phone number normalization, it's a fast path to 'works best with'

Marcos: Challenge is legacy contact apps where that info is being pulled from

AdamR: There is an IETF guidance

Marcos: We point to that in the spec as a SHOULD

NickS: It may be impossible for the browser to make a determination about the format (e.g., if user puts in number without a country code so format unknown)
... we make a best guess

<Zakim> AdrianHB_, you wanted to ask about capturing user data outside this flow and formatting it

AdrianHB_: You clearly want to use a bunch of existing data ... is there a solution where you return the data in a format, with a flag that indicates the format?

<marcosc_> Spec says: "When setting the payerPhone value, the user agent should format the phone number to adhere to [E.164]"

(IJ thinks "mime type")

AdamR: You mostly get that by seeing a "+" at the start of the string

AdrianHB: What about addresses or other data than phones?

AdrianHB_: Does the response indicate the format of the data?

Rouslan: Not yet

Facebook Implementation Experience

Roy: We'll see a demo in a moment
... here's what we have done:
... implement PR API in FB SDK...it overrides the default PR API implementation in the web view
... implements a proprietary FB payment method that does tokenization
... our app can return tokenized cards AND process payments; depends on merchant configuration in our system
... our implementation was fairly smooth
... we moved from our custom API to PR API!
... we are running the test suite as well (and pass all the tests)

nicktr: You said that your implementation can do both pull and push payments

nicktr: Any new needs based on your push implementation experience?

roy: "id" is very useful.
... right now we are not yet doing third party apps

alan: "id" is of interest to payment schemes.
... can "id" be an order number?

roy: I think we have this covered.
... "id" field is part of the details that go to the payment app

AdrianHB: Yes, "id" flows through to payment app

IJ: Yes, that's in the spec (but I see some legacy use of paymentRequestID rather than "id")

Rouslan: Do you support shipping physical goods?

Stoyan: You can ship things
... FB doesn't but merchant can
... Right now implemented on Android and IOS


Facebook Demo

[stoyan shows code; indicates it works end to end]

rouslan: Is there a use case where the FB user cannot make payments?

stoyan: canMakePayment() is more about merchant checking to see whether the FB app supports the API

Roy: there are also some use cases about payments in certain countries

Rouslan: What should merchant do when canMakePayment() returns false?

Stoyan: We fall back to traditional web form for card data
... Even though we have card data, we don't share that with merchants. We only return a token.

Rouslan: Do you have documentation on how to integrate?

Stoyan: Not yet

Roy: We will let you know when it's available.

(IJ asks for the link to documentation when available to dev portal)

nicktr: How does the merchant know they got paid in the push payment case?

Stoyan: In the payment response there's an ID and also an identifier from the processor.
... so, e.g., Stripe gives you an identifier that the merchant can use to poll Stripe for status.

<Zakim> nicktr, you wanted to ask about merchant experience

(IJ thinks this aligns with our previous expectation that the merchant would query the merchant or vice versa and that the payment service provider determines which to do)

zkoch: At some point do you imagine removing FBextensions and moving to PR API?

stoyan: Yes, and I had to do that to pass the W3C tests

zkoch: So it "just works" by payment method identifiers because implementations ignore the ones they don't implement. (Editor's note: The observation here was that by leveraging payment method identifier matching, Web pages and payment apps would selectively matched across (transitional) implementations without disrupting behavior in other user agents.)

Roy: I like Zach's observation that the right thing happens via payment method matching

zkoch: Please use URL for your identifier (rather than a short string).

Ian: +1, please use a URL for the payment method identifier.

NickTR: +1, please use a URL for the payment method identifier.

Stoyan: One note - we had an event called "checkout cancel" in our API; we haven't found a corresponding event in PR API.

Marcos: We have "abort"

Rouslan: Show() promise resolves with an error that you can use; this is a new feature
... Please file an issue if you need a more specific error message

Stoyan: As a merchant you may want to know that you had a thing in a shopping cart and maybe you get a discount if you come back tomorrow after aborting your cart

Marcos: Look at the user abort algorithm

zkoch: I think this is the only situation....

Adrian: There is more than one place where you throw an abort error

zkoch: There is merchant explicit abort and user abort; we can disambiguate between the two

marcos: But a merchant who initiates the abort knows they are doing so.
... so there's really one use case (user abort).

zkoch: So you can know.

nickS: Is the intent that if you were running on a platform that supports payment handler you would support it?
... Is it possible that, e.g., you could do card on file?

Roy: E.g., operating as a card payment supporting app?
... we can't do that in our implementation; we have stronger security requirements; we need the merchant's id

max: who gets the card number?

Roy: merchant only gets token; not raw PAN

katie: Do you have any funds limitations?

Roy: I don't know of any practical limitations

IJ: Fund limitations are not relevant to the API; these can be addressed in payment systems or developer guidance

Todd: +1

AdrianHB: The transaction will just fail (at other parts of the flow)

MattS: Have you looked into race conditions regarding push payments?
... there's a possibility that the merchant can abort payment

Roy: That's where the ID comes in
... so you can use it to reconcile

MattS: Do you want the ability to block abort while processing?

Stoyan: Not in the abort implementation. But there is a message in our implementation.
... Abort or app crash or battery dies are similar use cases

mattS: I think that you should be able to change state to "processing" and block calls to abort() during that time

AdamR: But network could time out

MattS: I can raise an issue and propose something

zkoch: We have a note in the spec that "abort" cannot necessarily be enforced

MattS: I see there is a provision in the spec; probably good to mention this explicitly

AdamR: I am hearing Zach say that this is implementation dependent

roy: I can see it being useful to add a value

AdrianHB: What are the use cases?

NickTR: Question is whether we need a state between "interactive" and "state"...e.g., "processing"

IJ: It's just information, right, not a requirement for a particular use experience?

michel: Larger point - this is a distributed system
... we can't always know what's happening
... trying to abort a payment while it's happening elsewhere; by definition you can't do that AND have a consistent response.
... is there support for idempotency?
... how are retries handled?

AdrianHB_: In my opinion we do support that; abort and show are functions of the payment request. So we can abort the payment request, which tells the browser "give me back control". You have the "id"
... so you can try a new payment request with the same ID and hope that the processor recognizes it as a retry
... but we can't make any promises in the browser that the PSP supports idempotency
... so we have "what we need" but can't provide guarantees

NickS: We don't need to make guarantees, but there are two types of abort
... payment apps still need to be able to handle aborts (e.g., if page dies)
... so I definitely think that payment apps should have a state where they can abort.

<nicktr> thanks from the chairs for the presentations from Zach, Rouslan, Roy and Stoyan

Samsung Demo

Alan: This is the SamsungPay demo... first step install the Pay Application
... Big thanks to shopify for enabling this, Andre thank you.
... There is a special website up there, I'm going to hit "Buy Now"... add items to cart, check out
... When I click check out, see payment sheet, use payment request, select shipping address.
... I can click on pay button, since I selected all items merchant wanted. Samsung pay comes up, I enter my PIN or fingerprint, then that completes the payment, notification at top, lots of round trips took place.
... Merchant submits to Visa, pull down certification, launch me into Samsung Pay, Visa card network submission, gave back response to merchant saying payment was ok, then notification comes back in a different channel, so user can see verification in both places.

<Ian> NickS: Is the UI yours or chromium's?

<Ian> Manesh: Samsung's browser

Samsung pay has tokenized DPAN/Crypto

Alan: Yes, trust zone based auth takes place, that's used w/ keys from issuers keys, cryptogram is created, passed back... then tokenized payment is decrypted, and submitted w/ cryptogram

Ken: Timeline that you can share?

Alan: Soon.

Ian: We'd like to link to implementation stuff, developer docs/portal, when it's available, we'd like to hear about it.

AdrianHB: What kind of method identifier are you using?

Alan: spay.samsung.com
... We'll publish a payment manifest file...

AdrianHB: That would limit it to Samsung Pay?

Alan: Yes

Worldpay Demo

nicktr: My innovation team has put this demo together, tech demonstrator, show it to product teams/merchants, exec committee, etc.
... I'm showing you the experience when you have native and web apps, going to check out
... Here's the payment sheet, we have a web app worldpay online (web app), android pay (worldpay Android native app)
... Native experience, no auth, native app, select pay, submits to test platform, transactions occur.
... For a web app, here's the experience... pick worldpay online... calls service worker, moves to web page, no auth, pay now, transaction occurs.
... User experience is consistent - payment app is consistent, down to implementation...
... When they see payment experience is consistent, that they get.

AdamR: Is the service worker implementation a complete implementation?

nicktr: It's Tommy's build.

Tommy: It's a bit of a hack, but it goes through actual service worker.

Alibaba Demo

Max: Hi, I'm from Alibaba, this is our demo, an updated version of the one we showed during TPAC 2016.
... We use the payment method manifest file for this... right side is the browser, working w/ Google, thanks Rouslan/Zach for the help.
... In the source code, here is the payment method, Alipay.com
... We have payment method related information, we have payment request API to invoke the payment method.
... When I click buy, alipay native app comes up, we can choose different methods in alipay, support credit cards.
... We can use fingerprint for authentication, payment is done.
... The payment method manifest file resides on alipay.com. When I push pay button, they get manifest, here's the JSON data ... note the fingerprint, browser can use that fingerprint to verify.
... In the latest payment method manifest proposal we put that information in a different web app manifest, we'll talk about this tomorrow in detail.

Zach: That was standard chrome,

nicktr: Native ali pay app?

Max: Yes.
... When the merchant only has one payment method configured, we can just directly show only configured payment method. When I clicked buy button, only Alipay would work.

Ian: We have discussed that user interface optimization before: when there is only one matching payment app, launch the payment app automatically (e.g., on user configuration) to save a click.

Zach: In chrome dev channel, if you call paymentrequest with one method, no additional features, the UI in the middle adds no value. Only thing you can do is click next.

Ian: If I store a credit card in the browser, when I click buy, I enter CVV (prompted)?

Zach: Third party payment app, URL identifier, search system, system has that device on there.

Alan: One less click for the user, it does create a different user experience.
... We've talked about that internally.

Zach: It's a concession to reality, if ultimate goal is payment request is reduce the "Nascar problem" (of lots of payment service logos).
... I think you'll see "Pay with X" buttons, not generic checkout buttons, we need to make the case to add more things to payment apps list over time.

Mahesh: There is an alternate way of using this, we should spec that.

Zach: Not sure I agree, this is a UX decision. From spec perspective, nothing is changing.

Ian: Have any browsers implemented a user configuration that allows the user to say "I always want to use the following payment app on this origin?"

Zach: We have no current plans around that. Difficult from perspective, tricky agreements in place. Payments app providers would not be happy...

Alan: There is an emerging tension between browser and app itself... Samsung Pay, functionality in in-app SDK that enables collection of shipping address.
... there is overlap there, we may want to evolve the spec to expose how much functionality it has, so optimal path can take place... not sure.

Microsoft Demo

Molly: We have early windows releases in windows insider... this is our demo site, microsoft edge. We have a payment request demo

Ian: This is public?

Matt: Anyone can access this.

Molly: This opens up Microsoft Wallet, kick off payment request. Shows up changing shipping address.

Matt: What we see here, it's a signed in experience, opt-in page for wallet. Giving awareness that you're using Microsoft Wallet.
... We always require CVV, we're working on security, so we'll reauthenticate... dabbling with these.
... This is available on insider builds now, this is a good guide to see how different interactions will work.

Ian: Any public statements on release?

Matt: Nothing firm, next quarter or the one after.

Mahesh: What part of that was native app?

Matt: This wallet is a native app, but what's rendered inside the app is our website.

Frank: What support is there for third party payment apps?

Matt: We're focused 100% on Payment Request, focus on basic card.
... Similar to approach to Zach/Google is taking, we have proprietary platform features...

AdamR: This is basic card right now, tokenized scheme, plan to use it?

Matt: MSDN docs, there are tokenized schemes/payment methods.

Gemalto Demo

Pascal: This demo was meant for internal demo purposes, Gemalto has a mobile financial services demo. Produce SDK for bank/financial institutions. The idea that I'll show you, implementation of creating new web payment app, and use it through payment request API, using Tommy's build.
... I have a small demo website, the idea is to show details of implementation and let them understand what types of information exchanges between browser/app. Full process we've implemented. If you don't do anything special what you have is only the payment methods included into your wallet.
... But, if the merchant is about to enter other payment method, opportunity to install it, you can register payment method, credit transfer payment... enter details for this payment method... then install payment app.
... I can go back to merchant website, when add items to cart, then it shows my credit transfer method.
... I include tax/shipping information, it shows up, selecting new shipping method, SEPA information is displayed on payment app, I accept, payment happens and I go back to merchant.
... These were web-based payment methods.

Ian: Later I will talk about payment app experience we've had so far. How many people have played around w/ writing payment apps?

10-ish people raise their hands.

EMVCO Update

nicktr: We've been talking w/ EMVCO on Web Payments - WorldPay is an associate of EMVCo, we pay to be an associate... EMVCo is a standards body that do chip card standards.
... The apps that sit on the card, certification process, communications, EMV standards - tokenization standard, Apple Pay, Android Pay, they are network tokens. Implemented EMVCo specification.
... 3DSecure specification....
... It's not an open organization in the model of W3C, so I have to be careful about what I say, and will speak in generalities.

ken: On EMVCo: This is mostly 6 members, align on card specifications, terminal specifications, and then come up with other standards around comms, specification, contactless, alignment, mobile standards, tokenization standards for issuers.

nicktr: We've been trying to work w/ EMVCo - that conversation is ongoing, but complicated, fruitful, different ethos between W3C and EMVCo.
... EMVCo doesn't operate like that, builds specs internally and then publishes, we're trying to have those conversations now.
... They have not made any information public yet on how they're thinking about this. Security is at the cornerstone of what EMVCo does. That's where input to W3C would come from.
... We need to be patient about timescales. Over the course of this year, we'll make progress, can't talk about time scales yet.
... Watch this space.

Ken: Part of American Express joining W3C is to bring value. We support building relationships between existing standards bodies that can add value, EMVCo and PCI, we're behind trying to help foster a healthy relationship between all of these organizations.

NickS: How does not being able to talk about EMVCo's process work w/ W3C Process.

Ian: There is a good faith effort going on right now on working together.
... I had a chat with PCI, what are the PCI/DSS implications of Payment Request API. Or other PCI implications (e.g., around payment apps). I talked w/ them, updated FAQ on developer portal after the conversation.

Ian: What does this mean for PCI/DSS compliance? I am initially optimistic the answer is "nothing," but I have a meeting in two weeks to work out whether and how PCI could do an official analysis. For large merchants, there is a requirement to look at code. Assessments of any code will include assessments of the use of Payment Request API. But my initial understanding is that PCI/DSS scope kicks in once merchants have data, and does not touch on how the data was procured. Mostly today I wanted to say that we've started a good conversation with PCI.
... Elsewhere: I was invited by European Central Banks to present our work. The work being done in the IG task force on regulatory topics has been helpful.
... I've also started a conversation w/ NACHA about the credit transfer spec. Zach justifiably asked whether the credit transfer spec could in practice be used across different credit transfer systems. So we are investigating, including by talking with NACHA about ACH..
... Our goal with the credit transfer spec is to come up with a common set of fields, ask NACHA if what we have would work for them... they have ISO20022 fields, Todd has a document, we need to engage with credit transfer stuff.
... We're doing our due diligence.
... I also hope to see ATOS get more involved.

Cyril: They're a "French WorldPay"

Ian: We're having renewed conversations w/ MAG, those are ongoing.

nicktr: There has been a huge consultation process around PSD2... this capped interchange rates, etc.... new focus on authentication, and restructuring.
... There are significant changes that this group needs to be aware of, looks like increased usage of two-factor authentication. I hesitate to say where it's going to land, still not done, EU Parliment delegated power to ECB, the Final Report is being reviewed by European Commission now.. then needs to be accepted by European Parliment.
... The direction of travel is, frictionless/invisible payments are going to be challenging to do... UI going straight through is going to be hard to do, low transaction limits, amount is same every month, those will be exempt... but in general, you will have to authenticate.

nicktr: There is a strong regulatory direction - our architecture works well for that... demo from Pascal, shows how payment experiences might land.
... We've talked about W3C specs as standards that those groups should pay attention to.

Payment Apps Update

<Ian> Slides: AdamR's slides on payment apps which refer to the Payment Handler API

AdamR: My main goal is to bring people up to speed to participate in the conversation tomorrow around payment app issues.

[Adam reviews primary changes to the spec]

(IJ plans to not scribe what is on the slides; will focus on other comments & questions)

(Text around instrument display)


(slide 5 shows code)

(slide 6 shows permission request by site -> do you let me handle payment requests?)

AdamR: We'll talk more about permission requests tomorrow

Michel: Registration of a web based payment app is analogous to a plugin installation

Marcos: Same idea as for things like geolocation

Alan: I have some concerns about how permissions are presented

AdamR: Agree this is an important topic; this demo is just a hint at the direction
... Different ways that logos and icons can be brought in to display app information in the sheet
... including app manifest and link/meta info

michel: Registration seems to be something that happens once, early on

AdamR: The payment app is associated with an origin, and it's up to the origin to keep the app up to date
... apps that are updated have permission and don't have to ask for it again if they update their capabilities, or if the user adds instruments
... I also understand that there's an update mechanism of service workers. So service worker can help keep the app up-to-date

dick: Can the user pick a friendly name instead of "***4322"?

AdamR: That's an implementation choice.

NickTR: I think of this as being a site-specific feature...you can add/remove instruments and also provide friendly names
... so that the friendly name is REGISTERED rather than the default

zkoch: Chrome today does not provide the friendly alias functionality

AdamR: We've heard that artwork (e.g., credit card logos) is an important feature

Marcos: We have a data structure for cards. Not sure if we can reuse the information; would be nice to consider

IJ: Also easier to add new cards and update card data easily due to finer grain API

AdamR: Set operations have keys associated with them....payment instruments can use those keys to appear in wallets
... key format is up to payment app provider
... tomorrow we will talk about the user's ability to select instruments directly from the browser chrome, or whether selection is at the level of the app

[Client open window]

AdamR: Moving in direction of a payment-specific open window event and experience can change based on screen dimensions.

Ian: A nice reason to do this can improve on user experience that we have today. This is a significant usability win.

Katie: Make sure focus moves to that window

Marcos: Chrome's implementation does this and others will

fdold: How would navigation be handled?
... what happens if error happens

AdamR: We have not talked a lot about what web primitives you can use internally

Marcos: Suppose you get a 404...and didn't have a close button

AdrianHB_: You might need a post messager

AdamR: I am certain we will need some affordance for user aborting the payment
... we need to make sure there is some recovery path

AdrianHB_: We should not carve out a narrow path for developers; let them leverage the full strength of the platform

AdamR: Can call postMessage back to service worker when done
... to send the payment app response back


AdamR: use cases involving grouping (e.g., business v. personal account, or white label wallet provider)

(slide showing amex business and amex personal wallets)

Ian: same origin, different semantic groupings

Ian: Permissions are by origin; but there might be different display goals for a given origin; hence wallets

Manu: Concerned about the term "wallet"

AdamR: We are not wedded closely to "wallet"
... Something like "Instrument Groups" might be fine

zkoch: What does this gain you really? You could simply use different labels like "personal card"

AdrianHB_: I think white label wallet provider is a stronger use case

Ian: there was pushback to saying "use subdomains" as there's a cost to doing that

AdamR: And using a new subdomain would require a new set of permissions

Ian: So the question is "Do we need this additional complexity to meet these use cases"?

AdrianHB_: As an implementer you can choose to display under a single list; the spec gives you some extra structure

zkoch: Just want to say that implementation is not free

AlanSamsungPay_: I don't see this getting adopted much. There's a lot of opportunity for control of the user experience.

Mahesh: On the UX side, when does the window open?

nicktr: On ordering....merchants provide ordered list of payment methods. What is relationship between payment method ordering and groupings?
... suppose bobpay has a personal and a business wallet
... and one wallet includes instruments for basic-card and, say, bitcoin
... and one wallet includes different instruments for the same.
... how does that work

AdamR: That is currently unspecified. I expect that can be specified.

IJ: I agree that there is an issue about merchant pref as related to payment app prefs

AdamR: Agree we need an algorithm for this.

Alan: Who are the primary authors of the payment handler spec?

Adrian: There is a payment apps task forc ce. The editors are currently Tommy, Adam, Jason, Ian, and me.

Roy: If you have registered an app and on a different device, and you add a card, how does that get updated?

Marcos: Permissions are per device

IJ: You should be able to write your payment app so that instruments are visible on multiple devices

DavidM: Could you limit visibility of some instruments for, say, mobile

Marcos: Yes. User controlled.
... you can manipulate instruments on a given device, AND also sync them as you want

Review of Day One Issues

Adrian: Here's what I've captured:


Pat: We can talk about this further in the IG. This would not happen in PR API
... we can look at what data is perhaps useful for some jurisdictions

Ian: +1 to writing down the use cases in the IG. I think we should write down the use cases that we have, Vincent had one wrt. contracts registered, let's write them down in the IG, play around with whether this would be useful as private data, new payment method, etc. Let's write the use cases down in IG.

Pull payment centrism in PR API

MattS: I'm ok to discuss this via a pull request
... there are three or four places in PR API where it might be worth making it less pull-centric

zkoch: +1 to pull request

Payment Handler Implementation Experience

<manu> AdrianHB: How to render UI?

<manu> nicktr: Tomorrow we have a slot for it, let's talk about it then.

(On the agenda tomorrow)

Invoking Native v. Web-based Payment Apps

<manu> AdrianHB: Max raised a point around handler invoking - web and native app installed, how does browser decide which one to present. How do we say "this native app is a version of this web app". Or are they separate apps?

<manu> Zach: This is a UX question - UAs will determine what is the right way to do this.

<manu> AdrianHB: Maybe this is a way to handle it in the manifest discussion.

Recurring Payments

<manu> Alan: Has there been discussion around recurring payments and data flow? Flag from merchant wrt. subscriptions?

<manu> AdrianHB: This has been deferred at this point... recurring payments are focused on cards, some payment methods don't work for recurring Bitcoin, for example, scheme and payment method specific.

<manu> AdrianHB: Indicate things like subscription, terms, ... if we want to add that to basic card...

<manu> Alan: Quick backgrounder, part of input params for visa cryptogram generation in the cloud to generate cryptogram in different way for recurring payments, so this is important to keep in mind. Since it's relevant in other circumstances, it doesn't seem like it should be payment method specific.

<manu> Alan: It's a more generic use, don't want to specify something specific to our payment handler... similar to order number.

<manu> AdrianHB: I could imagine this being added to basic card spec... it isn't in v1 of that spec.

<manu> AdrianHB: We should explore that.

<manu> Michel: It sounds like recurring payment is not really associated to basic card.

<manu> Michel: Recurring payment may be out of scope of payment request API, passing credentials that are outside of scope - pass me credentials, I'll process it for you, recurring - we may be able to look at it in that way - how many times, days - it should be generic.

<nicktr> +1

<manu> AdrianHB: If someone can design this flow and come back and show us why it doesn't work, that's a great way for us to decide what needs to change.

<manu> nicktr: Recurring payments were deemed not in scope for v1 of the API design.

<manu> dezell: In Lisbon, we had a session with Andrew Betts that talked about subscriptions, recurring payments, and there was supposed to be a CG. This is why the IG stopped talking about it. I don't know what happened with it

<manu> AdrianHB: I think it's a digital publishing CG now.

<manu> CyrilV: We have direct debit systems that do recurring payments. It's easier to do this work on SEPA Direct Debit and work for any direct debit... direct debit across countries is a nightmare... we need more than one scheme that can support it.

<manu> AdrianHB: We have opportunity to standardize data model - we need more use cases to standardize.

<manu> NickS: I would resist trying to do recurring at this point. The variety of information you need to collect is large.

<manu> NickS: We already have this support, you can put it in the payment method spec.

<nicktr> +1 to Nick's approach

<manu> AdrianHB: If someone writes 3rd party payment app - strong motiviation for browsers on how they can support that.

<rouslan> http://i.imgur.com/GY31DAb.png

<manu> Rouslan: In relation to subscription, PaymentRequest API works, Washington Post uses payment request for subscriptions... even though we don't have mechanism, merchants can figure this out on their own.

Payment Method Specs as Recommendations or Notes

<manu> Ian: I've found when we did our call for consensus - we concluded to request publication, TR to Wendy, note that these are called out clearly as not going to REC.

<NickTR> Let's leave as Notes.

Should we indicate in payment response what format data is in?

<manu> AdrianHB: What format for metadata in payment request - format for phone number, etc.

<manu> Ian: one thing that's analogous to this is our currency code decision... we have a way to say "this thing is in this repository over here". The default format is X, but if you want to use another format, it's over there

<manu> AdrianHB: Difference in this case is this is in the response, browsers will support one format or "we don't know"

<manu> Zach: Do we care about anything else than phone number here? We picked a standard address format... our i18n team is okay with it, that exists. Phone numbers are the only exception... very difficult to format them, I think safest thing is to remove all formatting, return back a bunch of numbers, then optional plus before country code.

<nicktr> PaymentAddress interface

<manu> Rouslan: We don't have separators, but we do have a format that we follow

<manu> Alan: It's only numbers or only values.

Disambiguate between user abort and merchant abort

<Zach> There are two places that .abort() is thrown, when user intentionally stops it. If you can deduce who abort()'ed.

<AdrianHB> Additional state when you can't abort because payment app is in processing state.

<Zach> We put it in the spec because there are certain situations where you can assert control... I'm hesitant to impose a tighter restriction here.

<nicktr> The payment apps spec, before complete is called, payment request user interface stays in a pending state. There is another state in the state model, there is already another state in the state model - diagram of state model.

<marcosc> We should delete the diagram, it's accurate, but not helpful.

<AdrianHB> Something we need to figure out in Payment Handler spec wrt. when on payment request is made, and then someone calls .abort() on payment request on merchant side. What's the teardown mechanism there, is there one?

<marcos> You need to tell it you're aborting, as you go to next step, something is going wrong - if I'm buying a movie ticket, the tickets are all gone.

<nicktr> A point was made about idempotency.

<marcos> We'll see if it has any effect, and add it in. We could add a conceptual state... state machine, accept promise is selecting the reality of the state, that's what you get back when you get .show()

<marcos> it's strange, but expected,

<nicktr> We should add it to the discussion for tomorrow, but not high priority, very technical

<Ian> Just to note: I integrated the remaining 3 issues logged by AdrianHB (about payment apps) into my presentation tomorrow about payment app issues.

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/03/28 20:17:30 $