See also: 24 March minutes · group photos · IRC log
[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
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
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?
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
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
<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.
<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.
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
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
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
[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
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
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.
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.
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.
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.
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.
<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)
serviceWorkerRegistration.PaymentManager.instruments
(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
[Wallets]
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
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.
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
<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)
<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.
<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.
<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.
<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.
<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.
