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

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

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Fri, 18 Jul 2014 19:57:25 +0200
Message-ID: <CA+eFz_Ju=pVCAxkU+GVD8iwA_EhzB1BUs=FH3-T=aux0upRa0w@mail.gmail.com>
To: Timothy Holborn <timothy.holborn@gmail.com>
Cc: Joseph Potvin <jpotvin@opman.ca>, Web Payments CG <public-webpayments@w3.org>
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
>>
>>
>
Received on Friday, 18 July 2014 17:57:54 UTC

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