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

Re: Payments Use Cases / Suggestions for Interest Group

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 04 Dec 2014 07:25:32 +0100
Message-ID: <547FFE5C.5040107@gmail.com>
To: Brent Shambaugh <brent.shambaugh@gmail.com>, Web Payments CG <public-webpayments@w3.org>
Brent,
IMO (FWIW), the IG needs to come up with something that:

1. "Makes a difference"
2. Gets supported by Google
3. *Cannot* be done with existing web technology

What this could be, is entirely up in the blue at this stage.

Anders

On 2014-12-04 04:48, Brent Shambaugh 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.
>
> 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.
>
>
> -------------------------
>
>
> 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 06:26:44 UTC

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