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

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


I wish to ask if the "value-in-exchange benchmarking" issue I
presented about in Paris is intended to be incorporated in this use
case, or is benchmarking elsewhere and I haven't noticed?  In my
3-minute presentation, I illustrated this with screenshots from my
online purchase of the dinner during that same event:
http://www.w3.org/2013/10/payments/slides/session4_potvin.pdf

During the PayPal sequence, a payer is presented with two choices of
"conversion rate" (aka "exchange rate"), the PayPal or the Credit
Cards' rates. Those, as we know, are just two of the potential
value-in-exchange benchmarks that are possible once web payments break
free of the constraint that there are only a very few choices.
Actually they differ in their processing fees, but both are based on
the WM Reuters spot exchange rate
http://www.wmcompany.com/pdfs/WMReutersMethodology.pdf     ...which
has raised some integrity concerns of late:
http://www.theguardian.com/business/2014/jul/21/foreign-exchange-trading-criminal-investigation-serious-fraud-office

F. Hayek believed "a monopoly, or ... power to limit the kinds of
money in which contracts may be concluded ... or to determine the
rates at which monies can be exchanged, to be wholly harmful". (Choice
in Currency, 1976).

Some see this as an "academic" issue, and well, me too, as my
forthcoming (2015) doctoral dissertation is entitled "Peer-to-peer
price attribute control (P2P-pac)". But this is far from only being
academic. It seems to me central to achieving the core pragmatic
purposes of this CG. In a sentence form my dissertation intro, I
suggest: "If sellers and buyers are to negotiate secure price in an
open market, then they must be free to choose all three essential
attributes of the numeric quantity expressing a price (e.g. 10.99),
namely: a unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange
(e.g. debit card, credit card, web payment etc.); and, a
value-in-exchange benchmark (e.g. WM Reuters Spot Exchange; Purchasing
Power Parity; Commodity Index; etc.)"

Let me propose a restatement of that as a "use case":

Use Case: Payee and payers negotiate secure price in an open market.
They are free to choose all three essential attributes of the numeric
quantity expressing a price (e.g. 10.99), namely: a unit-of-account
(e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g. debit card, credit
card, web payment etc.); and, a value-in-exchange benchmark (e.g. WM
Reuters Spot Exchange; Purchasing Power Parity; Commodity Index; etc.)

Should anyone think such choices would be too complicated for users,
we can discuss. I recommend that these matters can be handled rather
simply through payee and payer setting their global preferences with
ranked options. For example, on unit of account, Payee prefers to
receive US$, then €, then ¥; Payer prefers to pay €, then ¥, then US$;
so that transaction occurs in €.  This can be done with the other
attributes also.  And if no preferences are set, the system can
default to the payee's default without "choice in currency" as Hayek
outlined it.

-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

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

Received on Tuesday, 22 July 2014 12:51:08 UTC