Nearby: 24 February minutes
<trackbot> Meeting: Web Payments Working Group Teleconference
<trackbot> Date: 23 February 2016
<Ian> Meeting: Web Payments Working Group FTF
<wseltzer> Agenda:
<zkoch> The external link for this Hangout that anyone can join to watch the presentations live is: https://plus.google.com/hangouts/_/google.com/w3c-web-pay
<m4nu> scribe: manu
<m4nu> nickTR: Welcome everyone to the Web Payments WG meeting, we appreciate everyone's commitment of time over the next two days
<m4nu> NickTR: A couple of W3C minutae - we have an IRC channel and a Google Hangout for communication. We take minutes.
<m4nu> NickTR Covers a lot of basic meeting minutes.
<m4nu> Everyone is going around the room and introducing themselves faster than the scribe can scribe the names... 40-ish people in the room, all of them seem like nice people.
<wseltzer> [on the phone: @@1 Samsung and @@2 IBM]
<zkoch> External hangout link: https://plus.google.com/hangouts/_/google.com/w3c-web-pay
<m4nu> nickTR: Web Payments started at TPAC - annual get together at W3C after having been incubated in the Web Payments CG, Web Payments IG, and some other groups
<m4nu> NickTR: Our charter is to make payments on the open web easier - definitely for browsers, but also for non-interactive cases like device-to-device. We're focusing on browser APi right now - no point in designing a standard if no one is going to implement it and deploy it.
<m4nu> NickTR: Most of this morning is about reintroducing the subject - we'll go over flows, a few demos - will surface a number of issues. Up to the group to triage those - which ones are most important, some of them have a critical part to play in direction of the WG.
<m4nu> NickTR: We need to understand the proposal, choose a way forward - focus on a FPWD by end of March - time is running out.
<m4nu> NickTR: We're looking for people to step forward as contributors/editors of specs - we need volunteers.
<m4nu> NickTR: If you have time, and if there are issues here that are important, we want to hear from you. On that note, thank you, now we're going to go into Architecture.
<Ian> Architecture doc
<m4nu> AdrianHB: Since October, there has been a fair amount of activity on proposed specs - we have a task force that's been mapping out all different payment flows. There is a proposed architecture that's on the wiki - provides basis for discussion - quickly talk through the agenda - purpose of meeting is to come out of meeting with firm resolutions.
<m4nu> AdrianHB: Hopefully we have editors named and a group specification that we can go forward with. Today the WG doesn't have a spec of it's own - we want to figure out a single starting point to go forward with.
<m4nu> AdrianHB: This architecture was put together, abstract, to try and understand the moving parts of what we're doing that isn't specific to deployment scenario. How will this work on a desktop, how will it work on mobile - it doesn't focus on that. it's more abstract. Intended to be a starting point.
<m4nu> AdrianHB: We wanted to get away from industry definitions that were causing a whole lot of bikeshedding in the group. A lot of the people working in this group are not payments experts, they're browser/tech experts. For instance, we don't mention a wallet in the architecture - we have a payment app - we don't call it a wallet - too hard to define what that was, everyone has their own idea.
<m4nu> AdrianHB: When we're done - please feel free to discuss/ask questions.
<m4nu> AdrianHB: Primary actors are the interface to the payer, the interface to the payee, and then there is the mediator - mediator is there as a privacy-enhancing mechanism.
<m4nu> AdrianHB: What are the ways this person wants to pay me. based on info, kick off that payment. We don't want to violate the user's privacy.
<m4nu> AdrianHB: The intention w/ payment mediator - these are all the ways I can be paid - knowing what payment mechanisms payer has, payment mediator can pick how to make that payment. Does not leak information to payee.
<m4nu> AdrianHB: The payment app terminology - in mobile world, it's a mobile app. The thing that gets the payment request is an app - conceptually the idea was there. There are a few proposals about desktop payment app and how that works.
<m4nu> AdrianHB: Something that comes back in a browser frame, or is it another app?
<m4nu> AdrianHB: That, at a high-level, are the moving parts - how that manifests in different deployment scenarios is the browser where the payment mediator is taken on by the browser - that's probably closest to where we are today - browser API we're designing today. The one that processes the request, prompts the payer to pick a payment app. In this instance - the payment app host - payment app could
<m4nu> be browser extension.
<m4nu> AdrianHB: When app is instantiated, browser could pop up embedded iframe and fetches other stuff from website.
<m4nu> AdrianHB: When we look at mobile apps - payment mediator may not be browser - important for us to understand design constraints on API. If we look at Android, it has intents, that's a way of prompting one app to prompt another one to take over.
<m4nu> AdrianHB: My expectation in putting this together, that is how this system would work on mobile. Rather than browser picking app, mobile OS has that capability today, that's how intents work - here are the installed apps. I want to share a photo - it's a pattern that's well understood.
<m4nu> AdrianHB: I don't think any mobile OS has the granularity that's needed.
<m4nu> AdrianHB: I think that's a good place to stop - purpose of this is to understand how we can design something that's useful across multiple design scenarios. How can we accommodate the mechanism. Web Intents focus on particular platform is a lesson, we may not want to focus on anything in particular.
<m4nu> richardBarnes: We need to have all the design stuff in mind, but it's not something that's specific to Web - leave it up to mediators to figure that out.
<Rouslan> +1 to rbarnes
<m4nu> AdrianHB: Where this has come into play is the conversational patterns between website and payment apps - when you call the API, is it possible to have a chatty API? A pattern where the website calls the API, or are you in a scenario where mobile is going to implement things - once data has been passed off to other app - it's quite possible that we may decide that's not how things should work.
<m4nu> AdrianHB: In general, agree - we're going to be focused on browser APi to understand constraints that we're working on.
<rbarnes> oh and also, i should have said: i think this arch is very good
<m4nu> MarkWatson: Newbie question, maybe - two very distinct patterns - API causes payment to happen - or on the other hand, the payment app passes credentials to payee.
<m4nu> MarkWatson: It took me a little bit of time to understand that - different models w/ different properties.
<m4nu> AdrianHB: We have said that what we want to build supports push-payments - payment app can make payment, response to website is confirmation.
<m4nu> AdrianHB: We do want what we build to support both scenarios.
<Ian> [Netflix use case: recurring payments, whether or not you are online]
<m4nu> markwatson: Netflix's narrow interest is in recurring payments, we want that to happen every month whether or not you're online.
<m4nu> AdrianHB: It's come up - this process - how is it going to support enrollment.
<m4nu> AdrianHB: In the card world, there are 0 amount payments to do authorization as a payer - we need to discuss how we work w/ those. Take the way it's done in cards today and replicate that - validation of the payment - requesting an actual payment.
<m4nu> Joerg: I think I said something like that in almost every meeting - what is a wallet - they tell you I want to have one and it needs to be neutral
<m4nu> Joerg: I hope we come to an agreement that we have something like that wallet - we can allow it to be an instance in the hands of a user. Particularly, when I look at the world as it is - it's full of different solutions, we may not have a say in many cases how the flows work.
<m4nu> Joerg: I hope we will find a way to propose a good way to do any style of transaction because we will have coupons / vouchers - won't fit into app-like thinking. This is what users expect. Things must go much smoother than what they go today.
<m4nu> AdrianHB: This is a level setting session - I don't want to get too deeply into this yet. Let's go through work on existing payment flows.
<m4nu> Zach: I think that during the demos - both flows are possible, during demos - make sure that we're answering questions.
<m4nu> Kris: With respect to recurring payments, you gave recurring payment instruction and bank executes.
<m4nu> MarkWatson: There are at least two models - bank does recurring payment, or merchant does recurring transaction.
<nicktr> http://www.npci.org.in/documents/Int_API.pdf
<m4nu> AdrianHB: Matt and the Flows Task Force have been doing quite a bit of work on payment flows.
<nicktr> https://github.com/w3c/webpayments/blob/gh-pages/Flow.Update.pptx
<m4nu> AdrianHB: Those have surfaced quite a few issues...
<wseltzer> [Dinner tonight: we have a reservation for 40 at Sens]
<m4nu> MattS: I've got a quick update on flows - this depends on how much all of you want to focus on.
<Ian> [Use case: Merchant has details on file and requests payment (one of the recurring scenarios)]
<m4nu> matts: Push/pull payments, recurring payments - there 3 use cases - merchant has card details on service. The fact that there are three use cases for recurring payments - push/pull - I contest that there are hundreds of use cases for payments, at least 10 for recurring.
<m4nu> Matts: Hi, Matt Saxon from World Pay - most of this work is of interest to all - it's focused on WG flows.
<m4nu> MattS: Going to go over objectives, progress, examples explorations, and then do questions from the WG.
<sloane_b> Is there a hangouts session?
<nicktr> https://plus.google.com/hangouts/_/google.com/w3c-web-pay
<m4nu> matts: Flows Task Force was kicked off for a specific reason, when we come to WG, we had a couple of specs, we talked a bit about architecture, how are we going to map the specs to real world situations.
<m4nu> matts: This is all up on Github - documented in the wiki - what are we aiming to do. specs and architecture are something for the future.
<m4nu> matts: We want to make sure the spec will be adopted, if we can't meet use cases, we won't have a successful specs - flows task force documents what is in use today.
<m4nu> matts: We talked around PISP and other things in PSD2 - not focus of flows... not specifically harmonization w/ ISO20022 for flows (but harmonization is important)
<m4nu> matts: So, point of the flows is to show examples - not to do thousands of real world flows.
<m4nu> matts: Even though we only have a small number of flows - if we have fundamental use cases, we need to document those. We don't need to document things that are not fundamentally different.
<m4nu> matts: You have the presentation in front of you, this is one of the flows. We use PlantUML as the modeling language. Top to bottom, sections on how use cases are laid out - negotiation of payment terms, second section, payment processing - they should all follow this model, but they don't all follow this model right now.
<m4nu> matts: There is a bit of a mouthful - we all have different terminology we're using - we use wording that's specific to WG first, then common terms, then ISO20022. All flows look like this.
<Ian> Links to flows (with links to diagrams)
<m4nu> matts: In terms of requirements - on 7th of January, we're going to have to pick a few flows - baselined suggested flows. There were less than 23 flows, but we modeled slightly less... 12 modeled
<m4nu> matts: I hope this gives us reasonable coverage for FPWD. We have started to standardize, but more work needs to be done there.
<m4nu> matts: They're in a place right now where they can be reviewed and applied to specs.
<m4nu> matts: We have a good chunk of people volunteering but need to know more.
<m4nu> matts: Some of the flows, what they highlight, first one - legacy card payments - many folks think that's easy, but have we adequately modeled recurring payments in the API - don't know if we have or haven't.
<m4nu> matts: The point about this is next phase explores mappings. Adrian went through architecture this morning, different players in architecture - we've tried to see how they map. At a simple level, top of flow is met by API, bottom is met by API, middle is handled by payment apps.
<m4nu> matts: I'm not sure that meets all of our requirements. I don't want to give the impression that we've analyzed to nth level of detail. I have questions / observations - mapping to flows - see if those concerns are valid.
<m4nu> matts: Any questions about what we're doing - why we're doing it - whether we should be doing it or not
<Ian> (Example: 3D Secure http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/Card/MerchantHosted-CardPaymentwith3DS-Current.pml)
<rbarnes> are the green arrows the ones that are in scope for the WG?
<rbarnes> like 2, 3, 4, 17 on this slide
<m4nu> AdrianHB: Along with use cases we have, they're valuable to figure out if we make existing payments difficult - it's one sides - at same time, we need to know motivations for stakeholders to implement APIs. If it changes business models - negatively - there is no motivation for API implementations. Flows are helping us assess that. We need to consider - any incentive for merchants/PSPs to implement
<m4nu> these things?
<Ian> richard, (I think the big bold line says "you are here in the API"
<m4nu> matts: We have a specific agenda?
<Ian> scribenick: Ian
m4nu: We are going to keep adding
to the flows.
... is it a goal to have a document with all the flows and how
they map to the specs?
<rbarnes> +1 to matt -- we need critical mass, not universal coverage
m4nu: Do we have data (e.g., from worldpay) on most-used flows?
<m4nu> matts: When we come to the end, we have 23 today - we could map them against specs, I don't know where we stop - there are perhaps other things to be done rather than increasing the number. I'd definitely like to do the ones that are documented.
<m4nu> manu: Could we pick the top 30? based on data?
<m4nu> matts: We have that data, we can talk about it.
<m4nu> matts: Do specs cover what we need - 3D Secure - 3D Secure is used quite broadly in UK.
<m4nu> matts: 3D Secure has been handed over to EMVCo - card industry payments standards body - further authenticating a cardholder to suggest that they are who they say they are. PSD2 - strong auth - 3D Secure isn't entirely strong auth, but it's a password. You go to merchant website, put in PAN and expiry, then you can say you want additional auth, go to issuers website, you get a challenge, you get
<m4nu> response - 8 character passwords. There are other implementations that do different things.
<m4nu> matts: If it's a transaction for $2 - the risk is very light... but there is more complex processing to see if it's worth prompting the user - if you're going to ship something to a physical address.
<m4nu> matts: If you're going to ship something to something other than billing address, you might want to pop up something more complex.
<m4nu> matts: APIs as I understand them right now, not very conversational - yes payment has been done, or not.
<m4nu> matts: The conversation in 3DSecure is "I'd like to make a payment", PSP says hmm, no, I need more auth, then customer gives more data.
<m4nu> CyrilV: 3D Secure depends on banks, some of them ask for birthdate, others may choose password, or biometric auth.
<m4nu> CyrilV: This model is very interesting - credit transfer PSD2 - I recommend that one.
<m4nu> Brian: One comment to add - strong auth could be implemented via 3D Secure - you could also have no auth - passive auth is allowed, you still go through the framework but it comes back and says no need to do anything for this particular transaction.
<m4nu> Brian: The point is that there is flexibility there.
<m4nu> Laurent_: 3D Secure is a good example of the separation in the way payments are done right now - for me - important for us - when we do the specs - we don't separate things in this way - requirement to add auth is regulation stuff - 3D Secure is a good example of not what to do.
Laurent: Be careful in API to not change who is responsible for what in flows (due to regulatory requirements, for example)
<m4nu> matts: I've heard 3D Secure is an interesting use case, Manu did you not do that on purpose?
<m4nu> manu: Ran out of time, but API does not support 3D Secure right now.
<nick_s> For the record, not *everybody* here feels that 3D Secure is universally a good thing
<m4nu> AdrianHB: 3D Secure is mandated in South Africa - bad design decision that neglected to think about online payments on mobile.
<m4nu> AdrianHB: User is not in browser, looking at app - browser window in app - may or may not render right sizes.
<m4nu> AdrianHB: It's a terrible user experience - not thinking about bigger picture - personally think 3D secure isn't going to be difficult to implement in our model - anything past initiation isn't supported.
<Rouslan> +1 to adrianhb that API is only initiation of payment
<m4nu> AdrianHB: Folks may use callback API - we can debate later, but that puts it out of scope - we need to consider it, whether it will work, technically feasible. Is it a good or bad experience?
<Zakim> AdrianHB, you wanted to mention some of the bad design decisions in 3DS
<Vish> EMVCo is working on a revision to the 3DSecure standard that will address most of the concerns Adrian raised
<nick_s> nicktr: correct me if I'm wrong, but *3DS itself* isn't mandated by the EU, strong authentication for payments is. 3DS is one implementation of that
<m4nu> matts: You could bend the API to meet this use case, so much is outside of it, streamlining checkout process may not be easy w/ 3D Secure.
MattS: I think that for 3DS so much is out of the API that we are not meeting our stated goal of streamlining payment
<nicktr> @nick_s - 3DS is mandated by the schemes, not by the regulator.
<rbarnes> i thought PaymentRequest was chatty, but about different stuff than 3DS
<m4nu> zach: I think we've know that our flows don't support 3D Secure - what we prioritized is getting payment credential back to merchants - that's what the proposal is optimized for by design. It's hard to fix payment industry - I don't want to get too bogged down w/ trying to support difficult payment flows. We can do much of this out of band, and that may be okay for first pass of API.
<m4nu> Zach: We've said it's out of scope.
<m4nu> AdrianHB: Anything beyond initiation is out of scope - not saying there is consensus on that - that's my assumption.
<m4nu> AdrianHB: If folks disagree, we need to know.
<m4nu> Zach: You can do 3D Secure, you are not precluded from using payment request by using 3D Secure.
<Vish> Authentication via 3DSecure is always optional for merchants, who may not want to incur the friction and loss of conversion
<jheuer> The API should not stop 3DS from being executed, but could show a 'better' way, while allowing 3DS to be implemented outside the API
<m4nu> CyrilV: Another point I want to mention, when reading docs - french 3D Secure, they are compliant - French community adds some info algorithm, type of auth, not only token to say check mark, don't know if this is mandatory - what from a security perspective - maybe it's something for security people to consider. What are the types of algorithm - community that has been doing this type of systems
<m4nu> for years - consider that in design of API.
<m4nu> matts: One other example, tokenization - not going to try to define it - PSP tokenization - different from what we talked about w/ Vish. You called it about scheme tokenization - PSP tokenization is what I'd like to talk about here.
(PCI compliance)
<m4nu> matts: If you send card details to merchant in the clear - under SSL - but they get to the merchant and those card details are there, as soon as merchant has those card details - PCI-DSS IS UPON YOU
<AdrianHB> +1 to Cyril's point that we should consider the possibility of returning details about how the user was authorized in the response
(PSP tokenization is "on the fly" -> merchant->PSP->merchant->browser)
<m4nu> matts: That burden is pretty onerous on small merchants - trying to remove that burden, not the only game in town, scheme tokenization, network tokenizations, industry has evolved. PSP have evolved, token is generated at registration time, done in a Just in Time fashion. Merchant's client-side code sends PAN across PSP for tokenization on the fly. Token is supplied in milliseconds for merchant.
<m4nu> At that point, token can be stored for recurring transactions, reporting - refunded - you can use the token for a lot of stuff. When you do that, you have less of a burden for PCI standardization - you need handshake - code running in browser, code running in PSP
<m4nu> matts: My assumption about registration is registration is going to be mediated in the browser, I'd like to make payments around that payment app - client-side PSP - PSP tokenization is invisible to the user - but also done by lots and other PSPs. Payment to merchant, visa branded payment - they don't know how PSPs are in the flow - don't know how client-side code is injected to assist with these
<m4nu> mechanism.
<m4nu> matts: There is code that is coupled between the client in the browser and code that is running in the PSP's web server to figure out how to negotiate how PAN works - payment app registration is driven by user app registration, registration is done by user
<m4nu> matts: PSP is merchant-centric tokenization - we're moving to user-centric model.
m4nu: With the CG specs, we've
looked at this. There's a part where the app is registered by
the user, and when you make a payment the app is
instantiated.
... but there's another flow where the merchant says "I want
you to use this payment app"
... but at that point, we don't know how the user payment apps
will communicate with merchant-provided payment apps
<m4nu> manu: @Manu: We don't support this stuff in the WPCG spec right now, we could, but difficult.
<m4nu> matts: matts: Ok, so we need to pay attention to that.
<m4nu> Zach: is this an issue? I'm not sure - you can do this via the API, but you end up w/ a lot of problems.
<m4nu> matts: I think this is an issue, this is an example of a deeper issue that we can talk about later.
<zkoch> What was the other name of this? Silent post?
<m4nu> nicktr: Do we want to support this in V1? it's a question.
<m4nu> Rouslan: Android Pay is payment app, integrates w/ Stripe - android will request PSP token - I think what you're talking about is possible - Samsung Pay is done at point of registration, not just in time.
(Issue: tokenization at registration v. tokenization at run-time)
<m4nu> NickTR: True for stripe/braintree, not for anyone else.
<Zakim> Rouslan, you wanted to explain tokenization in android-pay, which is client side, but actually communicates to Stripe, which is the PSP.
<zkoch> @nicktr: Did you call that silent post?
<nicktr> yes - silent order post
<zkoch> thanks!
<m4nu> nick_s: I guess I'm not seeing where PSP tokenization fits in - transparent to user today, happens in the payment app - so payment app isn't plugged into PSP - or merchant does something they've received - are you suggesting that PSPs could implement their own on-demand payment app.
<m4nu> matts: Wrt. PSP tokenization - here's a use case that exists today, this is being used today, do we not need it anymore? If we do need it, how is it done in the API.
<m4nu> nick_s: I think we need it - but in future land, everyone tokenizes, so we may not need it in the end.
<m4nu> matts: We need to focus on answering whether or not we need this.
<m4nu> matts: Hopefully this has been instructive. Second one was complex - people do understand it, but difficult to answer question.
<m4nu> matts: Question, please answer in IRC.
<Vish> PSP tokenization is a pretty critical function as many merchants are using it to mitigate their PCI risk
<AdrianHB> Specifications+
<nicktr> specifications+
<rbarnes> UseCases+ (Requirements+)
<rbarnes> (which is effectively Specifications+, one layer abstracted)
<m4nu> matts: What should task force be focusing on? Increase flows? Refine flows? Review specs against specs? Take highlighted issues in flows, go back to core docs. Don't know if some of the things are covered -
<zkoch> Specifications+
<m4nu> manu: Focus on finalizing flows first, then apply those to specifications (after FPWD)
<m4nu> Ian: Keep refining, apply to specs, seems like that's productive use of time.
<m4nu> matts: What are the most important?
usecases+
<Laurent_> Specifications+
<nick_s> Sorry, is it not worth delaying this vote until after the full F2F?
<markw> My vote is for whichever one will advance support of recurring payments
<m4nu> manu: Refine+ Specifications+
<GregoryE> UseCases+
<Rouslan> Specifications+
<brian> Specs+
<CyrilV> specifications+
<tarcieri> Specifications+
<jyrossi> Specifications+
<adamR> UseCases+
<Roy> New+
<m4nu> matts: About how it's being conducted today - we haven't posted lots of updates, haven't posted to mailing list - back to git - is that too closed?
<padler> New+
<Leandro> new+
<Ryladog> Refine+
<m4nu> matts: I have trouble keeping up w/ emails - we have it to the point where we can show what we've done - daily weekly, monthly basis. Do we start posting to main group - evolve on a daily basis.
<mountie> Specifications+
<ShaneM> Refine+
<Ryladog> +1
<Rouslan> Bring it In -1
<rbarnes> BringItIn-1
<VincentK> Specifications+ ISO20022+
<kriske> Refine+
<zkoch> -1
<Roy> Bring it In +1
<deganon> Bring it in -1
<Roy> Flows+ Roy
<nicktr> bring it in +1
<ShaneM> bring it in -1
<padler> Bring it in -1
<Laurent_> Flows+ Laurent
<m4nu> matts: Who wants to be more involved?
<jheuer> bring it in +1
<Ryladog> Bring it In +1
<kriske> Bring it In -1
<VincentK> Bring it in -1
<deganon> Specifications+
<Erik> Specifications+ ISO20022+
<rbarnes> the value of this is to say what we need in the browser API. the WG needs them to aggregate the use cases and summarize the requirements
<mountie> Bring it In +1
<m4nu> AdrianHB: One of the values of this group - WG is unique in W3C, huge number of people in this group are not traditionally involved in W3C work - they don't feel comfortable making updates to specs - real world insight - spec is sensible, they want to help w/ that. Flows are useful in connecting those two groups of people. Payments industry folks in group - technical spec editors understand how
<m4nu> payments work. Flows work helps w/ that.
<m4nu> AdrianHB: If people feel like they're not going to be contributing from a technical standpoint, flows task force - regarding open/closed groups - task force isn't closed, you don't need a special secret handshake to join, but those calls are separate.
<brian> flows+ (but need to confirm availability)
<m4nu> AdrianHB: If you want to join, you can join - every Friday, enough folks from timezones, we'll hold them at some other time.
<m4nu> BREAK BREAK BREAK!
<scribe> scribe: Ian
<VincentK> +1 for Adrian - we need more people to validate correctness of the flows
<wseltzer> [break for 1/2 hour, reconvening at 11 PST]
<zkoch> PaymentRequest docs: http://wicg.github.io/paymentrequest/
<wseltzer> [returning]
<nicktr> scribenick: nicktr
zach: two motivations for this
work
... 1. it's too difficult to use the web for payments
... 2. it's risk to move card numbers and other credentials
around
... we think the browser can be leveraged to improve the
experience
... and browsers are native apps
... the browser becomes a proxy
... 1. leverage information in the browser, and 2. browsers are
more powerful and are special apps
... this is important to send a message to developers that the
open web is an important platform alongside native apps
... high level architecture
pass in:
scribe: 1. payment methods
... 2. shipping information
<Ian> [13:09] <Ian> scribe: Ian
<Ian> [13:09] <Ian> (Demo from Zach and AdrianB of payment request)
<Ian> [13:09] <Ian> https://github.com/WICG/paymentrequest/blob/gh-pages/docs/rationale.md
<Ian> [13:12] <Ian> (Zach on rationale for the API)
<Ian> [13:12] <Ian> * better user experience
<Ian> [13:12] <Ian> * better security
<Ian> [13:13] <Ian> ...also a strong message to merchants...same experience for users wherever they are
<Ian> [13:13] <Ian> http://wicg.github.io/paymentrequest/specs/paymentrequest.html
<Ian> [13:13] <Ian> Payment Request API
<Ian> [13:13] <Ian> ...four arguments to the API
<Ian> [13:13] <Ian> * Supported methods
<Ian> [13:13] <Ian> * Details about the transaction
<Ian> [13:14] <Ian> * Payment options
<Ian> [13:14] <Ian> (e.g., shipping info?)
<Ian> [13:14] <Ian> * Scheme-specific data
<Ian> I have been on the wrong channel
<Ian> scribe: Ian
zach: Browser computes
intersection of accepted and user-registered apps, and presents
list to user
... user chooses one
... blob of data is passed back to the merchant
... shipping is optional
... the API is simple today...can be expanded to include other
features
... e.g., related to loyalty or other things to reduce drop
off
... today we want to address the many cases that involved
things like cards, and then grow
adrianba: Here's how we've structure the proposal...then I will do a demo
-> http://wicg.github.io/paymentrequest/specs/architecture.html Architecture
-> http://wicg.github.io/paymentrequest/specs/arch.svg architecture diagram
adrianBA: Central notion is "payment method identifier"
(first argument of payment request API)
")
Think of payment methods as what you see on stickers in stores: "We accept Visa!"
scribe: when you get the blob of
data (after user selection)
... the set of data needs to be standardized for a given
payment method
See response data proposal for credit card payments;
http://wicg.github.io/paymentrequest/specs/basic-card-payment.html
<nicktr> q
mountie: What about registration
of native payment apps?
... What about auto-registration of payment apps?
zkoch: Registration is only early
proposal; that will change; lots to discuss for now
... including today the registration document I published is
just for the web
... I think different ecosystems will have their own
requirements (e.g., intents on Android)
... IOS will have a different view of how registration will
happen for native apps
... I expect Google will say more about how registration will
happen with native apps
... I imagine browsers will bootstrap some support when there
are no payment apps; that will be up to the browsers
demos:
http://github.adrianba.net/paymentrequest-demo/
http://github.adrianba.net/paymentrequest-demo/demo-simple.html
(We walk through the code)
adrianba: The data you get back
in the response is payment app specific (e.g., card info, or
token, etc.)
... page uses that information to process the payment
Demo with request shipping address
http://github.adrianba.net/paymentrequest-demo/demo-shipping-free.html
Example: request shipping address and calculate shipping options
http://github.adrianba.net/paymentrequest-demo/demo-shipping-calc.html
adrianba: The API allows handling
of shipping either through callback or event handler
... demo shows use of callback
... The demo shows a 2-second delay to simulate a network
call
... See card payment spec ->
http://wicg.github.io/paymentrequest/specs/basic-card-payment.html
... three pieces of info:
* What identifiers does this app respond to?
* Any payment specific data needed for the fourth argument?
* What does the response data look like?
adrianba: We might need a billing
address in the card payment API
... one reason we thought that it's useful to include shipping
address, is that we probably have to solve for billing address,
so maybe we can use the same solution for both.
... punting on shipping address to not deal with addresses may
not be helpful in the end
nicktr: Let's go 15 mins
<m4nu> +1 for spending as much time as we need to to understand the proposals.
shepazu: Is it onerous to not use a call back?
adrianba: There are so many ways
to do shipping, you need this approach
... we support the ability for merchant to say "I don't support
shipping for that"
<Zakim> m4nu, you wanted to ask what happens when merchant doesn't get back to paymentrequest?
m4nu: There's a point here where
the merchant site hands control the browser, and where the
browser hands control to the merchant site.
... what happens when merchant doesn't get back to the
browser?
... did you look at ways of building the API so that doesn't
happen? Either response is "immediate" or "not at all"?
adrianba: We have an open issue
on how to address that question
... we've looked at solutions like a "time window"
... or where sites can request more time
... I'm open minded about how we approach this...we'll probably
need something that says "something has probably gone
wrong."
... but it should always be possible for the user to cancel out
of the request
<Zakim> nicktr, you wanted to ask what would happen if the payment app was another web app
nicktr: if the payment app were another web app, how would we pipeline the changes through.
zkoch: We don't. We don't hand
off to a payment app until we have a final amount of
money.
... in our API, the payment app cannot do shipping
nicktr: Suppose we look at Visa
Checkout as a payment app
... as this is currently proposed, you would see Visa Checkout
as an option
... you finish the shipping changes, and then you select Visa
Checkout and hit authorize, and you MIGHT get another
experience from them about choosing.
zkoch: This becomes a platform question...you go to the domain of the payment app...they do whatever they want, then go back to the browser, then back to the merchant
nicktr: My concern is that you can have poor user experience because you are daisy chaining them
zkoch: We should have a separate
conversation about registration
... there are some issues about third party registration
... there is an assumption here, which is when a merchant
accepts a method, it knows how to handle the response
adrianhb: I think the demo needs to show other payment apps than cards.
zkoch: Complicated due to registration...needs more discussion
adrianhb: To be clear, the UI the demo shows is browser UI. When I pick a payment app, there is still potentially payment app UI that will appear.
zkoch: Correct.
<adamR> Is there a floor mic that people can use?
<adamR> It is very hard to hear the conversation on the phone
adrianhb: One question I have is when is the browser UI torn down
zkoch: Our UI is torn down after you call complete....but for even more certainty, you can be sure it's been torn down when you get the resulting promise
Laurent_: My first question is
close to Nick and Adrian's comments...how do you hand over
control to payment app to participate in the response
computation?
... e.g., in many cases you have to authenticate the user
... how is handover done to payment app
... my section question: you have a detailed list of items with
prices
... but this item list is not related to payment method.
... we did discuss some use cases where price or amount might
vary according to payment app
... is there a way to tie this list to the payment method?
zkoch: First, I have a broad statement...registration spec just published last night speaks to some of this but also is very open for discussion
<nicktr> https://github.com/WICG/paymentrequest/blob/gh-pages/docs/registration.md
zkoch: we'll get feedback and build demos
adrianba: I think on the question
of "how a payment app works" my view is that there are a lot of
platform dependencies
... at Microsoft we are working on an API platform called
component UI (bring apps into the UI of other apps)
... so the experience would be "in the same app"
... I think different platforms will work in different ways, so
we are trying to not be too prescriptive about UI
... regarding currency...we've discussed ways we've might make
that work
roy: have you taken tax into account?
zkoch: Line items is very
generic
... you can pass in whatever you want regarding taxing...when
you changing shipping you get an event to update the list
items
... the browser should not take a stance on how tax should be
computed?
<CyrilV> @Ian: what was your question ?
Roy: Is tax info part of the app list?
zkoch: Don't know yet
mountie: Normally data is generated on the merchant side
<dezell> I would suggest that taxes be part of the up-coming e-Commerce considerations.
mountie: how is data integrity checked?
zkoch: the assumption we have is that the last thing you pass in is the final amount
<Roy> Questions I just asked: how would taxation be handled? There are situations where the taxes charged are dependent on address, tax id info or even the payment methods and currency. And where would collection of the customer's tax information be in the flow?
zkoch: we'll design the UI around that amount
<dezell> Especially the calculation and verification part. Passing a precalculated tax up is fine (for now).
mountie: My question is - how do you protect the data from the merchant so it is not compromised before payment?
adrianba: What anti-tampering
mechanism is there...the way we propose to solve for that is
based on the payment method
... the only example we have today is returning the card
information...once that information is returned to the web
page, that goes back to the merchant and "could still be
tampered with"
... but for more sophisticated payment apps, we would expect
something in the response to map to the amount in the
request
<Zakim> ShaneM, you wanted to mention that user cancellation is sort of scary
adrianba: but this is in the purview of the payment app and the respective payment method
<shepazu> (mountie, the merchant gets back an amount that's been authorized, so the merchant can check that against the amount they want to charge)
ShaneM: I think we need an error handling mechanism to give user feedback that _payment did not happen_
adrianba: I think that's a great place for implementations to compete.
kriske: Regarding interop....the
specs define data items
... ultimately these will be used outside the payment
domain...whose responsibility will it be to turn the data into
something used in a given payment system?
... where is that integrity addressed?
adrianba: I think that the
information that comes back from the API will be defined in
some specification (e.g., we have the basic card spec)...there
will be different specs for different kinds of payment
methods
... at some point if the merchant web site creates a request
that is not a valid amount...they won't sell a lot
... we have to put some onus on merchant to get it right
kriske: You can avoid that by setting expectations about what format and structure is required
adrianba: Something that varies by provider is not likely to be something that we standardize.
adrianhb: We are chartered to do
a card spec.. I think we will see this sort of spec in the
wild
... and it would make sense for an organization like ISO20022
RA to say "here's how you can do traditional transfers"
... we're going to provide the framework.
<Roy> I'm wondering what apis there are for querying about the status of payments? Consider network cutouts during charge, or more simply asynchronous payment methods. How would the merchant expect to inspect the status of payment in these events or would that be something handled by payment methods implementations?
adrianhb: but beyond cards (an example of how to do this), I don't see the WG doing this (unless strong interest in generic mechanisms)
jheuer: The idea of the
registration of the payment app...we solved this problem with a
simple system...we allowed parameterization of apps, and the
app registers instruments
... I recommend implementing a way where the user has a "plain
view of instruments available"
... whether they are provided through an aggregator or second
level wallet
... that would simplify the user experience
... also, take pains to not foster a new UI for each payment
instrument
... try to create one look and feel and then trigger those
instruments
... in the end, that's what customers appreciate
... if you wander off into different styles of handling things,
the value we can bring is rather limited
... regarding taxation, I could see publishing a transaction
identifier, and then enabling a series of back and forth
negotiations around that identifier
[Manu now does demo around the CG proposal]
<nicktr> [Manu's computer is still rebooting]
<nick_s> If Manu is looking for a new computer, the Apple Store in Union Square is open late tonight
<nick_s> Happy to extend my employee discount
Manu Demo
-> https://docs.google.com/presentation/d/1ckU7ZJWmKqtbygAgN2BZhx6aT1fYe6DZsS_WntJ8UK4/edit
manu: This proposal from the CG
includes 2 specs
... high level checkout API
... lower level payment API
... payment API is payment primitive, checkout is higher level
involving flow
[Payment API]
scribe: Minimum viable API...no
notion of cart or checkout
... supports registration, initiating a payment, selection a
payment app, receiving an acknowledgment
[Shows demo]
scribe: this demo uses a polyfill
that is on github
... the poly is running on web-payments.io
... we'll review payment app registration, perform a
payment
... and show both push and pull payments
... keep an eye on how the URIs change...we simulate moving
between sites by updating the URL
Register a payment app
https://web-payments.io/first-pay/register
when you click on "register" the "payment mediator" pops up (cf the architecture)
(Manu reviews data sent during registration process)
manu: The "url" is the one used to initiate a payment
(Manu registers NextPay app)
https://web-payments.io/next-pay/register
(manu registered bitcoin payment app)
https://web-payments.io/bitcoin-pay/register
Manu then does a payment with each one:
Click on "pay" (on simulated merchant site)
scribe: three payment apps are displayed
manu chooses card option...which generates a payment request
scribe: there are no line items,
etc....just amount and currency
... and accepted payment methods
... the merchant site then gets a payment acknowledgment, which
includes something like a status and approval code
... and data about how much was paid and in what currency
(Manu then shows more secure option NextPay)
scribe: note the message coming
back to the merchant has a digital signature
... this is an example of a payment-method specific piece of
data handed back to the merchant
... the payment scheme can add extra data in the response
... this particular demo shows digital signature as way for
merchant to have greater confidence that the transaction was
not tampered with
(Manu shows bitcoin payment demo)
<AdrianHB> zakim open the queue
manu: We want to demonstrate
flows (via polyfills)
... to show that the API works
brian: When you went through registration, you didn't show how to provide the payment app with relevant credentials.
manu: that's true, I was just
showing the data passed through the API, not the UI of the
payment app
... e.g, person enters card info into the payment app (which I
did not show)
Laurent_: I like the fact that
you have an extension mechanism. You indicated that the payment
method extended the response
... it seems to me that it's the payment _app_ that's extending
the response, not the payment method
... I think Visa Checkout would be a better example
Roy: A common flow is to provide
coupons
... you could register your own site as a payment app for
coupons
... have you thought about chaining them together to allow
partial payments to a transaction?
manu: The way we are thinking
about coupons is through a different API (verifiable claims
work)
... this API does not address the e-Commerce stuff...we have
thought about chaining things together but the User experience
was not good
... you want to have a synthesized user experience
... but that's more the realm of checkout API
zach: The limit of registration
is that you are origin-bound
... either the browser is there to "break the origin" or you
need the merchant and payment app provider to have a trusted
mediator.
manu: Yes
zach: I think we are very similar
in how we are thinking about registration.
... note on challenge of indicating payment method
... suppose the payment app says "I support X, Y, and Z" but
the user only has Z, and the merchant accepts X and Y and
Z
... so it looks like there's a match but in fact the user
doesn't have that payment instrument
manu: We haven't thought through
that.
... There is another topic about distributed registration of
payment apps
... if we do payment app registration, all the payment apps are
bound to the software you are registration with
zkoch: Use manifest files. They
can be linked externally.
... when you export to a browser, you just need to export URLs
and other browsers can then reuse the same manifest files
manu: Benefits of the API
* Layered approach. This API just handles payment
* Enables checkout to evolve independently
* Can be used by merchants that want their own checkout flow
scribe: some may not want the
checkout experience in the browser
... there are large retailers that pride themselves in how they
do checkout
... or reinforcing their brands
... to be fair, I think you can invoke the payment request API
to do something similar
* Very small API surface but big upside for payment networks
scribe: we haven't done so yet...there are, I think, two groups of people in the WG now:
1) those that want to improve the user experience at checkout
2) those who want to integrate new payment networks
* Extensibility via JSON-LD (one clear story, not the only story)
(We look at the code)
http://wicg.github.io/web-payments-browser-api/ED/2016-02-19/#payment-app-registration
(Registration code)
Initiating payment -> http://wicg.github.io/web-payments-browser-api/ED/2016-02-19/#processing-a-payment-request
Ack -> http://wicg.github.io/web-payments-browser-api/ED/2016-02-19/#generating-a-payment-acknowledgment
Manu: Payment request is executed
on the merchant side
... you end up being pushed over to the payment app side
<nicktr> Ian: @@@@11672
<rbarnes> API design point -- please please please don't use promises to pass events. the droid you're looking for is MessagePort https://developer.mozilla.org/en-US/docs/Web/API/MessagePort
<nicktr> Ian: 2 different methods are called "get" and "acknowledgment"
adrianba: I think the name "ack"
is confusing
... it's really more like "response"
... I would have shown a bitcoin example....
... and compared with a visa payment "here's the card
number"
manu: +1 to our updating the examples
<Zakim> Ian, you wanted to ask about whether dictionaries could be used and to ask about need for the acknowledgment method
<Zakim> AdrianHB, you wanted to suggest the example is confusing because it uses cards which are traditionally pull-based
Manu: We've put some flows in the
spec
... and we show what the code would look like on the merchant
side
... we map it to the steps in the flow
... we wanted to verify that we could achieve the flows with
the API
... the pattern looks similar across flows, which I think is a
good sign
... typically what is changing is the data you see in the
response
{The Checkout API]
* focuses on shopping cart; uses the payment API at the end
* supports:
- initiating a checkout flow
* Line item display
* shipping address and option
* requesting and acknowledging payment
scribe: this API intends to support the same things as the google/microsoft proposal (and if it doesn't that's a bug and we should fix it)
* benefits of the API....streamlined, enables more secure.
scribe: some people have raised
concerns about being too prescriptive in checkout flow
... another concern that is more troubling for me, is that we
may be codifying shopping cart abandonment problems
... number one reason is "shipping cost was more than
expected"
... the advice that a lot of people who build these sites is to
be sure to collect shipping address way before people start
putting things in their shopping cart.
... that helps reduce surprises
... gather the data early in the process
... problems happen when you don't collect shipping information
near the front of someone starting to check out.
<kriske> great idea for improving the ux!
scribe: so the question is should we have another primitive for gathering shipping data before payment starts?
(Checkout API code)
Simple flow: http://wicg.github.io/web-payments-browser-api/ED/2016-02-19/checkout-api.html#simple-checkout-example
checkout
manu: the protocol with the
browser is a "requesting information dynamically"
approach
... there are send and request functions
... send() gives info to browser to display
... start() starts a checkout flow..
... then up to the browser to collect that information in the
best way possible
... then finish checkout which creates a payment request using
lower level API
<VincentK> Why not request to register the shipping information, to provide upfront shipping cost/delay even before the check-out ?
zkoch: Suppose I have a digital good...the expectation is that people will call the payment API, not the checkout API, right?
manu: The argument that we are
making is that developers will understand which API to
call
... they could also wrap it in a checkout API call
zkoch: Suppose I'm a game
developer, who sells both physical and digital goods
... I have a concern that we are going to ask developers to
switch in their checkout flow depending on the nature of the
goods....rather than calling the same API all the time, and
passing it information about what functionality is
required.
Manu: We could address that by
saying "just use the checkout API"
... I am concerned about the amount of complexity and getting
it right
... so I prefer starting with the smaller primitive and getting
it right
... or other orgs might innovate using a lower level API
markw: From Netflix perspective,
each step in enrollment leads to drop-off.
... the more you have very primitive operations that enable
people to compose, you can do more useful experimentation
... regarding the user interface expectations, I think for this
expectation, merchants are likely to want some assurances about
what the user interface does (e.g., confirm payment has
happened)
... that will make merchants feel safer about using the API
<AdrianHB> (Manu shows slide displaying key differences)
<Roy> Is server-side integration with payment providers within the scope of working group? All the demos are focused on client-side, but many async or push payment methods require significant followup action by the server. If a goal is to streamline and outsource support of various payment methods across devices wouldn't it be necessary to provide guidelines on how to followup on payment status?
<wseltzer> [break until 2 PST]
<inserted> scribenick: nick
Stefan: Presentation about interledger, use cases, there will be a demo portion
Stefan: Made demo last night,
presentation this morning [excuse the roughness]
... What is interledger? Payments work well as long as you go
across systems
... But breaks down when you go across systems
... world will never agree to use a single ledger
... We need an open protocol for interledger payments
... Open protocol for payments gives everybody reach
... Neutral, fit to build into standards. Other standards are
abstracted but built into this standard. Also universal.
Doesn’t prescribe the ledger you must use. Anybody, any
currency, any country
... Applied to the web payments use case - consumer has a
relationship with a financial institution, as does a
merchant.
... Merchant initiates a payment agent to the user agent. User
agent notifies currently selected payment processor there’s a
pending request
... payment method checks with the user if they want to approve
a particular payment
... Payment approved, that completes the flow
Demo follows
Stefan: If I click “Set as default payment provider” a permission dialog is presented
<zkoch> …i’ve since changed my mind on iFrames (again)
<zkoch> #flipflopper
Stefan: Would be useful we think
if the status (default or not) of an instrument could be
surfaced back
... let’s move onto another ledger. Completely different
payment method/scheme. The payment will instead go through a
peering arrangement between mulitple providers
... the front end here is similar to what you might find at
Stripe, etc…a simple piece of JavaScript with the pieces needed
for payment
... so this code generates a button which shows the payment UI.
It’s prefilled the recipient and the amount
... and we also need an account identifier. We’ve had some
discussion over what the account ID should be. Right now it’s a
URL
... OK, so this code is generating the right payment data now.
I want to show off a payment.
[Two websites are side by side, each requesting a payment from a different scheme]
scribe: so now I want to do an
interledger payment. I don’t need to worry about payments not
matching. Rather than doing the interledger on the web payment
level if interledger was included inside the web payments API
then interledger could handle this. The discovery and peering
process could be automated away by interledger
... when I’m ready to send it will go through, so I’ve paid $10
dollars on Website A
... but on Website B I got a little less, that’s because some
of the interledger providers along the way took a cut
... but I can also specify exact amounts, and the fees can be
charged on top
... why should WPWG care about interledegr?
... today I have a relationship with my financial institution,
the merchant might have a different institution, and today we
look for a match
... and if there’s no match the payment doesn’t go through. So
rather than failing the payment, with interledger if both
schemes support some kind of escrow we can make the payment
happen
... another case is wallet mobility
... for example, credit card expiration.
... and the solution is often to embed it in the wallet instead
- for example, PayPal has an interface for subscriptions
... but this makes switching wallets very difficult.
Interledger shifts this perspective.
... so if I want to switch Wallet providers I could use
interledger for this.
... the wallet app is just something I add to that / plug in to
that
... this graph is no more complicated than what we’re normally
going, it’s just a longer path
... it also means if I want to sign up with multiple payment
providers that use different methods I don’t need to worry
about which one I select
... ultimately I want to pay with whatever is cheapest / most
advantageous to me. And although those rules might be quite
complicated (reward points, etc) I can pick a wallet provider
that encodes those rules
... we want to build standards that aren’t necessarily thinking
about that but are at least future proofing such
applications
... finally, let’s look at device payments
... when you have devices paying you run into similar
situations. We don’t want to treat payments like pyramids, but
as a flat path which can take any route. All ledgers are just
accounting systems that track balances
... so here’s an effort Google is leading, called Physical Web.
This caught my attention as it had a payments
implementation
<zkoch> Physical web: https://google.github.io/physical-web/
scribe: that’s really nice, but
it’s payment provider specific. If I’m traveling maybe I can’t
use my regular payment provider. Efforts like this build on
existing schemes with aren’t necessarily extensible
... all of this can be solved with a graph like ledger
... here’s the last part of my presentation, I think I went a
little bit fast [Scribe: my keyboard is on fire]
... currently with smart devices the way I’d set payments up is
generally insecure or ad hoc
... either the device has some kind of limit, which is
basically accounting, or it has unfettered access to my account
(insecure)
... so if I do that I’m essentially creating another kind of
ledger
... if we think of everything as a standardized ledger then I
can get deeper insight into how the money across all of my
smart devices is being used
... and it doesn’t matter where it went to be processed
(PayPal, another provider, etc), because there’s a central
point / ledger
... you can even break it down further
... if, say, my smart washing machine has a ledger and it uses
TCP/IP then the device itself may have a ledger, and the
components of the device may also have ledgers
wseltzer beat me to it
Stefan: Deep nesting also
possible - other users and individuals with accounts
... today we do this manually, but in the future we could
coalesce with a routing algorithm
... that’s where standardization can come into it
... so if you’re interested in this, the 1st interledger CG
workshop is this Thursday
... check out our site at interledger.org
manu: does this have to be the interledger protocol?
Stefan: I would like to build
something that at best implements this and at worst doesn’t
block such work. There isn’t a whole lot the browser needs to
add to pave the way for something like this.
... if we can solve registration in a way that I can register
for the scheme interledger that isn’t tied to anything and you
can send a request to that scheme as well we can solve that
problem
AdrianHB: No more questions, but
that’s what I think the transition would be - interledger will
be a payment method, and if it’s successful people will stop
supporting other payment methods as interledger would correct
them
... it’s a payment method that doesn’t have a scheme owner
<Zakim> m4nu, you wanted to ask where the interledger stuff fits into the UI flow?
Stefan: there’s some central
source of truth somewhere, some ledger you can go to like
bitcoin
... the issue with interledger is there isn’t a finite network.
the network can potentially be infinite
... so pathfinding becomes less deterministic, but still
practical
... whenever we’re designing just keep in mind whether anything
is blocking this
padler: one of the things I
wanted to talk about, it looks like the registration process of
accounts…seems like that might be fairly important, if you’re
talking about the use cases when you’re switching between
multiple wallet providers. Some kind of collective standard /
format about the details of those?
... that’s not something we’ve dealt with so far, we’ve dealt
with the use of the payment instrument
stefan: One thing that I want to
be clear about - you can think about these use cases in a very
complicated way
... it can seem very hard to the point of being almost
impossible
... but the realization here is all of these things are
essentially ledgers
... they will have common elements like balances, fund
transfer, authorization, etc. We’ve tried to narrow down the
interaction between ledgers to its minimum components
... for example, we’ll need a balance transfer. We just need to
standardize the simplest, most common ledger protocols
... more complex ledger specific functionality is left out
padler: if you think about requiring a common way to do escrow….if we were going to standardize that you’d have to have a way of requiring that as a base primitive. You’d need to know that the wallet adheres to the interledger spec. Will there need to be communication of that?
stefan: Correct - I think the
first major piece of work the CG will take on is this. Most of
the work has been done by NIST, we think
... that’s a very basic solution though, there are some
arguments for more complex solutions.
... it’s outside of the charter for the WG, so I would focus on
something like “if interledger was supported what would it look
like”
AdrianHB: think we’re out of time here
padler: just thinking about where the IG heads from here
AdrianHB: So I took a stab at
this, it demos a couple of ideas I had for payment apps
... let’s assume you’re on Megastore.com, and you hit buy
... then some UI pops up. It’s not web page UI - it’s something
that the user agent is presenting
... intention is to finalize the price first. Pick an address,
pick shipping options, you’ve finally got a price and then you
continue
... it’s still the same UI, same native box provided by the
browser
... you’ll notice the similarity here with what Manu showed,
the price is shown next to the payment instrument
... this is a point we need to discuss
... do we need to be able to specify a price per payment
method?
... trade off and complexity here, something to think
about
... I’ve got four payment app examples here. This is still all
user agent UI
... so here’s an idea where you might have something like
loyalty points, there are different ways to pay built into the
app
... in this case the payment app is provided by Megastore.com,
so they’re going to incentivize me and give me discounts
... I have a question around registration related to this - I
see an incentive for big merchants to add their own payment
apps
... but it’s only useful if merchants know their payment app
has been selected
... but maybe if you’re able to check whether your app is
there, Yes or No, maybe there isn’t a privacy problem.
... anyway, we authorize and now I’m back to the website, the
user agent UI has disappeared
... if I follow the same process this time I’ll use a bank
issued payment app
... this app gives me a choice of several ways to pay - card,
direct debit, etc
... in this instance the app wants me to use an OTP to
continue, the payment app authorizes the payment as well
... that’s one approach to the 3DS question raised
earlier
... this is interesting as it’s multi currency. This time the
payment app has a range of prices, because the app supports
different methods with different associated costs
... starting to head down a road with many scary complexity
issues, so something to think about
... this app supports both dollars and bitcoin, with different
prices
... last payment app, this is a very simple app which abstracts
everything away
... it has some advanced authentication with another
device
... I’m going to speed through the payments flow on mobile,
it’s very similar
... again, UI is native
... same UI, list of apps that can deal with (in the case of
Andorid) intent
... once I pick the app on mobile this could take me to a whole
new app, once completed I switch back to the browser
<Zakim> m4nu, you wanted to ask if merchants can do price differentiation - some merchant contracts don't allow merchants to show price differences between card schemes?
AdrianHB: so a few ideas to stimulate some conversation
m4nu: so with price differentiation…not sure if this is still a thing, but do we need to pay attention to card contracts / restrictions?
AdrianHB: not sure, don’t think
it’s the case any more
... let’s put that in the reasons why we shoudn’t show the
prices box
<Zakim> nick, you wanted to ask about merchant payment apps
nick: not just merchant apps, how about payment instruments jointly issued by merchants / banks (co-brand cards, etc)
AdrianHB: not really a discussion we’ve had at all yet. More to come
<Zakim> Rouslan, you wanted to say exact UX is a good place for web browsers to differentiate, compete, experiment, and incentivize, so let's concentrate on the JavaScript APIs instead.
Rouslan: this is interesting, we shouldn’t expect browsers to agree on UI. It will be a point of differentiation / competition
AdrianHB: You can differentiate
to a point, there is a flow that will need to be followed
... It’s difficult today…we should be careful about designing
something where we don’t consider constraints, say, on mobile
because we think those constraints will go away
wseltzer: that was very helpful and called up lots of issues - like the privacy considerations, will people be comfortable with differentiation in UI.
AdrianHB: My feeling is we should
start by talking about the constraints of payment apps
... Let’s say I visit my bank’s website and install their
payment app, and I have a single card. Whenever I shop with
that app it advertises the fact it supports that card. What
happens if my bank now supports some other method…how does my
bank notify my browser to update its supported methods
... that is, update out of band, without going to the bank’s
web site
<Zakim> m4nu, you wanted to focus on FPWD issues
m4nu: my concern is FPWD is a
month off, can we prioritize issues that are related to
that?
... for example, in the first version we could leave
registration completely
AdrianHB: that’s a fair proposal to put on the table now
rbarnes: I appreciate the desire for simplicity, but given both proposals have registration I am disinclined to take it out
<wseltzer> nick: I'd like to prioritize the choice of which proposal we're going to use
<Rouslan> +1 to prioritize issues of contention between proposals.
(thanks wseltzer)
AdrianHB: Don’t see a huge amount
of difference between the two..fundamentally it’s two specs
versus one. A simple payments API, one that supports shipping,
and a checkout API
... goes from simple to very complex. I wanted to potentially
discuss shipping as a topic on its own before we decide which
API do we want to use. I think it’s worth deciding is it a
priority for version 1?
... maybe we should take ten minutes to make the case either
side
<Roy> are recurring payments out of scope? neither proposal seems to address them...
AdrianHB: are we happy to proceed in that direction?
<Zakim> m4nu, you wanted to note a more concrete proposal
M4nu: I don’t think it’s one spec versus the other, it’s how to we structure the FPWD. Do we publish two specs, a low level and one that builds on top of it, or are we just doing one spec
AdrianHB: there are a few design
differences between the two
... so we do have a decision to make there.
<Zakim> nick, you wanted to address Roy’s question
<wseltzer> nick: addressing Roy's irc question. I don't think anything precludes recurring billing; it's left to the payment app
<zkoch> That said, it might be nice to know a payment is recurring from a UI perspective?
AdrianHB: recurring billing is in scope, we don’t say what that means but I think type of payment might be in there
AdrianHB:I would like us to make a resolution that we think shipping address should be in scope for version 1
AdrianHB: show of hands for making it for and against shipping?
m4nu: can discussion be around prioritization therein?
AdrianHB: if we say shipping is a priority then we know which questions we have to ask tomorrow
<Zakim> padler, you wanted to comment on layering
padler: from an IG perspective, I
just wanted to say that the layer that we saw is going to be a
better longer term approach, being able to combine things in
the commerce space
... I think there’s some things we should talk about in regard
to which API we prefer
yeah, if you’re offering
I will probably be quite vocal here
AdrianHB: Case against: too complex. Without it it’s simpler and allows us to focus on the payment piece
<Zakim> m4nu, you wanted to note prioritization of shipping address - leave it rough for FPWD.
<wseltzer> scribenick: wseltzer
Manu: let's talk about
priorities; prioritize the low-level API, and say FPWD will
also included higher-level with shipping address
... we won't have all the issues solved, but pointer to ongoing
discussion
... so proposal: let's push two specs out, low-level payment
API, higher-level checkout API
... get feedback from community
... is it confusing to have 2 APIs?
... get the FPWD out, don't try to perfect it first
zkoch: Careful about taking Jake
Archibald out of context
... If we want his full comments, we should invite him to
share more
... Are you asking us now, do we want shipping?
adrianHB: do we want shipping in
March FPWD?
... can we release something simple and in the meantime
incubate shipping?
<rbarnes> just so everyone has process context: https://www.w3.org/2005/10/Process-20051014/tr.html#first-wd
zkoch: from Chrome perspective,
shipping is a must-have
... we're trying to solve the problem of people bouncing off
checkout flows because they're cumbersome
... we'll have a hard time winning over merchants anyhow
... so how do we give them incentives
... we're trying to get merchants into the group
... just trying to get the funnel part won't work
... a clean API that no one will implement doesn't matter
... value add to merchants: give up a bit of control over
checkout flow, get better continuation
<Ryladog> +1 to Zach
<Vish> +1 on mobile checkout issues
nick: lots of us agree shipping
address is a must for v1
... I'm not convinced about FPWD that has 2 separate
specs
... it shows we can't agree on an approach
... think it complicates things
... what we have should have shipping address; I'd like to see
just 1 spec
<rbarnes> we have initial spec for payment, shipping, and registration, and implementer interest in all three, so it seems worthwhile to me to include them. we can always streamline later.
adrianba: procedural point. I
don't think it would be wise to do FPWD without shipping with
the intent to add shipping for v1
... it's important that FPWD outline the scope of a spec
... in the W3C process
<rbarnes> +1 to adrianba's point about the FPWD encompassing the scope
<shepazu> +1
adrianba: so I wouldn't support
goal of sending with plan to add more scope
... 2d point, is this v1 or v2? Shipping is something we want
to talk with merchants about
<Zakim> ShaneM, you wanted to address the complication of multiple API layers
adrianba: persuade them of the value; shipping is an important part of the value
ShaneM: agree shipping is
important.
... but we're not talking about 2 competing specs, but about
layers of API
... it's ok to have low-level and high-level; that's good
architecture
... not competing
nick: my concern is they're currently put forward by 2 separate groups; I wouldn't want to see them smashed together
<Zakim> m4nu, you wanted to note the data on shopping cart abandonment.
<rbarnes> to paraphrase nick: we can always refactor a consolidated API to have cleaner layers
manu: I'm wary of "competing" --
this wasn't a competition
... key is layering of API
<padler> +1 to layering!!!
manu: I don't care which spec is
picked so long as we layer it properly
... b/c shopping cart abandonment data shows we're collecting
shipping address at the wrong time in the Google/MS API
<rbarnes> this abandonment argument is a total red herring -- nothing says the merchant can't do shipping earlier if they want to
<nick> I am also not convinced it is backed up by the data
manu: putting all our eggs in a complicated basket seems wrong for FPWD
AdrianHB: we're trying first to say, is shipping address in FPWD.
<nick> we don’t *know* abandonment stats because no web merchant today gets to pull address information directly from the user agent
AdrianHB: are we ready to ask for that
Laurent: back to charter; we were
talking about data format, browser API
... have we abandoned defining data format?
AdrianHB: we havent' gotten there
yet
... first we're picking API design
... one of the goals is "streamline checkout flow"
... gathering shipping address is in scope
... so do we want to do it?
Laurent: some data flows are outside browser
AdrianHB: the other deliverables haven't gone away, just not the focus today
nicktr: is shipping address must-have, as AdrianHB asked?
PROPOSED: include shipping address
AdrianHB: Observation: we haven't
considered that payment apps may consider shipping address as
differentiator
... and this puts browsers ahead in the flow
rbarnes: merchant-facing API just lets merchant get the data; doesn't say where it comes form
<Ian> PROPOSED: Shipping address will be included in FPWD.
rbarnes: you could shim-in the app
AdrianHB: if as a merchant I say I want shipping address; browser receives the request and tries to get from user, if it can't, what next?
nicktr: anyone against the proposal?
Vish: it is critical functionality
<Ian> Vish: As an observer, it is critical functionality to get shipping address.
<Ian> ...it's an ugly can of works to open...due to variability in addresses
Vish: but it's an ugly can of
worms to open because international address standardization is
virtually non-existent
... challenge of new address formats
... different country, different address format
<rbarnes> to be clear: we're not going to define an address format, we going to use an existing format (xAL in the current spec iirc)
<mountie> different encodings.
Vish: so you're still talking lots of pain, lots of fields on a mobile device
<zkoch> +1
<Rouslan> +1
nicktr: please _+1 or -1 to the proposal
<m4nu> +1
Ian: if you object, please raise your hand
padler: is there a notion that we
have to support other functions based on address
... if not, should we indicate "address" rather than
"shipping"?
<mountie> -1
AdrianHB: here we're talking
about shipping
... more detail to come later
burdges: you can't give site a
shipping address without asking the user
... so there will have to be a dialog
... which won't necessarily solve the merchant's problem
AdrianHB: implementation details
<padler> +1 to including..
AdrianHB: argument for doing it
is that browsers already have access to info, not
origin-bound
... they can offer it to user, user still makes decision
whether to share
ShaneM: clarification question:
proposal is "shipping address is in-scope for FPWD"
... not saying it's provided by the browser
AdrianHB: API will support the notion of requesting shipping address from the user
<Ian> PROPOSED: Shipping address capture will be included in FPWD.
PROPOSED: Shipping address capture will be included in FPWD
<Ryladog> +1
<Roy> +1
mountie: in many countries,
formatting is different
... then we have difficulty entering address
... also different encodings
<ShaneM> +1 - but I am afraid we are skating very close to the edge of the UX cliff that is explicitly out of scope for this group.
mountie: need to hear from non-western countries
adrianHB: we're not yet discussing those details
<rbarnes> allow me to introduce everyone to xAL http://xml.coverpages.org/xnal.html
adrianHB: I think it absolutely has to support non-western address formats
<rbarnes> this is not the first group to encounter addresses
nicktr: recognizing that addresses are hard,
<nick> +1 to rbarnes. we know how to handle addresses globally
<zkoch> +1
<m4nu> +1
<padler> +1
<hober> +1
<rbarnes> +1
<Rouslan> +1
<nick> +1
<shepazu> +1
<Ian> +1
nicktr: proposal is to include shipping address capture in FPWD.
<yaso_> +1
<ShaneM> mountie: note that issue #28 on the paymentrequest draft is about the format.
<Leandro> +1
<dezell> <because the queue is closed> I will defed my vote to+1
<Ian> SO RESOLVED
<VincentK> +1
<Erik> +1
<burdges> abstain : I think it's completely orthogonal, but no harm probably in combining it.
RESOLUTION: Shipping address capture will be included in FPWD
<dezell> <because the queue is closed> I am convinced by Adrian's argument about IP inclusion as trumping simplicity.
nicktr: after break, we need to talk about requirements, layering
[break, return in 20 minutes]
<scribe> scribe: Ian
<wseltzer> scribenick: Ian
AdrianHB: I am hearing people
today would like us to get to a point where tomorrow we are
working toward a single document.
... there are some low-level design things we get to
later.
... we want to pick the starting point for our specification
today so we can get to other decisions tomorrow.
... I think that as time has gone by, the proposals have gotten
closer to one another.
... I think there are some differences that we can deal with
later like "different prices for different payment methods";
let's not focus on those data model differences here
... I would characterize the difference this way:
* API that allows you to set a flag to get shipping information.
* Composable APIs
scribe: where payment request can
be included in a checkout flow.
... I would like to open the floor to people who feel strongly
about the pros and cons of the two approaches
<Zakim> Rouslan, you wanted to say the fundamental difference is multi-step vs single-step api. i'm concerned that UX for multi-step api is going to be undesirable for merchants.
Rouslan: I think the primary
difference between the proposals is indeed single step v.
multi-step API
... I'm concerned that merchants may not like the multi-step
approach from the user interface perspective. It might imply
that the browser might first prompt for shipping then hide the
ux then perhaps prompt the user for payment separately.
... so I am in favor in that sense of a single-step API
<Zakim> m4nu, you wanted to make case for composable low-level APIs.
m4nu: I don't think it's a
single-step / multi-step question. I think it's monolithic v.
composable.
... the question is whether we want a number of primitives or a
single monolithic API.
... ...the extensible Web view is "create primitives" to
support innovation
... the other thing I am concerned about is the data suggesting
that we should collect shipping address way before we do
checkout
... when the customer hits the site you collect shipping
address and then you can tell them when the product will be
delivered, how much it will cost, and that will address cart
abandonment.
... the other thing that I am concerned about is that the
checkout API is complex.
... there are a lot of decisions we are going to have to make.
I am not confident that we will make the right decisions.
... if we have composable APIs we can learn from merchants and
then make changes based on merchant feedback
tarcieri: My personal opinion is
the ability to intent into a native app
... make a payment from the mobile (native) web
... I'd like to see that capability in there one way or
another
adrianba: I would like to make
several points
... the first is that in the simple case where you want to make
a payment request that doesn't involve any shipping information
or any other information gathering, the payment request API
proposal we've made is pretty simple.
<adrianba> http://github.adrianba.net/paymentrequest-demo/demo-simple.html
adrianba: I feel like for the
simple case, our API is pretty simple.
... and then you can layer in new things into the request as
you want them
... so shipping address options are the ones that we have done
first, and I can see that we will want to add things into the
future
... there's an advantage to having a single entry point
API
... you tell developers who want to make a payment request
"here's where you go"
... we want to maximize the opportunity to compete on the
experience
... we have incentives as browsers to compete on the user
experience, and the better we get, the better for
merchants.
... I worry that if we have an API that breaks down the UX
elements into discrete pieces, it makes it difficult or
impossible to enable the innovation we seek.
... regarding the extensible web manifesto and the desire to
build APIs that are "as low level as possible"
... if we build lower-level capabilities we can allow
experimentation and figure out later what to add to the
browser....BUT there are caveats about doing that where it
makes sense. And for something that is privacy and security
sensitive like payments,
there are concerns about building an API that gives you access to user data without them understanding that they are sharing this information together.
scribe: so low-level primitives
are good, but here we need to build a consistent experience
where people can be aware of what they are sharing
... regarding cart abandonment, I've not seen any good data
that describes the impact of a trusted experience from the user
agent...so it's not clear to me that a unified experience
within a trusted UI will lead to the same result as other types
of experiences that might have led to abandonment.
markw: I think it would be useful
for the group to understand the target market for the
API.
... I think different sites will have different views.
... for instance, for big sites with teams focused on payment
refinement, you may want primitives that allow them to
experiment
... but for smaller merchant you may want a single API
... as far as possible, don't make assumptions about user
interface
... there are different user experiences possible...like
populating address information with the push of a button
<padler> Can we propose a smaller set of core primitives for composability along with a reference (or base) higher level API to illustrate a basic composition?
<nicktr> How would that work, @padler?
<rbarnes> padler: that might sound good in principle, but when you make an API, you have to choose
<rbarnes> developing for N>1 APIs is harmful
<padler> regarding Mark's comment and looking at the Extensible Web stuff, we do make choices on the core primitives... and how the basic things work... but allow for innovation experimentation on how those are composed...
<Erik> I always design API's in layers. Most people just want the API to work (90%). Develop the very low level API and add higher level API that fill/bootstraps the 'defaults' of the lower level API
<padler> the reference implementation may help smaller shops which do not have resources for large scale R&D..
<Erik> High level API fill out the defaults of the monolithic API
vish: Good point from Mark Watson
regarding large merchant v. small. I agree there's a dichotomy
of needs between the two. But from what we see from Visa, more
e-Commerce is shifting to large merchants.
... that's happened in the US and is happening globally.
... personally I prefer more composable APIs. Here's why:
* Merchants want diversity of vendors. So they might be ok with browser form-fill for some things, but some people might not trust browser for some things and want to get info from wallet provider
* As a merchant, I may be getting data from multiple sources
* If I'm a merchant, there are some cases where I want a user to log in, and the ability to get shipping via API and get payment details later is useful
* It's important not to stifle innovation, so I think a composable API might lead to a broader set of use cases being fulfilled
nick: Let me offer a
counter-argument for this. I am not a huge fan of getting
shipping in a separate API; it will be abused
... if we provide a separate API to collect shipping, they will
use it alone
... so I prefer linking it to payments
... I would also be wary of cart abandonment data....we will be
enabling new experiences because user agents are in a more
privileged position to gather user contact information
... so I don't believe the current data simply doesn't apply.
The user will not be typing information; it will be
automatically provided (with consent)
... so I strongly support linking the shipping and payment in a
single API
<Zakim> ShaneM, you wanted to talk about community activism and forcing people to change
ShaneM: We have an opportunity
where people can innovate or where we can tell people "what to
do"
... I think a parallel is community activism
... we don't want to tell people how to change their user
experience.
... is that true of small merchants?
... no, they will use the simple API
... but the bigger merchants will want to innovate and not be
told what to do
zkoch: A few additional points -
you don't need multiple levels to run A/B testing
... you can imagine passing a flag or not depending on data,
and changing over time
... I think there is onus on us to demonstrate that there is
value here.
... the onus is on us to show that the value of giving up a
small piece of control over shipping gathering is offset by the
improved experience and lower cart abandonment
... that's why we are starting with the bare minimum (pay and
ship). We want to take an
iterative approach to this problem before adding later
features
MattS: We resolved to include shipping address. +1 to publishing FPWD with composable APIs and getting feedback
<Magda> +1 to Matt's comments
<padler> +1 to Matt's comments on getting feedback related to a composable approach
<ShaneM> +1 to Matt's comments - that's brilliant.
rbarnes: We are dancing around
topic of hiding complexity. You can hide by breaking into
pieces, or you can do a single one that scales. I think that checkout is
heavily predicated on payment, which speaks more to the
scalable option (1 API)
... from a payment perspective, there's no difference.
... from a browser implementer perspective, it's more or less
the same cost
... from a developer perspective it's also mostly the same
approach.
... so there is, I think, a marginal cost to having 2 APIs
because it will be more complex
... so I come down slightly in favor of building one thing
where you can ignore what you don't want
... and there are some marginal benefits to "not artificially
suggesting independence" (where there isn't really, as nick
said)
... and lastly, these could be modified later...we can factor
things in or out depending on feedback we get
<ShaneM> +1 to stop starting and start
AdrianHB: Anyone on the call want to weigh in? Let us know on IRC
<Zakim> m4nu, you wanted to note that we keep talking this as an either or when it's not that.
m4nu: Quick observation...I think
some people are suggesting that there is a reduction in
functionality in one approach or the other. But I don't think
that's the case.
... The whole question is how people who don't need the full
functionality do the simple thing
AdrianHB: I have a few points without my chair hat on:
* I don't think the points about separation of shipping and payment are entirely accurate.
scribe: fundamentally both APIs
return the shipping address to the site prior to payment
... you can use either API to farm shipping addresses without
ever getting a payment
... in terms of the data, I thought the one data point that I
thought was really interesting, was that it did not talk about
people dropping off because of "Flow" it had to do with
"price"
... at the last minute the discovered the price was too high
with shipping
... I think that data point remains valid.
... I am hearing from the browser folks that knowing the
requirements up front lets them build a better UI
... but I'm not sure that the API differences affect that
... i think the checkout API is not vastly different from the
callbacks of the other API.
... I may be wrong, but I think you can use composable APIs in
a single UX
... lastly, how will we add new options in the future?
... as a developer, I don't like the fact that I create the
payment request that causes behavior to happen somewhere
else.
... I prefer chaining things together ... when I get shipping
info I execute this, when I get this other info I do this,
etc....as a developer I like that pattern
nicktr: Given that we want a base spec to work toward FPWD, what would it take with either spec, to deliver the requirements of (1) simple implementation for developers or (2) composable for others
<Zakim> padler, you wanted to ask about use cases around web payment with in store pickup and whether that impacts approach...
padler: Use case: buy on the web
pick up in store
... another use case to consider: Digital media
... I need to use payment alone without shipping
<markw> Sometimes the tax you pay depends on where you live, even if the purchase is digital
padler: I want to be sure we can get to other use cases...not just checkout that we are doing today
ted: I am not sure that
contrasting the two current approaches from the composability
lens is helping
... both approaches have good qualities from software
engineering perspective
... no matter what we do, we can iterate on it.
... given iteration is the thing to do, I prefer to make the
smallest change to the platform possible.
... what's the minimum to do to make checkout easier?
... and find out if they love it or hate it.
sanjay: I was thinking about
monolithic v. composable
... I think each has pros and cons
... but I wanted to mention that information that the browser
knows (e.g., device id)
... access to that information will affect the flow
... I don' think there is a single path here...things can
change ... it's good to have not too much choice
zkoch: I agree composability may
be the wrong lens. If we create a "collectShipping" Api, it's
not clear that chrome team will do that
... issues of privacy, and that will require a lot more
thought
<padler> perhaps the way it is exposed is an implementation choice?
zkoch: If people like the
approach of "send" and "request" ... we can build up the
payment request API with that approach as a compromise
... but please note we may not expose some things as individual
APIs for reasons like security
... composable does not imply it will be exposed.
padler: If you choose to expose it together, that's fine. But if others want to expose both, fantastic
kriske: Regarding shipping API,
the reason there is a risk attached to it (giving out shipping
details to merchant)
... I wonder if you want to collect the information you need to
have a good idea of what the cost will be...you don't need to
give out shipping details at the beginning, you give out the
minimum information like country or state
... and only later do you provide the actual full shipping
address, when the user has agreed to buy something.
... so to me it's a "non-issue"
<Zakim> Rouslan, you wanted to say i disagree on both apis farming. the multi-step api requests payment after getting address. the single-step requires payment request before getting
Rouslan: Yes, indeed, chaining v.
passing flag is not the issue. What I am concerned is farming
shipping address.
... I don't agree you can farm shipping address.
... with the Google/MS API
adrianHB: I disagree...you give back shipping address to compute final price
zkoch: the events are fired on change..so that you can update price
Rouslan: three steps:
* show() => request payment
* address change event
* show promise resolves and user is ready to complete transaction.
adrianHB: But the web site can
kill the process once they have the shipping address.
... you are going to have to monitor web sites that seem to be
farming addresses.
IJ: Is it happening today? Is it more likely to happen with this?
nicktr: Billing address is more
significant
... those are credentials
<rbarnes> pony racketeer
adrianba: Two things to add to
what has been said:
... it's true that in the payment request API we share the
shipping address during the process.
<Vish> My son wants a pony - what's that site for the free pony?
adrianba: I do think that it being part of the UI presented to the user mitigates somewhat the issue
<ShaneM> I am not sure that billing address is a "credential". But i agree that it is used as one during payment validation.
<m4nu> https://freeponies.co.uk/
adrianba: and is very different from separately creating an API for getting a shipping address. We don't think it's desirable to do that
<rbarnes> we have reached the "pony jokes" point of the meeting
<m4nu> shipping from that site's gonna be harsh, tho.
<zkoch> Vish, we need your credit card to run a $0 auth, and then we’ll send you a free pony. Please PM me credit card details
adrianba: regarding
comparability, it would still be possible to compose different
pieces into a converged UI, but it would also require us to
build the non-converged UI
... to me, that seems like a lot more work
... I think the implementation cost is much higher
<Zakim> wseltzer, you wanted to note standards as pattern matching
<rbarnes> also m4nu: https://freeponies.org.uk/
wseltzer: we are all interested in innovation, but a part of the standards process is to determine patterns that have emerged from innovations that we can pull into the platform.
<Vish> Time for pony rickrolling https://m.youtube.com/watch?v=lbnoG2dsUk0
wseltzer: Let's identify the
common patterns and let people use the Web more
effectively
... so maybe a key audience is smaller merchants
... maybe some of those merchants are currently relying on
libraries
... maybe we can give them some more help
AdrianHB: I don't see the
composable API being used outside payment
... we should not support a flow that does not involve
payment
<nick> I don’t understand how that fits in with m4nu’s request to support collecting shipping address before checkout
adrianhb: If we do not plan to allow shipping capture without payment, then the differences between the APIs are minimal
<Erik> Store the shipping in the browser defaults and move on.
dezell: As mentioned earlier, we
should be sensitive to IP
... +1 to getting feedback
Vish: Are we thinking about security models?
<Magda> *wondering if we can reopen the q*
Vish: Who is going to have access to underlying APIs?
<dezell> Just for the record...
<dezell> 1) the inclusion of features in FPWD (per Adrian) is important for IP disclosure, and is at odds to the "minimum required to declare victory" approach that we might take in our own internal development efforts.
<dezell> 2) v1 can be non-composable, and be refactored to be composable later.
<dezell> 3) marking features as "at risk" in a draft effectively signals to the community that feedback is needed.
Vish: As a wallet provider we
have to vet entities connected to our wallets
... we have to monitor potential malicious activity
<tarcieri> ^^^ +1
<wseltzer> scribenick: wseltzer
ian: my concrete proposal, having
heard security concerns
... the unlikelihood of using the APIs independent of one another
... and opening to revisit how the chaining happens
... request that editors convene to see whether they can come
to agreement on a single proposal
... with slightly different event handling model
... solving use cases to extent possible
... because I'm not hearing that they'll be used in a manner
that's uncomposed
... either because browser won't support, or we as group don't
support sole shipping address
nick: that seems like a good
idea
... please be very careful about suggesting in FPWD that we're
talking about 2 options for same thing
... because we're talking about pure browser
implementation
... but 2 streams require browsers to do twice the work,
without changing what other participants get out
... so I'd like to pare it down, focus
<Ian> +1 to getting feedback in the spec
nick: and then be open to feedback
Manu: we're talking about a
non-proposal
... there's no proposal on the table that says "collect
shipping address at the beginning"
<mountie> composability: deliver first, pay later
Manu: the original reason for
composability was that some merchants may not want an entire
checkout flow pushed on them
... they probably won't use any of the checkout API other than
payments
... I'd like some part of this work to be successful
... we all came together around payment initiation,
acknowledgment
... checkout API came later
<Erik> I purchase electronic media all the time. In those cases the shipping API is an email address
Manu: also, it's only an FPWD.
nicktr: the question we're trying
to answer
... is there a way in which we can pick one, and put what we
want into the other
... proposal from Ian that the spec editors have that
conversation themselves
... before we ask them to take that action,
... I wanted to ask, if I flipped a coin and picked one,
... is there anyone who'd say they couldn't work with it?
<rbarnes> could someone post URLs for the APIs so people can refresh?
nicktr: so reopening the queue
adrianhb: it seems browser
vendors favor one proposal, non-browsers another
... is there an implementation challenge the checkout API
poses?
... someone's work is going to be put aside and used as a
source of ideas for others
... ideas are not gone forever, but the work isn't taken as a
starting point
... it seems we agree there's not huge fundamental difference
between the proposals
... but we need a starting point.
mountie: I think we need
composability
... e.g. deliver first, pay later
... so we might just need delivery address
Ian: a word on my thinking: I'm
not hearing huge differences
... material, but manageable
... close to isomorphic, but a style question
... except I heard pretty loudly that some things won't happen,
e.g. for security reasons
... but I may be hearing some things won't be implemented
... go find common ground
adrianba: AdrianHB asked, if we
took the checkout proposal, what would we change?
... difference for me is I understand ours, whereas I don't
understand checkout API
... because I keep being told I'm talking about a
non-proposal
... so I couldn't support the checkout API
... we can certainly visit some of the stylistic points,
syntax
<rbarnes> https://wicg.github.io/web-payments-browser-api/checkout-api.html
manu: the non-proposal was there
is no tech spec on how to collect shipping address outside
checkout flow
... differences were outlined in one of my slides
... how you collect information, mainly
... minor details we can work through
<nicktr> http://wicg.github.io/web-payments-browser-api/checkout-api.html
manu: we could start from either
spec and go from there
... are we telling people: there's one way to do payments,
initiate checkout flow
... or there are two ways, including checkout flow.
markw: last time I saw a WG with this problem, the solution was to choose one and agree to adopt particulars from others
shepazu: so they designed it by committee?
Roy: you asked us what would be a
blocker. For FB, we do a lot of experimentation.
... either proposal has the ability to allow for that
... so not a big difference
MattS: it seems to be easier to
go from complex to simple, in post-FPWD period
... if that's true, then start from complex
shepazu: nothing in the process says you can't do that, but some risk that people dismiss the work
zkoch: I disagree that
paymentRequest is for a more complex flow
... we start basic, if you want complex, you can add
detail
... I like the story "here is how you do payments on the web,
this API"
... the defaults work; if you want more options, add
detail.
... better to have a single cohesive story, better for
outreach
... I'll go with our dev rel team to tell developers how it
works
<ShaneM> +1 for a cohesive story.
<Zakim> Rouslan, you wanted to say that (as a proponent of paymentrequest), if i had to take Checkout API, I would replace get-address+request-payment pattern with
Rouslan: (as a proponent of paymentrequest), if i had to take Checkout API, I would replace get-address+request-payment pattern with
20: 22 < Zakim> ... request-payment+get-address pattern.
<ShaneM> Doctor, it hurts when I go to W3C meetings.
AdrianHB: we should just pick
one
... we've increasingly decided the two are almost
identical
... the decision is less about which proposal, than which
editors
... there's an editor selection decision we should make at the
same time as the starting-point decision
The following statements from Manu Sporny were inserted on his request after the meeting took place.
manu: It's obvious to me that the browser vendors will not go with any proposal but the one that they put forward, so what the WG wants doesn't really matter in this particular case.
manu: I find it offensive that Adrian Bateman (from Microsoft) says that he doesn't understand the Web Payments CG proposal and couldn't work with it since he doesn't understand it. It's been public for months and all he had to do was ask about parts of it and we would have explained it to him. The CG took the time to analyze the Microsoft/Google proposal, we put in effort to understand it, and we submitted 25+ issues on it (which haven't been integrated into the issues in that spec). The browser vendors haven't done the basic due diligence to read and raise issues on the Web Payments Community Group spec. This has not been an equal exchange of intellectual due diligence.
manu: In addition, I think there is a large amount of intellectual dishonesty going on here on the part of the browser vendors, but the WG is really powerless to do anything about it because the browser vendors are going to do whatever they want at the end of the day. So, there are really only four opinions in the room that matter - Microsoft, Google, Apple, and Mozilla.
manu: This is typical W3C browsers-vs-everyone-else politics - it's about control and the browser vendors want the control. We're no longer having a technical discussion, this is politics. Speaking as a non-browser W3C member, and as the Chair of the Web Payments Community Group, I'm really fucking pissed off about what is happening here. This is bullshit.
manu: So, that said, I see two choices in front of us. Spend the next day of face to face time slugging it out over the specs w/ the browser vendors digging their heels in more and more OR pick their spec and get on to discussing issues, which we really need to do to get a First Public Working Draft out by the end of March. I don't think we have any choice but to kill the CG specs at this point.
manu: So, here's the only workable proposal that I see: Abandon the CG specifications and pick the Google/Microsoft proposal as the base specification so we can get some spec text under the control of the Working Group and then start processing issues.
End edited block of comments from Manu Sporny.
<Erik> Shipping address is metadata for a business process, not a payments process.
AdrianHB: whom would you propose
as editor
... someone wearing merchant, PSP, other stakeholder hat would
be valuable
<Ian> +1 to getting to the differences
<rbarnes> +1 to getting to the differences
<shepazu> +1
<Laurent_> +1
<GregoryE> wseltzer: I could do that
<rbarnes> this does not have to mean goodbye -- the CG's work will be really valuable for the "Payment" part of "PaymentRequest"
<GregoryE> for m4nu
<GregoryE> and AdrianHB
Ian: I was trying to listen for
comments from stakeholders; the security/privacy concern stood
out
... there's other valuable work from the CG, on the HTTP
API
<ShaneM> I think the security/privacy concern is a red herring. there is no way to prevent the problem that was alluded to.
<GregoryE> working for a PSP and dealing mostly with merchant issues
Ian: there's lots of work to do
there, and also lots to find in both APIs
... no one is saying let's steamroll the use cases or ideas
from either draft
... browsers have shown willingness to talk about the messages,
they need to be responsive
<ShaneM> I am very concerned about disenfranchising third party wallet / payment app providers.
AdrianHB: we now have a WG spec
we're working on
... it's no longer a CG or Incubator proposal
<Ian> I am convinced payment app providers are included
AdrianHB: editors will have to work to respond to concerns of everyone
<Ian> But I don't see lots of opportunities for non-browser meditators at least in the early versions
AdrianHB: a lot of work has gone
in on both sides
... I would like the CG to be more involved
<rbarnes> +1 to bringing in the CG's expertise in payments. the PaymentRequest is really thin on that
nicktr: point of information, I think Gregory in irc is volunteering to be an editor
PROPOSED: that we adopt the Payment Request API as the base specification
<Magda> +1
<AdrianHB> +1
AdrianHB: anyone opposed?
ShaneM: make sure people know what we're talking about
<Ian> (Nobody raises hand to object)
AdrianHB: Payment Request API is the proposal put forward by Microsoft and Google
<Rouslan> +1
https://wicg.github.io/paymentrequest/specs/paymentrequest.html
<rbarnes> +1
<zkoch> +1
<padler> +1
<yaso_> +1
<Ian> SO RESOLVED
RESOLUTION: that we adopt the Payment Request API as the base specification, https://wicg.github.io/paymentrequest/specs/paymentrequest.html
<Ian> https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016-Requirements
Ian: a project on atomic
requirements
... some groups publish requirements documents
... e.g., it's not a requirement that the shipping address be
useful outside a payment
... capture the requirements so we can come back to them.
... should we perhaps start there tomorrow?
... could be that this is useful ancillary deliverable
markw: how should we provide comments?
Ian: those in the group can edit;
observers can send to the public mailing list
... these aren't my statements; it's up to the WG to declare
whether there's consensus
MattS: the group suggested
earlier that flows TF should work on specs, use cases
... I think this is a good place for requirements
... flows TF will distill requirements from the flows, update
them in IJ's document
Ian: this document not yet group consensus; as we hear group consensus, we should not that
AdrianHB: A meta issue
... W3C is trying to figure out "what's the right time to start
a WG"
... I think we have valuable feedback for the Advisory Committee
... the intention was not to create competing drafts
AdrianHB: both proposals got
better as we discussed them
... if proposals had matured more first and we'd had today's
discussion before charter...
<nicktr> https://www.w3.org/2015/Process-20150901/#ACMeetings
AdrianHB: I'd like us to think about feedback fro AC
Ian: I want to thank all who brought concrete proposals
<padler> +1 to Adrian's comments on feedback re: WG process...
Ian: the CG, the browser
group
... both have given us input that gives a better chance of
getting things right
zkoch: We're in a different room
tomorrow; we'll be closer
... look for the signs
<nicktr> We're meeting in "Sue Storm" tomorrow
nicktr: thank you all, see you tomorrow
