- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 04 Dec 2014 20:43:44 -0500
- To: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <54810DD0.8000401@digitalbazaar.com>
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
Received on Friday, 5 December 2014 01:44:19 UTC