- From: <msporny@digitalbazaar.com>
- Date: Wed, 21 May 2014 12:50:41 -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-05-21/ 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-05-21 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014May/0102.html Topics: 1. Web Payments IG Charter Draft 2. Merchant-initiated payments 3. Customer-initiated payments 4. Customer-based selection of payment processor 5. Payment method switching 6. Loyalty cards and coupons 7. Remittances 8. Purchase-specific need-to-know identity Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Brent Shambaugh Audio: https://web-payments.org/minutes/2014-05-21/audio.ogg Dave Longley is scribing. Manu Sporny: There is one update to the agenda - the draft charter review for the Web Payments IG. David I. Lehn: No other updates. Topic: Web Payments IG Charter Draft Manu Sporny: The charter is here: http://www.w3.org/2014/04/payments/webpayments_charter.html Manu Sporny: There are two weeks left to review the charter and get your feedback in, so if you haven't done so yet, please do so. Manu Sporny: Send all comments in to: public-webpaymentsigcharter@w3.org Manu Sporny: Even if you agree with the entire charter, send comments in stating that you are okay with the charter in its current form. Manu Sporny: Don't worry about doing a thorough line-by-line review if you don't have the time. Some comments are better than none. Manu Sporny: Don't worry about doing a thorough line-by-line review, some comments Manu Sporny: Sections 1 and 2 are the important bits, most everything else is boilerplate and follows standard W3C practices. Manu Sporny: Read about what W3C wants specific input on: http://www.w3.org/community/webpaymentsigcharter/2014/05/15/first-draft-of-future-web-payments-interest-group-charter-published/ Manu Sporny: The World Wide Web Consortium will be having an Advisory Committee meeting on June 6th and 7th and the charter must be in its final form before that meeting. Manu Sporny: We have contacted around 40 companies that have volunteered to review the charter, we sent out communications to ~185 companies, 40 will review and provide feedback, another 30 have committed engineering resources for any working groups that start up Manu Sporny: Some other companies are still trying to get things passed through their legal departments so they can participate Manu Sporny: It looks like we translated momentum into some, at least, light commitments for now Manu Sporny: Any other comments about the IG charter, etc.? Dave Longley: No Topic: Merchant-initiated payments Manu Sporny: We're going to be looking at these use cases today: https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Initiating_Payments Manu Sporny: So, right now we have - Merchant-initiated request for payment. Dave Longley: We might want to clean up the language a bit, might be fine as is? [scribe assist by Manu Sporny] Manu Sporny: Like what? Dave Longley: We could say something like: "A user performs an action, clicks a buy button, merchant creates a payment request to be sent to customer's payment processor." [scribe assist by Manu Sporny] Manu Sporny: "You go to a website, you click on a button and the merchant generates a purchase request to be sent to the customer's payment processor" Manu Sporny: So, what about - Customer selects item to purchase on merchant's site, merchant generates a purchase request that will be processed by the customer's payment processor. Dave Longley: Ok, that's fine. [scribe assist by Manu Sporny] Topic: Customer-initiated payments Manu Sporny: We have this now - Invoke payment service via URI scheme. Simple URI system - simple payment markup that developers get right. Dave Longley: Doesn't sound like a use case, sounds more like a requirement. [scribe assist by Manu Sporny] Dave Longley: The merchant can put a payment link with a specific URI scheme on their website such that when a customer clicks on it, it will invoke the customer's payment service. [scribe assist by Manu Sporny] Dave Longley: It's a slight variant on the first case. [scribe assist by Manu Sporny] Manu Sporny: It's really more of a URI scheme Manu Sporny: Ok, so - A developer can create a payment link with a specific payment URI scheme such that when a customer clicks on it, the customer's payment processor starts the payment process. Dave Longley: Get rid of the first mention of 'payment', otherwise looks good. [scribe assist by Manu Sporny] Topic: Customer-based selection of payment processor Manu Sporny: People can have more than one payment processor, so that when someone goes to pay for something, they need to be able to pick the one they want to use for the particular purchase, so it's negotiation between customer and merchant, if merchant takes paypal and visa, then customer is given option for both of those (if the customer uses them) Dave Longley: It's written as a requirement. So, reword to: When a customer intends to make a payment, they are given a choice of payment processor for all the payment processors they've previously registered with. [scribe assist by Manu Sporny] Manu Sporny: Ok, so - When a customer intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant. Dave Longley: A bit wordy, but a bit more accurate. How that use case gets implemented might not match the use case exactly. [scribe assist by Manu Sporny] Dave Longley: There are details about what "compatible" means wrt. the intersection. [scribe assist by Manu Sporny] Manu Sporny: Ok, sounds good, we'll keep that wording for now. Topic: Payment method switching Manu Sporny: What we have now - Switch payment method in the middle of a transaction. Dave Longley: This makes it seem like the process is a really long one, when it doesn't need to be. Before a transaction is finalized, a customer can pick a different payment processor. [scribe assist by Manu Sporny] Dave Longley: It's going to get tricky/confusing wrt. what "finalized" means. [scribe assist by Manu Sporny] Dave Longley: What we're really trying to say is that "before a customer consents to a transaction, they may change the payment processor that they want to use." [scribe assist by Manu Sporny] Manu Sporny: Ok, so - Before a customer consents to a transaction, they may change the payment processor that they want to use. Dave Longley: It sounds like what this was meant to be about was, if the customer says they want to use a certain payment processor, the pricing might change, which may prompt the customer to change the payment processor. [scribe assist by Manu Sporny] Dave Longley: There has to be a two-step process. The customer says "I want to pay w/ this method, do you want to change the terms?". [scribe assist by Manu Sporny] Manu Sporny: What we do today is just make an offer using each payment mechanism. Dave Longley: That's simpler, I think the part that's out of scope, is the mechanism to select payment processors. We just need to provide the ability to pick different payment methods. [scribe assist by Manu Sporny] Dave Longley: This use case is actually a merchant-based use case. The merchant can advertise different price models based on payment processor choice. [scribe assist by Manu Sporny] Dave Longley: That's really what this use case is about, it'll have a whole bunch of legal/contractual repercussions, but the technology can support this. [scribe assist by Manu Sporny] Manu Sporny: Ok, so this is the use case, then - A merchant advertises different details for an offer of sale based on potential payment processor choice. Manu Sporny: And that's in scope Manu Sporny: We should be asking whether these are in/out of scope Dave Longley: So far everything has been in scope, as far as the changes go. [scribe assist by Manu Sporny] Topic: Loyalty cards and coupons Manu Sporny: So, this is what we have so far - Allow loyalty cards, coupons, etc. as a payment mechanism. Brent Shambaugh: In what way? Manu Sporny: I don't think they are payment mechanisms, one is payment association, the other is to make a payment with Manu Sporny: So, for example - If I'm buying airline tickets, I want to associate my Sky Miles number with the purchase so I can get Sky Miles credited to my account. Brent Shambaugh: Loyalty cards --- association , coupons --- make a payment with Manu Sporny: Or, it could be the application of discounts to the purchase. Brent Shambaugh: Coupons may only reduce purchase... Brent Shambaugh: You may still need a credit card...etc Manu Sporny: The third one is "pay with gift card" Brent Shambaugh: Which is like a credit or debit card in function? Manu Sporny: Yes, exactly. Brent Shambaugh: Basically it is a prepaid card Manu Sporny: What I'm trying to say is that the "pay with gift card" is already covered by other use cases. Manu Sporny: So, we really need to define two use cases for this one. Manu Sporny: So we have 2 use cases here Manu Sporny: Payment association (loyalty cards, etc.) Manu Sporny: Coupons (discounts on a purchase) Manu Sporny: So, what about - Associate a membership card with the transaction such that points or benefits are associated with your membership as a result of a successful purchase. Dave Longley: Too wordy, how about - A customer can associate a membership card with a transaction to receive benefits. [scribe assist by Manu Sporny] Manu Sporny: Sounds good to me. Manu Sporny: Ok, so the next one has to do with applying coupons/discounts. Dave Longley: A customer can use a coupon (or similar) to receive a discount on a transaction. Manu Sporny: Sounds good to me... Brent Shambaugh: So you get then as a result of buying something? like a rewards system for being a good customer? Brent Shambaugh: And the amount in dollars or whatever of what you buy? Dave Longley: You can get some kind of benefit by associating a token w/ a transaction. We could combine them like that. [scribe assist by Manu Sporny] Brent Shambaugh: And the specific type of item? Brent Shambaugh: All associable...perhaps out of scope for this conference Dave Longley: A customer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits. Brent Shambaugh: Okay...makes sense Manu Sporny: Ok, that sounds good - A customer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits. Topic: Remittances Manu Sporny: So, right now we have - Sending money to family internationally via low-cost methods. Manu Sporny: This is pretty vague, seems too deployment-specific/business model-related. Dave Longley: Sounds like it's out of scope. It's too business model related. The only technical requirement is that benefits are gained by standardization that would probably result in the lowering of fees for remittances. [scribe assist by Manu Sporny] Dave Longley: We want this to happen, but it's out of scope wrt. the use case affecting the technology (other than perhaps the international aspect to it, but it's the Web, we only really think of this stuff in an international context w/ localization) [scribe assist by Manu Sporny] Brent Shambaugh: And the cost is generally high...but this is out of scope...agreed Manu Sporny: (In that, we don't gain anything by having it in there). Dave Longley: If we create interoperability, then the "low cost" and "internationally" bits can be met. [scribe assist by Manu Sporny] Manu Sporny: Ok, so, we're agreed - use case doesn't add much and is just an argument for interoperability, which is the basic requirement of any standard. Manu Sporny: So, this particular use case is rejected. Topic: Purchase-specific need-to-know identity Brent Shambaugh: Brent's thought: yes, standards make things easier... Manu Sporny: Ok, so we have this right now - Leveraging variable degrees of identity/anonymity per requirements of the payment transaction. Dave Longley: We already have this use case in the "Identity Use Cases" section. [scribe assist by Manu Sporny] Manu Sporny: Yeah, agreed, we can reject this one because it's a duplicate. Manu Sporny: We already have: Execute a transaction without revealing secrets (i.e. identity, passwords, PINs) whose primary purpose is orthogonal to the actual transaction. Brent Shambaugh: Why orthogonal? Manu Sporny: Orthogonal is hard to understand, what about: A customer executes transaction without revealing secrets (i.e. identity, passwords, PINs) whose primary purpose is not vital to the successful completion of the transaction. Brent Shambaugh: The only problem is when you spoof someone's identity and pay as them Brent Shambaugh: It is called stealing Dave Longley: A customer executes a transaction without revealing secrets (eg: identity, passwords, PINs) that are not vital to the successful completion of the transaction. Brent Shambaugh: But you can complete the transaction nevertheless Manu Sporny: Ok, reword: A customer executes a transaction without revealing secrets that are not vital to the transaction (i.e. identity, passwords, PINs or other information the merchant does not need to know in order to complete the transaction). Brent Shambaugh: This seems wordy? Manu Sporny: Ok, so we deleted that use case and reworded one of the use cases in the identity section. Manu Sporny: Any suggestions on how we could make it less wordy? Brent Shambaugh: Just the stuff in the () is wordy, but it is in () Manu Sporny: We're concerned that it's not clear w/o the stuff in the ()s Manu Sporny: Ok, general agreement that it doesn't hurt to keep the stuff in the ()s Dave Longley: It's fine with me, i don't think we need to spend any more time on it Brent Shambaugh: It clarifies what a secret is? Dave Longley: It provides an example and makes clear what "vital" means (necessary to complete a transaction) (or at least gives an example of vital) Brent Shambaugh: "Or other information the merchant does not need to know in order to complete the transaction" Manu Sporny: Brent, are you suggesting that we remove "identity, passwords, PINs" ? Dave Longley: Brent, can you type in exactly what you'd like the text to be? Brent Shambaugh: A customer executes a transaction without revealing secrets that are not vital to the transaction (i.e. identity, passwords, PINs or or other information that the merchant does not need to know). Manu Sporny: +1 To bshambaugh's final text. Dave Longley: +1 Manu Sporny: I got it... I'll update the use case w/ that. Brent Shambaugh: Thanks Manu. Manu Sporny: Thank /you/, Brent. :)
Received on Wednesday, 21 May 2014 16:51:08 UTC