Re: VOTE: Revised Payment Initiation / Wallet Web Payments Workshop Use Cases

Your time on it is very much appreciated.   Good idea to get onto it too..

Separately? I do think we should be using / improving some of the tools we're so passionate about, especially when we can improve what we're doing, but using them...

But - I very much appreciate the time thing... 

Sent from my iPad

> On 19 Jul 2014, at 3:57 am, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
> 
> Getting on a plane now but have a look and let me know if this format will work.
> https://docs.google.com/a/hopebailie.com/forms/d/1_vuxlxdL0MCf5eudEG--2kJFUbcYFPvhvzYT3OSOxRw/viewform
> 
> Will add all use cases later today
> 
> 
>> On 18 July 2014 19:51, Timothy Holborn <timothy.holborn@gmail.com> wrote:
>> FYI - https://ld-cal.rww.io/
>> 
>> Sent from my iPad
>> 
>>> On 19 Jul 2014, at 3:47 am, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>>> 
>>> Will throw a quick sample together on a Google Form and share the link.
>>> If you we're all happy I will add all of the use cases.
>>> 
>>> 
>>>> On 18 July 2014 19:42, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>> ... actually, the options ought to be
>>>> 
>>>> - In favor for v1.0
>>>> - In favor for later version
>>>> - Opposed
>>>> - Open-ended text field for comments/suggestions
>>>> 
>>>> On Fri, Jul 18, 2014 at 1:38 PM, Timothy Holborn
>>>> <timothy.holborn@gmail.com> wrote:
>>>> >
>>>> >
>>>> > Sent from my iPad
>>>> >
>>>> >> On 19 Jul 2014, at 3:35 am, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>> >>
>>>> >> 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.
>>>> >>
>>>> > +1 and use some basic formatting for the output, like csv - good for importing into a spreadsheet...
>>>> >
>>>> >> 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
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Joseph Potvin
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> jpotvin@opman.ca
>>>> Mobile: 819-593-5983
>>>> 
>>> 
>