Payments Use Cases / Suggestions for Interest Group

   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.


-------------------------


Partly inspired by: Web Payments Use Cases on the CG wiki:
https://www.w3.org/community/webpayments/wiki/WebPaymentsUseCases_r1


Cheers