- From: Tim Holborn <timothy.holborn@gmail.com>
- Date: Sat, 19 Jul 2014 03:27:06 +1000
- To: Joseph Potvin <jpotvin@opman.ca>
- Cc: Web Payments CG <public-webpayments@w3.org>
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 >
Received on Friday, 18 July 2014 17:30:23 UTC