W3C home > Mailing lists > Public > public-webpayments@w3.org > July 2014

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

From: Joseph Potvin <jpotvin@opman.ca>
Date: Fri, 18 Jul 2014 13:42:11 -0400
Message-ID: <CAKcXiSr+wRKZtJeaXcB_mWN_-WGWFLqAN5_kf8Sm6A3UfoDBoA@mail.gmail.com>
To: Timothy Holborn <timothy.holborn@gmail.com>
Cc: Web Payments CG <public-webpayments@w3.org>
... 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
Received on Friday, 18 July 2014 17:43:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC