- From: <msporny@digitalbazaar.com>
- Date: Mon, 02 Jun 2014 14:43:27 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes for this week's Web Payments telecon are now available: https://web-payments.org/minutes/2014-06-02/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Web Payments Community Group Telecon Minutes for 2014-06-02 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0000.html Topics: 1. Parametric Selection of Payment Method 2. The IGF 2014 Workshop on Payments and Identity 3. App Stores 4. In-app Purchases Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, Timothy Holborn, David I. Lehn, Pindar Wong, Brent Shambaugh Audio: https://web-payments.org/minutes/2014-06-02/audio.ogg Dave Longley is scribing. Manu Sporny: Pindar had asked to announce some IGF information Timothy Holborn: The outline (from IGF) looked very positive... Manu Sporny: Any other updates? David I. Lehn: Nope Topic: Parametric Selection of Payment Method Manu Sporny: So we have this right now for the use case: Selection of payment method based upon desired payment speed and cost. Manu Sporny: This seems to be something that the payment processor would ... it's a fairly complex use case, we could say it's something the payment processor could handle, but that payment processor might have to know information from other payment processors, etc, to produce quotes Dave Longley: This sounds like a requirement, so we'd need to reword it as a use case. [scribe assist by Manu Sporny] Timothy Holborn: Should it specifically state directionality? As in: capability at both merchant and end-user contact points?? Dave Longley: Maybe the reason it was in here was because the protocol would need to support it - this seems complex, especially for the first version of this. [scribe assist by Manu Sporny] Timothy Holborn: Different regions might have different rates for payments. So, cms might check where end customer is.. Manu Sporny: The problem with the complexity of the use case ... is that it may require something built into the protocol and it may be difficult to add in later Dave Longley: I'm trying to think through how this could be standardized/implemented. [scribe assist by Manu Sporny] Dave Longley: Further problem - how would these prices be displayed, does the merchant have any control over it? [scribe assist by Manu Sporny] Dave Longley: This may or may not require the merchant to know which payment provider's are available. [scribe assist by Manu Sporny] Timothy Holborn: Perhaps the requirement is being able to identify the characteristics of a payment processor? Dave Longley: Or are we talking about merchants providing different payment options. [scribe assist by Manu Sporny] Dave Longley: Payment speed soundsl ike something payment processor could decide. Wouldn't your payment processor just provide with a better rate? Payment processor can process things more quickly, thus at a better rate. Seems like this is out-of-band stuff. [scribe assist by Manu Sporny] Manu Sporny: I think the intent at the workshop was a smart wallet that could auto-negotiate on your behalf to pick the best payment processor option based on a number of different variables Timothy Holborn: Perhaps a means to dynamically signal qualities. Manu Sporny: We want your payment agent to be able to determine your fastest/cheapest payment option based on a variety of different inputs Timothy Holborn: Like petrol prices at a petrol station. Perhaps the characteristics might fluctuate, and/or if a signalling method existed, higher flexibility might encourage competition. Dave Longley: Seems to me, based on how we designed payswarm so far, right now merchants put up offers for assets that indicate what minimum costs are. [scribe assist by Manu Sporny] Dave Longley: You turn around and give that to whatever payment processor you want to. The payment processor will give you a finalized price to display to you before you purchase. [scribe assist by Manu Sporny] Dave Longley: If we don't consider this in version 1, if we wanted to add something to the protocol, what would happen in that case, the "Web Pyaments Commerce Protocol" would just communicate with N-many payment processors to pick one offer. [scribe assist by Manu Sporny] Dave Longley: I think we can layer this. [scribe assist by Manu Sporny] Timothy Holborn: Does the payment processor signal the "deal" or arrangement (charge) for processing the payment? Dave Longley: We've completely separated concerns - the merchant just states what they need. That may or may not contain some price that must be met. [scribe assist by Manu Sporny] Timothy Holborn: At the time of the transation Dave Longley: What might end up happening is that the payment processor could give you a refund, or pay the merchant more money... the merchant might say the cost does need to be a dollar, but I'm willing to take between 70%-80% of that dollar. The payment processor might negotiate to give you a refund. [scribe assist by Manu Sporny] Dave Longley: In another case, the merchant could say: I just want $0.80. [scribe assist by Manu Sporny] Dave Longley: Version 1 could just talk to your payment processor. [scribe assist by Manu Sporny] Dave Longley: Version 2 could talk to N-many processors. [scribe assist by Manu Sporny] Dave Longley: Seems like this could layer and it could work. [scribe assist by Manu Sporny] Manu Sporny: Going through tim's comments ... the directionality question ... the merchant specifies the asset they are selling and what they want, the customer can come in and read what the merchant wants and figure out which one of their payment processors would give them the best deal and would then meet that offer by posting something back to the merchant Timothy Holborn: Payment processor more likely to say, I'll charge you 10c to do that transaction, in usd, within the next 30 seconds. The merchant says - that's the cheapest deal, do it. Manu Sporny: The merchant doesn't need to contact the customer, the customer can make the best decision for themselves with all the available information Manu Sporny: Because the merchant has already made all that information known Timothy Holborn: K. Manu Sporny: Re: different regions would provide different rates. Manu Sporny: "Perhaps the requirement is being able to ID the characteristics" that is one requirement, the other requirement is being able to identify the charact. of an offer for sale, the system we're discussing will know each of the payment processors available, they'll be able to say "i have an offer the merchant put forth, what's the fastest you can process this transaction for me and what's the price" and then you pick the best quote Manu Sporny: "Perhaps a means to dynamically signal qualities" ... i don't know what he means by that exactly, dynamic is a loaded worded, perhaps the means to signal qualities is what linked data is all about, we use linked data to express a whole variety of different qualities Manu Sporny: "The characteristics might fluctuate..." ... we assume the characteristics do fluctuate, we allow merchants to publish whenver they want (every 100 ms or every day or year, whatever works for them) Manu Sporny: We are enabling flexibility Timothy Holborn: Some payment processor might fluctuate in price during a given period. Timothy Holborn: :) Manu Sporny: "The payment processor is more likely to say 10c..." ... i think this conflates what the merchant should be able to say Manu Sporny: There's no reason to involve the merchant, it's too complex to do it that way Manu Sporny: The merchant just has to say "these are the offers, these are the terms" Manu Sporny: And the customer/payment processor just figures out what works for them Manu Sporny: If the merchant won't accept something, they don't offer it Manu Sporny: "Payment processor might fluctuate..." ... yes, that's assumed Manu Sporny: We need to rewrite this use case Manu Sporny: A customer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The customer contacts three different payment processors to get a finalized transaction before accepting that transaction. Dave Longley: We can support that now, the way we've done this (I think it already works with the protocol). [scribe assist by Manu Sporny] Timothy Holborn: I imagine their might be loyalty opportunities between payment processors and their customers Dave Longley: I think this is already covered by the current design. [scribe assist by Manu Sporny] Manu Sporny: I don't know if we support the merchant specifying which payment processors they support yet. Dave Longley: I think we can do that now, you can list the payees as specific to certain payment processors. So, technically we can do that today, but we may want to do it in a different way in the future. [scribe assist by Manu Sporny] Manu Sporny: A customer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The offer includes a list of payment processors that the merchant is capable of receiving payment through. The customer contacts a subset of those payment processors that they are capable of sending payment through to get finalized transaction details (such as price or speed) before executing the most desirable transaction. Timothy Holborn: +1 Manu Sporny: Pindar +1 through skype Topic: The IGF 2014 Workshop on Payments and Identity Manu Sporny: http://www.intgovforum.org/cms/wks2014/index.php/proposal/view_public/69 Pindar Wong: The IGF, the good news, is that our proposal has been accepted, and therefore we will present in Instanbul, Turkey, at the panel, well ... it's actually a working group, i had a few names presented to me at the stockholm forum, I just wanted to have it on the record during this call Timothy Holborn: +1 Timothy Holborn: Looks great Manu Sporny: The comments that we got back seemed very reasonable, things we should definitely address Pindar Wong: A lot of the time was taking up with presentations in last years IGF, so this time there will be some videos and those will get out of the way to have more time Pindar Wong: We've had some comments from the federal reserve and they might be ideal in terms of reaching out to Manu Sporny: I can reach out to them Pindar Wong: I'll bounce some names later this week, i know you're traveling, we can let the list know about the comments Manu Sporny: Right, which list? Manu Sporny: The web payments CG would be good to hear the comments, the ... actually, maybe it would be good to let them both know, and let the IG list know the MAG is interested in payments Pindar Wong: This would be a good test case to figure out how we should work the messaging around this. Manu Sporny: I forwarded the comments from the MAG to the web payments list, i blanked out email addresses, names, etc. Manu Sporny: Here are the comments we got back from the IGF MAG: http://lists.w3.org/Archives/Public/public-webpayments/2014May/0149.html Manu Sporny: I'll send this onto the web payments chartering IG so they're aware of this happening Pindar Wong: Thank you Brent Shambaugh: +1 Manu Sporny: We're hoping to send out a pretty big advance in the payments privacy/policing area, it's a new proof of concept we've been working on for the last month ... to demonstrate that this isn't just theoretical, showing how to put all these things together, such as high-stacks credentials, passport, proof of age, driver's license, etc. and digitally signing those so that they can be trusted by third party sites, these credentials Could be issued by bank, etc. Manu Sporny: National ID card could have signature on it from US, Canadian, Hong Kong gov't, etc. Manu Sporny: And be stored with your identity document and be able to be transferred to third parties and would be digitally verifiable Manu Sporny: Anything else on this topic before moving on? Dave Longley: Tim holborn wanted some clarification on something Timothy Holborn: What did you want to be clarified? Topic: App Stores Manu Sporny: This is what we have for the app store use case so far: App Stores - selling apps in mobile scenarios. Timothy Holborn: Oh. Just seemed like a long pause... Manu Sporny: Number of problems with this, it's not very specific, it's only mentioning mobile... the problem with mobile is.... the general discussion we had at the workshop was that mobile is *part* of the web, this mechanism is built for the web, it's not "non-mobile" or "non-tablet" the key here is that there's a programmatic way to utilize HTTP and other low-level protocols to execute payment Timothy Holborn: My app interface hung... Now I'm catching up. Sorry. Gimme a tic Manu Sporny: A browser is not required Manu Sporny: With in-app purchases, etc. typically a browser is not used, but what we mean by web payments is to use the web as the substrate on top of which payments are built Manu Sporny: No browser is required Manu Sporny: We can't say "mobile scenario" because what is and isn't mobile is pretty shaky these days Brent Shambaugh: So apps use HTTP? Manu Sporny: Is a transforming tablet with a keyboard on it a mobile? Manu Sporny: So we should probably just remove the whole "mobile thing" from the use case and just talk about app stores Manu Sporny: And app stores that just happen to use the web payments protocol to do payments Pindar Wong: I agree mobile/non-mobile is not a useful distinction [scribe assist by Manu Sporny] Manu Sporny: We also have this for the next use case: In-app purchases in mobile scenarios for purchasing premium content, virtual goods, or subscriptions. Manu Sporny: So, we might want to combine these two use cases. Pindar Wong: Yes, combine them makes sense [scribe assist by Manu Sporny] Timothy Holborn: I'm not sure the issues exhibited in those older paradigms apply here. Dave Longley: A customer uses their mobile phone or browser to access an app store to make a purchase. [scribe assist by Manu Sporny] Dave Longley: A customer purchases premium content, virtual goods, or a subscription from inside of an application. [scribe assist by Manu Sporny] Timothy Holborn: Can a link be provided in the AppStore to make the purchase in a browser? Dave Longley: I think there are two different cases. You are at an app store making a purchase. You are in an app making a purchase. [scribe assist by Manu Sporny] Dave Longley: What device you're doing that with, doesn't really matter. [scribe assist by Manu Sporny] Dave Longley: If we can mention mobile as an example, that may assuage some people's concerns. [scribe assist by Manu Sporny] Dave Longley: So, with your mobile device, with your browser, it just works wherever. [scribe assist by Manu Sporny] Timothy Holborn: Might be in a browser making a purchase for an AppStore or an app... Pindar Wong: Leave out desktop [scribe assist by Manu Sporny] Timothy Holborn: Ie: kid has phone, with no credit card details in AppStore. Parents use laptop to buy app or send credit to kids appstore Timothy Holborn: K. Manu Sporny: Then how about this for the first use case: A customer uses a native non-browser application on their mobile phone or tablet, or a web browser to access an app store to make a purchase. Pindar Wong: Yup, works for me. [scribe assist by Manu Sporny] Timothy Holborn: +1 Dave Longley: I think we need to be slightly more clear about "need to make a purchase via an app store". [scribe assist by Manu Sporny] Manu Sporny: Ok, so change to: A customer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store. Dave Longley: Your application or web browser can use the same protocol to initiate the payment. [scribe assist by Manu Sporny] Pindar Wong: +1 Timothy Holborn: +1 Topic: In-app Purchases Manu Sporny: What we have right now is: In-app purchases in mobile scenarios for purchasing premium content, virtual goods, or subscriptions. Timothy Holborn: Why are the principles different for mobile. Timothy Holborn: Is this due to carrier direct billing? Timothy Holborn: Arguably, these models also apply to many games for desktop / other platforms. Manu Sporny: Re: tim, no this was just something that was mentioned at the workshop because people were thinking that mobile-based payments were different Manu Sporny: Tim, no - this is mostly because people at the workshop were too fixated on Mobile. Timothy Holborn: Or advanced apps. Manu Sporny: From other payments, and they really shouldn't be Manu Sporny: Carrier-direct billing is different, but the only thing that's different is the payment processor Manu Sporny: Your payment processor is your mobile carrier, not, for example, paypal or google wallet Manu Sporny: Ok, so this? A customer makes a purchase from within an application for premium content, virtual goods, or subscriptions. Pindar Wong: I think we need to ensure that mobile-based payments is not perceived as different even though the payment processor may be different [scribe assist by Manu Sporny] Timothy Holborn: Yup. Dave Longley: +1 Timothy Holborn: +1 Pindar Wong: +1 Timothy Holborn: I think people forget mobile started with wap Timothy Holborn: Or similar. Timothy Holborn: Now, the apps are much more capable of speaking www. Manu Sporny: Next week the meeting time is up in the air, we may or may not have a call next week Manu Sporny: We're just going to keep going through the use cases, if we don't do it, the web payments IG will have to, it's better that we do some front running and get some solid use cases down related to the tech we're building Manu Sporny: I think so far many of the use cases are already met with at least the payswarm stuff we've put out into the public Manu Sporny: That's good that they are met by the tech we've been building over the last 4+ years Manu Sporny: Any other comments we should be aware of before the call next week?
Received on Monday, 2 June 2014 18:43:52 UTC