- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 04 Dec 2014 07:25:32 +0100
- 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