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

Excellent.

Perhaps add at the end a question with an open text field: "If any use
cases have been missed, please describe, with a reference to
discussion archives if possible."

joseph

On Fri, Jul 18, 2014 at 1:57 PM, 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
>>>
>>
>



-- 
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 18:14:33 UTC