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

I like the idea of using a form, and Adrian's Google form looks great, but
in the meantime I'll just share my votes here, and I look forward to see
yours.


On Wed, Jul 16, 2014 at 8:51 PM, 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: A developer can create a link with a specific payment URIscheme
> such that when a customer clicks on it, the customer's paymentprocessor
> starts the payment process.*

*+1*
This is my favorite approach. No NASCAR problem, no list of payment
processors, just an email with a payment link.
It could be implemented with a simple form with text field for inputs like '
wallet.example.com/walletID' or 'walletID@walletexample.com' (maybe with a
drop down menu), make an API call to the example provider and let the
provider send the email with the payment link if the transaction is
possible.


>
>
> *Use Case: Temporary payment tokens for merchants. If token is
> stolen,thief does not get access to financial account. Tokenization
> mechanismthat protects the buyer and merchant from theft of credentials.*
>
*+1*
Generating links and tokens per transaction would be very simple yet
powerful and secure.


> *Use Case: A customer makes a purchase from within an application
> forpremium content, virtual goods, or subscriptions.*
>
*+1*
However, without embedding wallets, but by obtaining delegated access
through OAuth tokens.



Use Case: The customer goes to a merchant website and clicks a buy
button to complete a purchase
*without having to go through anyregistration process*. During the purchase
*the customer chooses whichinformation to share with the merchant *which
the merchant then uses to
uniquely identify the customer if they perform any repeat purchases.
*+1*
Low friction, privacy control.

Use Case: A customer can associate a membership card, coupon, or similar
> *token* with a transaction to receive a discount or other benefits.
>
*+1*
Tokens.

Use Case: Leveraging variable degrees of *identity/anonymity* per
> requirements of the payment transaction.

*+1*
This is very easy to achieve by assigning both a clear ID (e.g.
'aliceWallet') and an opaque ID (e.g. a Bitcoin-like base58 address
'gnT8mv9PBb9i7wFSFmGevjartKF') to each wallet and exposing certain
information according to the ID used.

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*
Microtransactions.




 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.)
*+0*
Compatibility is always good, but sometimes complicated, and even more for
the entry-level payment provider trying to achieve PCI compliance.
Excluding SMS, this is very high-end, and doesn't apply to the 2.5 billion
unbanked.

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.
>
*+0*
If generating the purchase request is equivalent to generating a link or
token, +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.
*+0*
The capability of switching wallet hosting providers would be great, but I
guess it would be hard to achieve if there is balance to be transferred
that would imply one provider sending actual money to another.

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.
*+0*
Pay-as-you-go tokens sound good, but what about choosing the payment
processor first?

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.
>
*+0*
Native apps are ok as long as they use the Web infrastructure for the
transactions (e.g. REST APIs)


> Use Case: A merchant advertises different details, such as price, for an
> offer of sale based on potential payment processor choice.
>
> *+0*
It makes a lot of sense, and it happens a lot in online games, but maybe it
would be hard to define or predict 'potential choice' if the user is not
even registered but just browsing several sites to compare prices and make
an actual choice.




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 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 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 *
NASCAR problem.


> 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*
Custom payment UIs are not the way to go in my opinion.





> 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.
>
> Design Criteria: Require data portability for customer financial data
> and identity data that is required for core transaction functionality.
>
> Design Criteria: Don't prevent the implementation of simple digital
> contracts and smart contracts.
>
> No opinion.


On Wed, Jul 16, 2014 at 8:51 PM, 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/
>
>
>