- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Fri, 18 Jul 2014 13:35:02 -0400
- To: Tim Holborn <timothy.holborn@gmail.com>
- Cc: Web Payments CG <public-webpayments@w3.org>
I'd offer to put it up, but am overcommitted presently. Each item should have, I think, radio buttons foy Y/N, plus an open-ended text field for comments. Joseph On Fri, Jul 18, 2014 at 1:27 PM, Tim Holborn <timothy.holborn@gmail.com> wrote: > Nice Idea. > > Could simply be a form that’s run on rww.io / data.fm - mind, people would need to get a WebID (cimba.co makes that simple…) > > On 19 Jul 2014, at 3:08 am, Joseph Potvin <jpotvin@opman.ca> wrote: > >> Is anybody in this GC running an instance of LimeSurvey or equivalent >> that we might conduct a more efficient poll on, or use SurveyMonkey? >> (Or did I miss something about that?) >> >> Joseph >> >> On Fri, Jul 18, 2014 at 12:14 PM, Adrian Hope-Bailie >> <adrian@hopebailie.com> wrote: >>> Use Case: Customer selects item to purchase on merchant's site, merchant >>> generates a purchase request that will be processed by the customer's >>> payment processor. >>> +1 >>> >>> Use Case: A developer can create a link with a specific “attribute (custom >>> URI >>> scheme or rel type)” such that when a customer clicks on it, the customer's >>> payment >>> processor starts the payment process. >>> +1 Updated use case - Is URI scheme the only way to do this? >>> >>> Use Case: 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. >>> +1 >>> >>> Use Case: A merchant advertises different details, such as price, for an >>> offer of sale based on potential payment processor choice. >>> +1 >>> >>> Use Case: A customer can associate a membership card, coupon, or similar >>> token with a transaction to receive a discount or other benefits. >>> +0 For later iterations >>> >>> Use Case: Leveraging variable degrees of identity/anonymity per >>> requirements of the payment transaction. >>> +0 For later iterations >>> >>> Use Case: 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. >>> +1 >>> >>> Use Case: 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. >>> +1 >>> >>> >>> Use Case: A customer makes a purchase from within an application for >>> premium content, virtual goods, or subscriptions. >>> +1 >>> >>> >>> Use Case: Temporary payment tokens for merchants. If token is stolen, >>> thief does not get access to financial account. Tokenization mechanism >>> that protects the buyer and merchant from theft of credentials. >>> +1 >>> >>> Use Case: The customer goes to a merchant website and clicks a buy >>> button to complete a purchase without having to go through any >>> registration process. During the purchase the customer chooses which >>> information to share with the merchant which the merchant then uses to >>> uniquely identify the customer if they perform any repeat purchases. >>> +0 For later iterations >>> >>> Use Case: A customer goes to a website and is presented with a payment >>> UI from their payment processor. The purchase can be completed without >>> any additional information from the customer other than their consent to >>> complete the purchase. >>> +1 >>> >>> Use Case: A customer goes to a merchant website, and upon initiating a >>> payment, the merchant's software transmits the merchant's payment >>> processor options to the customer's software. The customer's software >>> presents a choice of payment processors the customer has previously >>> registered with that are compatible with the merchant's payment processors. >>> +1 >>> >>> Use Case: A customer visits a merchant's website and initiates a >>> payment. Their payment processor presents them with an option to >>> subscribe or add a pay-as-you-go token for future purchases from the >>> merchant. >>> +1 >>> >>> Design Criteria: Consider using Web Intents or Protocol Handlers to >>> provide an abstraction layer that could be used to solve both payment >>> initiation and other problems on the Web. >>> +1 >>> >>> Use Case: A customer stores their wallet, credentials, and digital >>> receipts with a particular identity/wallet/data storage provider. The >>> customer decides to switch to a different identity/wallet/data storage >>> provider and all of their wallet, receipt, and credential data comes >>> with them. >>> +1 >>> >>> Design Criteria: Require data portability for customer financial data >>> and identity data that is required for core transaction functionality. >>> +1 >>> >>> Design Criteria: Ensure the Web payments solution can provide an >>> abstraction layer that integrates with existing payment methods (eg: >>> VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.) >>> +1 >>> >>> Design Criteria: Don't prevent multiple levels of security based on the >>> type of transaction being performed. No auth for small amounts, PIN auth >>> for medium amounts, Secure Element for large amounts. >>> +1 >>> >>> Design Criteria: Don't prevent the implementation of simple digital >>> contracts and smart contracts. >>> +1 >>> >>> >>> >>> On 17 July 2014 03:51, Manu Sporny <msporny@digitalbazaar.com> wrote: >>>> >>>> Please +1/+0/-1 each payment initiation / wallet use case below in order >>>> to show whether or not you agree that we should try and attempt >>>> addressing the use case in the first iteration of the Web Payments work. >>>> If you +0 or -1 the use case, please specify why as well as changes that >>>> could be made that would result in you +1'ing the use case. >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Use Case: Customer selects item to purchase on merchant's site, merchant >>>> generates a purchase request that will be processed by the customer's >>>> payment processor. >>>> >>>> Use Case: A developer can create a link with a specific payment URI >>>> scheme such that when a customer clicks on it, the customer's payment >>>> processor starts the payment process. >>>> >>>> Use Case: 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. >>>> >>>> Use Case: A merchant advertises different details, such as price, for an >>>> offer of sale based on potential payment processor choice. >>>> >>>> Use Case: A customer can associate a membership card, coupon, or similar >>>> token with a transaction to receive a discount or other benefits. >>>> >>>> Use Case: Leveraging variable degrees of identity/anonymity per >>>> requirements of the payment transaction. >>>> >>>> Use Case: 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. >>>> >>>> Use Case: 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. >>>> >>>> Use Case: A customer makes a purchase from within an application for >>>> premium content, virtual goods, or subscriptions. >>>> >>>> Use Case: Temporary payment tokens for merchants. If token is stolen, >>>> thief does not get access to financial account. Tokenization mechanism >>>> that protects the buyer and merchant from theft of credentials. >>>> >>>> Use Case: The customer goes to a merchant website and clicks a buy >>>> button to complete a purchase without having to go through any >>>> registration process. During the purchase the customer chooses which >>>> information to share with the merchant which the merchant then uses to >>>> uniquely identify the customer if they perform any repeat purchases. >>>> >>>> Use Case: A customer goes to a website and is presented with a payment >>>> UI from their payment processor. The purchase can be completed without >>>> any additional information from the customer other than their consent to >>>> complete the purchase. >>>> >>>> Use Case: A customer goes to a merchant website, and upon initiating a >>>> payment, the merchant's software transmits the merchant's payment >>>> processor options to the customer's software. The customer's software >>>> presents a choice of payment processors the customer has previously >>>> registered with that are compatible with the merchant's payment >>>> processors. >>>> >>>> Use Case: A customer visits a merchant's website and initiates a >>>> payment. Their payment processor presents them with an option to >>>> subscribe or add a pay-as-you-go token for future purchases from the >>>> merchant. >>>> >>>> Design Criteria: Consider using Web Intents or Protocol Handlers to >>>> provide an abstraction layer that could be used to solve both payment >>>> initiation and other problems on the Web. >>>> >>>> Use Case: A customer stores their wallet, credentials, and digital >>>> receipts with a particular identity/wallet/data storage provider. The >>>> customer decides to switch to a different identity/wallet/data storage >>>> provider and all of their wallet, receipt, and credential data comes >>>> with them. >>>> >>>> Design Criteria: Require data portability for customer financial data >>>> and identity data that is required for core transaction functionality. >>>> >>>> Design Criteria: Ensure the Web payments solution can provide an >>>> abstraction layer that integrates with existing payment methods (eg: >>>> VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.) >>>> >>>> Design Criteria: Don't prevent multiple levels of security based on the >>>> type of transaction being performed. No auth for small amounts, PIN auth >>>> for medium amounts, Secure Element for large amounts. >>>> >>>> Design Criteria: Don't prevent the implementation of simple digital >>>> contracts and smart contracts. >>>> >>>> -- manu >>>> >>>> -- >>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>>> Founder/CEO - Digital Bazaar, Inc. >>>> blog: The Marathonic Dawn of Web Payments >>>> http://manu.sporny.org/2014/dawn-of-web-payments/ >>>> >>>> >>> >> >> >> >> -- >> Joseph Potvin >> Operations Manager | Gestionnaire des opérations >> The Opman Company | La compagnie Opman >> jpotvin@opman.ca >> Mobile: 819-593-5983 >> > -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983
Received on Friday, 18 July 2014 17:35:49 UTC