Re: Payments Use Cases / Suggestions for Interest Group from Brent Shambaugh

+1  great work.  really useful dot points (which are always more difficult
to build, than they are to read, when done well :) )

On 5 December 2014 at 12:43, Manu Sporny <msporny@digitalbazaar.com> wrote:

>  These are a set of requirements and use cases that Brent Shambaugh (of
> the Web Payments CG and Web and Mobile CG) has been collecting/analyzing
> over the past year. Brent offered to send these into the group on this past
> week's Web Payments CG call for the purpose of forwarding them to the IG.
> We already have some of them covered, others we don't have covered at all.
> For example, the VRM principles out of Doc Searls' group at Harvard is
> something Joerg mentioned at the Web Payments F2F, but we failed to note in
> detail. Good stuff, we should take a look at it.
>
> The original email from Brent can be found here:
>
> http://lists.w3.org/Archives/Public/public-webpayments/2014Dec/0006.html
>
> --------------------------------------------------------------------------
>
>
>    1.
>
>    Allow the use of multiple devices
>     2.
>
>    Allow the use of SMS both for notifcations and for payments
>     3.
>
>    Decentralize the payment authority and allow for peer-to-peer
>    payments. Decentralized domain name system.
>     4.
>
>    Allow pre-authorization of a single payment, or multiple payments.
>     5.
>
>    Automated recurring payments.
>     6.
>
>    Encrpyt information if it is stored on a centralized server.
>     7.
>
>    Risk and anti-fraud screening.
>     8.
>
>    Support having no account history with vendor.
>     9.
>
>    Support anonymous payments.
>     10.
>
>    Support machine readable data that is distributed.
>     11.
>
>    Support metadata attached to content, such as licenses, asset
>    information (e.g. description, pricining), obligations to other
>    agents...etc..
>     12.
>
>    Support automated vending when identity proven.
>
>
>    1.
>
>    Separate content from licenses.
>     2.
>
>    Support VRM principles for customer-vendor relationships
>
>
>    -
>
>    Customers must enter relationships with vendors as *independent actors*.
>
>     -
>
>    Customers must be the *points of integration for their own data*.
>     -
>
>    Customers must have *control of data they generate and gather*. This
>    means they must be able to share data selectively and voluntarily.
>     -
>
>    Customers must be able to *assert their own terms of engagement*.
>     -
>
>    Customers must be *free to express their demands and intentions
>    outside of any one company's control*.
>
>
>     *(http://cyber.law.harvard.edu/projectvrm/Main_Page
>    <http://cyber.law.harvard.edu/projectvrm/Main_Page>)*
>    1.
>
>    Customers should only pay when the transaction closes
>     2.
>
>    For large payment amounts, enable two-factor authentication
>     3.
>
>    Support web browser and in-app payments
>     4.
>
>    Allow agents to make multiple payments in one action
>     5.
>
>    Allow agents to receive loans or payments from multiple other agents
>     6.
>
>    Support offline mobile to mobile payments
>     7.
>
>    Allow agents to accept and receive payments to particular destinations.
>     8.
>
>    Skip signatures for small payments
>     9.
>
>    Allow for bank issued identification
>     10.
>
>    Support instant (or near instant) settlement of transactions
>     11.
>
>    Allow editing of business and accounting information
>     12.
>
>    Allow for many forms of authentication of identity (including possible
>    futures). (e.g. Authenticate payments with brain waves (EEG)).
>     13.
>
>    Allow for chargebacks (refunds due to error)
>     14.
>
>    Support all currencies, all cards, and all bank accounts
>     15.
>
>    Allow wallet to be interoperable with other wallets.
>     16.
>
>    Allow payment network to be interoperable with other payment networks.
>     17.
>
>    Allow user issued pseudo-currency. Issue securities and tokens of any
>    kind.
>     18.
>
>    Support micropayments.
>     19.
>
>    List things purchased (digital receipts). Verifiable recipts.
>     20.
>
>    Use tokens in place of card numbers. Avoid revealing bank and credit
>    information.
>     21.
>
>    Allow for time delayed transactions. Hold funds in escrow until
>    transaction occurs.
>     22.
>
>    Distribute public key for communication.
>     23.
>
>    Give IDs to each object in payments.
>     24.
>
>    Initiate and request transactions.
>     25.
>
>    Refund debits, reverse credits.
>     26.
>
>    Support billing through subscriptions.
>     27.
>
>    Give a record of debts for each billing period.
>     28.
>
>    Buy and sell debt on the open market.
>     29.
>
>    Keep a balance.
>     30.
>
>    Include an API.
>     31.
>
>    Retry failed payments.
>     32.
>
>    PCI Compliance.
>     33.
>
>    Pay for items before entering store.
>     34.
>
>    Store information to avoid re-entering.
>     35.
>
>    Apply and store gifts, credits, and coupons.
>     36.
>
>    REST compliance.
>     37.
>
>    Support irreversible transactions.
>     38. Allow automated conversion of currency or pseudo-currency so each
>    agent receives their preferred one.
>
>
>  -------------------------
>
>
>  Partly inspired by: Web Payments Use Cases on the CG wiki:
> https://www.w3.org/community/webpayments/wiki/WebPaymentsUseCases_r1
>