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

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/
>
>
>