Payments Use Cases / Suggestions for Interest Group from Brent Shambaugh

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.

13.

    Separate content from licenses.

14.

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

14.

    Customers should only pay when the transaction closes

15.

    For large payment amounts, enable two-factor authentication

16.

    Support web browser and in-app payments

17.

    Allow agents to make multiple payments in one action

18.

    Allow agents to receive loans or payments from multiple other agents

19.

    Support offline mobile to mobile payments

20.

    Allow agents to accept and receive payments to particular destinations.

21.

    Skip signatures for small payments

22.

    Allow for bank issued identification

23.

    Support instant (or near instant) settlement of transactions

24.

    Allow editing of business and accounting information

25.

    Allow for many forms of authentication of identity (including
    possible futures). (e.g. Authenticate payments with brain waves (EEG)).

26.

    Allow for chargebacks (refunds due to error)

27.

    Support all currencies, all cards, and all bank accounts

28.

    Allow wallet to be interoperable with other wallets.

29.

    Allow payment network to be interoperable with other payment networks.

30.

    Allow user issued pseudo-currency. Issue securities and tokens of
    any kind.

31.

    Support micropayments.

32.

    List things purchased (digital receipts). Verifiable recipts.

33.

    Use tokens in place of card numbers. Avoid revealing bank and credit
    information.

34.

    Allow for time delayed transactions. Hold funds in escrow until
    transaction occurs.

35.

    Distribute public key for communication.

36.

    Give IDs to each object in payments.

37.

    Initiate and request transactions.

38.

    Refund debits, reverse credits.

39.

    Support billing through subscriptions.

40.

    Give a record of debts for each billing period.

41.

    Buy and sell debt on the open market.

42.

    Keep a balance.

43.

    Include an API.

44.

    Retry failed payments.

45.

    PCI Compliance.

46.

    Pay for items before entering store.

47.

    Store information to avoid re-entering.

48.

    Apply and store gifts, credits, and coupons.

49.

    REST compliance.

50.

    Support irreversible transactions.

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