See also: IRC log
<stan> I'm the other call-in people, stan from Stripe
AdrianHB: Can we get some introductions form new folks.
Steve: Hi Steve from shift4? I'm one of the founders of the company, payments company, mostly in North America, trying to expand out further, trying to get more involvement at a global scale.
Stan: Stan from Stripe, I'm on the acquiring team, mostly focus on non-card payments, trying to roll those out. Excited to give that perspective to the group.
Jenan: Jenan, on the Stripe Web payments team and mobile payments team?
AdrianHB: Please be aware that we have two guests on the call.
Zach: You mean for the PMI pull request?
AdrianHB: We talked about this - action is to put a PR together based on the discussions. If that is low-priority before you resolve the other stuff, just wanted to touch base on where we are.
Zach: The only point of contention that remains is whether or not we restrict string to W3C-only things, make URLs a backup option. The PR is secondary to the active payment actions one. I'm prioritizing that one.
AdrianHB: Happy to help on the PR
Zach: Do we want to discuss that and close it out while we have everyone on the call.
AdrianHB: I'd summarize to as - we settle on using URLs and fetch a manifest form URL. We also allow short string, open payment method, not mechanism to restrict which payment apps can use the payment method. Can strings be usable by anyone, or should browsers have a hard coded list from list of specs from WG.
manu: +1 to not allow strings for anything other than W3C specs.
ShaneM: Can you illustrate use
cases where short string that isn't already known ... what's
the use case, and how would it manifest?
... Use case at TPAC was standards body that doesn't have W3C
association develops standards in payments domain - EMVCo,
decides to come up with a payment method, they have members
that agree, merchants implement, payment apps implement, for
them to implement they'll need to go through the process of
goign through W3C.
AdrianHB: One of the solutions is to just use a URL - browsers may constantly hit URl to fetch a manifest where designers didn't expect there to be manifests.
zach: I recognize there are no current examples of this. This is forward looking and theoretical, but anyone could claim any arbitrary string, that gets messy in my mind.
<ShaneM> -1 to allowing nonURIs. W3C is not going to be a bottleneck
zach: I'm highly suspect that W3C
would be the blocking mechanism.
... There are coordination things we need to figure out to make
it more accessible, nothing preventing them from spinning up a
URL, cached simple thing, or alternate, lightweight process at
W3C.
AdrianBA: It's not the case where we need to require a spec process, the end goal is standardizing the string at W3C. If some other organization goes off and creates a spec, it seems like it would be easy for us to define that.
<ShaneM> W3C is capable of normatively referencing external specs.
<dlongley> manu: Mostly to agree with AdrianBa and Zach. This group would define this, I think out of a desire to stay relevant, we would write the whole spec and then coordinate with that group. I don't see a problem with saying "if you want to use a string, you have to go with W3C". We'll probably do the work to define it here. It's supposed to be a W3C only spec... for anyone else who isn't engaging W3C, use URLs.
<Zakim> manu, you wanted to say we can't tell implementers to go to W3C, we'd do it instead.
<Zakim> jnormore, you wanted to ask about no manifest for short string methods
jnormore: I think strings make
sense, no manifest - what happens when there is no
manifest?
... Is there any other information in the manifest, other than
restricted apps that would require some part of the manifest to
define open payment methods.
adrianHB: The manifest format isn't fully defined.
Zach: I have a strawman
proposal
... Jason, is your question about the value of the
manifest.
Jason: No, if the manifest is a basic string, the manifest isn't a thing in that case.
Zach: I think the string, the spec defines - it's an open method, no need for a manifest.
<ShaneM> dlongley: +1
<AdrianHB> PROPOSAL: PMIs that are not URLs are only used for payment methods defined at W3C
manu: +1
<jnormore> +1
<zkoch> +1
<dlongley> +1
<adrianba> +1
<Max> +1
<ShaneM> +1
<dezell2> +1
<zkoch> Go for it! I’m behind in all things in life. We’ll see who gets there first :)
RESOLUTION: PMIs that are not URLs are only used for payment methods defined at W3C
Zach: Everyone is generally aware of the proposal, here's a link
<zkoch> https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
Zach: General idea - people would
like to know before showing the UI, whether or not a payment
method is available. If you're available /w ApplePay -
canMakePayment... isReadyToPay for Android.
... I think most people are supportive - how much people need
it to be spec'd out for implementations.
... That's up in the air, need input on that.
... Most of the PR is written, algorithms left out, I've had a
chance to talk w/ a lot of different people - generally, people
are supportive - made changes to TLDs last week. Only thing
pending is the PR. If people have issues, speak up now.
... We are looking for input on time limit restriction.
<dlongley> would be good to get a security review from WebAppSec on this particular piece in the future
Mahesh: I'll chat w/ Zach about
this today - only thing I wanted to talk about, time limit -
get rid of it, only alternative is having one page, browser
cache responds on that tab, no matter how many times its
called, cached response is returned. I think shopify had a
comment on that, what if multiple pages on different
tabs?
... if one tab is opened, the response is cached,
session-based.
AdrianHB: Let's wait until PR is
done - pretty good rhythym on editors of specs making direct
changes. Everything is done through Github, you can submit a
PR.
... Sometimes if it's a big issue, we have a discussion on
this, someone puts a proposal together like Zach's, discuss
that first before diving into laboriuous spec text. Quick
overview of process.
... Once we have something to talk about, we can analyze -
leave it to you guys to chat, Zach and Mahesh.
AdrianHB: Roy has made a few changes in the PR, do you want to give an update?
Roy: It's pretty simple, we tried
to pull that PR back to just having transaction ID, the
transaction ID in the current PR is optionally provided by the
merchant.
... Everything else is left out for later discussion.
Stan: I'm looking at PR adding processing state, not seeing something where payment has been processed, what's the thinking there?
AdrianHB: Processing state has been pulled out for callback URL idea. Response from payment app, go and listen on callback URL for a result.
Roy: That was pulled out, it's just the transaction ID at this point
AdrianHB: A quick note for push payments, thinking was around making push payments work a little better. We have to balance putting stuff in vs. letting payment methods define that. Think ahead and avoid massive fragmentation. Callback URL is a prime candidate where if we had a top-level callback URL, there may be some benefit. We're not convinced enough that it can be standardized enough to be useful. If you have input on that, that would be valuable.
<Zakim> manu, you wanted to note what's happening w/ callback_url?
<dlongley> manu: Just to raise a slight bit of concern about not standardizing the callback URL. I'm hearing we feel it's important but it may go in a push payment spec, and if that's the case, I
<dlongley> manu: I'm a bit concerned about that. I feel like we have enough feedback to understand the basic concept and to define a callback URL and send a response to it.
<dlongley> adrianHB: The plan is to look at the current proposal and we haven't completely thrown away the callback URL idea. It's the most contentious part so we've split it out of the proposal for now. If people are still keen on having it, it should be in its own proposal.
Roy: Still intending to continue
to talk about callback_url
... We didn't need to couple these things together, we have
consensus on transaction ID.
Jason: I'll echo what Manu said, we can leave callback_url for a later conversation, but it's important.
Zach: Any comments from Zach or Adrian? Seems fine to me. Do we want to have any specification for how this gets generated or leave that up to implementations?
AdrianHB: Any thoughts from implementers?
<ShaneM> I think it is a UUID
stan: It could be useful for support purposes that customer eventually sees that ID so merchant and payment provider where that can be reconciled. Things are often uppercased, such and such.
AdrianHB: The group seems to be happy with putting this in now, ironing out the details. Do we need to be specific about what the identifier looks like.
AdrianB: I'm still reluctant, I
can live with the proposal. If we have a generated ID, we
should propose something. We could use UUID, as Shane is
proposing.
... Whether we're that specific or not, we should at least say
that implementations shouldn't encode recognizable data into
that identifier. We've seen places in the past where
identifiers contain part of the request into the identifier
then web developers depend on identifier having that
format.
<dlongley> +1 require auto-generated identifier to be opaque
adrianba: We don't want developers depending on that sort of functionality.
<Zakim> jnormore, you wanted to add that I wouldn't want to restrict format for merchant generated ids
<dlongley> +1 to not restricting merchants
<ShaneM> +1 to never restricting what the merchants can do
jnormore: I don't want to restrict what merchants do there, they know best, I have a bias towards that. In terms of what browser should do, I'd lean toward no restrictions.
<stan> +1 to not restricting the merchant: eg UUID is probably too long for most bank statements?
AdrianHB: Maybe AdrianBa and Roy can take this offline and merge when happy.
adrianba: Sounds good.
<ShaneM> I note that if you are going to do a push payment, then you really need to be able to push the payment...
<dlongley> manu: If we're going to do push payments we need a way to notify the merchant via some kind of callback URL that's out of band with the browser if the browser goes away. It's not that complicated, if we can agree we want to do push payments, which we have I think, the question is how to do it. The simplest way is provide a callback URL and then send a message to it.
Roy: Wanted to give some
additional explanation on what PR was intended to describe. My
goal was to instrument a server callback URL, payload that goes
to that URL should be payment response in the browser. Payment
Method Identifier, status, more importantly, freeform data blob
that payment apps can use.
... One of the bigger comments, people will want to put their
own data in there, I think that was intended to be supported.
Wanted to know about the pushback.
<dlongley> +1 to parallel's with HTTP API, could reuse/define there perhaps.
AdrianHB: I think a new PR will have to be clear about that. The way we defined HTTP API, don't want to put a strong dependency there.
Jason: We need a well defined format - wanted to add, merchant would have some relationship w/ payment method, could achieve it in their own way, the open payment method type, multiple apps for payment methods, apps for different - requirements on merchant to integrate w/ different apps, may cause problems there.
<dlongley> +1 we should standardize it
<zkoch> Jason, isn’t that conflating payment methods and apps?
Max: I'd like to use callback
URls to notify merchant.
... Sometimes loss of network connection, user may close
browser, would like to work with Roy on this.
adrianba: I remain opposed to this, the real idea with this proposal is that we'll be able to use one callback URL. Roy is proposing callback back - we're not saying whether or not you can have callback URls, this is just about standardizing a single input that you can use everywhere. I'm not sure we can make that statement yet. People may want to do different things w/ the callback. Not convinced that people are in agreement on what format of data should be carried; want to get more experience before we can conclude that.
adrianhb: We are getting some
examples. This may be premature to put in, but at the same
time, we have to think about how disruptive it'll be to put it
in later.
... Moving this to a top level is less disruptive.
<dlongley> the payment response message sent to the callback URL can be very flexible, we just need to define how to specify the callback URL and the minimum information that goes into the payment response message
Stan: Some of this stuff, we want to give perspective, this is not push payment specific, you have to rely on the callback to make sure payment is successful. Another data point, iDEAL - synchronous, but order is successful is as soon as it's accepted at bank app. We've seen, for those types of instances, we make the callback_url the preferred way of doing it. What is the security aspects of the callback URL? Open payment method situation, what's the trust model?
<dlongley> manu: So there are two comments to follow up on. The first is, Jason put into the IRC channel that there are 50+ methods that they are standardizing callback URLs for. I think we have enough data to figure out what needs to go into the message. I share Adrian Bateman's concerns about defining how everything works for everyone in the ecosystem. I don't think what we're talking about here is defining any old "callback_url", rather, we're doing a very
<dlongley> specific type of callback URL. I would -1 something really generic, but would support a very specific callback URL for sending information to a merchant saying that the payment has hit a certain status.
<Zakim> manu, you wanted to note jnomore's comment.
<Roy> max said it was useful...
zkoch: We keep conflating things
here, shopify is an implementer of payment methods. If the
payment method has to take that callback_url as input. Shopify
would have to expose the endpoint, but that doesn't mean
anything if these payment methods are using it. I haven't heard
from a single payment method provider to use callback_url
defined by the spec.
... There is a difference between utility, vs. willingness to
use it. Is Alipay going to change their implementation to use
it?
... I think there is complexity on the payment method side, we
don't have evidence from payment method providers.
AdrianHB: Fair comments, there is
some desire from people involved in push payments - proposal
needs to more clearly articulate how that would work.
... This is a URl where you post payment responses, it's not a
generic place where people can put URLs. The purpose of the URL
is specific, it's not just a general callback_url, we need to
be specific about what it is and why that is valuable, beyond
just convenience.
stan: I kind of agree with Zach's comments, status of payment asynchronously.
<zkoch> Okay, really have to go now. ::waves::
AdrianHB: That's another issue, thoughts or proposal on what to put forward to do that, we lived under assumption on communication between website and payment app isn't going to be very reliable. Can't get a handle back, and communicate back and forth with the payment app. Things have progress a long way since then, channel between website and payment app. We need to see a proposal of how that would work, pratically between payment apps, could be web based, native app based, responsibility of browser to specify what types of payment apps they'll pass payment requests on top.
AdrianHB: Would be great to put that on the agenda next week.
Roy: When I looked at AliPay and ??? specs, there are provisions for both kinds of integration. Server callback of some kind. endpoints where merchant can call into payment method implementer. I picked the one I did to start because it was going to be easier to tackle. Lower traffic volume, less incentive to mess w/ people. Other way is there as well. Didn't address that yet.
AdrianHB: That can be very
payment method specific. payment app does what it needs to do
and returns a URL. What we want to standardize is payment app
back to merchant system. Only have a couple of minutes left.
next step clearly a bunch of people interested in pursuing
this. I'll leave you to pick it up w/ Max, Jason, Manu, and
Stan.
... Don't know if we'll have a meeting next week, will confirm
with him, ian, and Mike to make sure someone can run the
meeting next week.
Alan: Hi Alan, from Samsung Pay - dialed in late, will get into schedule - quite interested in callback question, will have to ramp up to participate.
stan, Github issues and email
ShaneM: We're setting up another mailing list to talk about testing.
<Roy> shane, I'm happy to help code review testing stuff
<dlongley> 24th-25th
Note: This section was not discussed as such during the call; Ian updated and corrected the information following the call.
Per announcement we plan to meet on 17 November. Reminder: No meeting on 24 November.