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

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
>
>