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 payment URI
> scheme such that when a customer clicks on it, the customer's payment
> processor starts the payment process.

+1

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

+0
ideally there should be an option to set the default payment processor for
that merchant, so the NASCAR selection only needs to happen once.

> Use Case: A merchant advertises different details, such as price, for an
> offer of sale based on potential payment processor choice.

-1
the two above that allow the merchant to limit who can be a payment
processor seems like it would kill any small payment processors. i'd like
to see the ability to be your own payment processor as a use case. given
that there still needs to be a trusted third party between merchant and
buyer, maybe a middle ground is to allow the buyer to choose a major
payment processor listed by the merchant as a trusted proxy for their
preferred payment processor. inter-processor transactions seem to be
supported:
https://web-payments.org/specs/source/web-payments/#the-decentralized-settlement-process
..

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

+1

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

+1

> 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, if there is a user flow for proxying from payment processors included
by merchant to another payment processor as described above.

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

+1

> 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, if proxying as described above happens by default if chosen as an
option before.

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

not sure how different from "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 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, although double negative "don't prevent" is confusing, maybe allow?

> Design Criteria: Don't prevent the implementation of simple digital
> contracts and smart contracts.

+1, although double negative "don't prevent" is confusing, maybe allow?

---

so how do i add a use case?

Use Case: When a customer intends to make a payment, it is possible to pick
a payment processor trusted by the merchant as an intermediate proxy for a
payment processor not trusted by the merchant.

cheers,
Michael