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

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

Received on Friday, 18 July 2014 17:09:43 UTC