W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2014

Re: Payments Use Cases / Suggestions for Interest Group

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Wed, 3 Dec 2014 21:59:16 -0600
Message-ID: <CACvcBVrhnX0nLjF+hqtPHnWVM7AKLLEVxP038iOtwhp=UNYn4g@mail.gmail.com>
To: Web Payments CG <public-webpayments@w3.org>
51. Allow automated conversion of currency or pseudo-currency so each agent
receives their preferred one.

-Brent Shambaugh

Website: bshambaugh.org

On Wed, Dec 3, 2014 at 9:48 PM, Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

>
>    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
>
Received on Thursday, 4 December 2014 03:59:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC