- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Fri, 18 Jul 2014 13:08:53 -0400
- To: Web Payments <public-webpayments@w3.org>
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
Received on Friday, 18 July 2014 17:09:43 UTC