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

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.

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

Received on Friday, 18 July 2014 17:35:49 UTC