Difference between revisions of "2013 Web Payments - Ecosystem"
(→Peer to Peer)
|Line 16:||Line 16:|
=== Peer to Peer ===
=== Peer to Peer ===
Revision as of 13:18, 1 March 2013
This page is intended as a top level characterization of the ecosystem for payments as it relates to the requirements for realizing open standards for web payments. The assumption is that any standard defined by W3C would be layered on top of existing (or new) payment solutions and decoupled as far as practical from the details of each such solution.
Main types of payment
For example, payments in a store through a point of sales terminal, or payment for a metro ticket at a station kiosk. NFC payments offer a convenient user experience for this, but an alternative is for the phone to display a QR Code that is scanned by the point of sales terminal, as is the case with the Starbucks mobile app for their card account holders. Users may want to select the exact means of payment according to their preferences. For example, imagine your phone supports a virtual wallet with a range of cards. On the London Underground you might prefer to use your Oyster card rather than your Barclaycard. Proximity payments should not require your device to be online as there are use cases where that would be impractical, e.g. paying for a taxi in a remote area with poor mobile coverage.
An online point of sales terminal (POS) may need to be online to perform a transaction, but even where this isn't needed, it can offer greater flexibility when it comes to dealing with larger payments, or payments that involve third parties as a means to bridge gaps, e.g. for a tourist visiting a store in a foreign country.
There is emerging interest in using Web technologies in point of sales terminals as a means to reduce costs. There are also opportunities for two screen solutions where information is presented on both the user's phone and on the point of sales terminal. This could relate to the use of prepaid vouchers or discount coupons. Does the user want to make use of these to reduce the net payment in the current transaction? Does the store want to inform the user that he or she is being given discount coupons for future use? A further possibility is to support paper coupons (e.g. with QR codes) that are scanned as part of the transaction.
Examples include paying a bill online, topping up a prepaid mobile phone account, or transferring money to another person who isn't currently present.
Peer to Peer
This includes person to person payments where both parties are physically present. In principle, it should be as simple a user experience as it is to hand someone some cash. This raises challenges to avoid double spending, and to ensure that the "money" transferred is directly usable by the recipient for further transactions without needing to be online. One approach to realizing this involves a secure element that acts as a local wallet for a specific payment system. This can be topped up and drawn down as needed. Such payment systems tend to be limited to specific contexts, but in principle, can be coupled to other payment systems when you are able to go online.
Another approach is a form of virtual cheque that has to be paid in before its value can be redeemed. A digital signature replaces the handwritten personal signature. This may necessitate additional mechanisms for authenticating the person "writing" the cheque, for example, the virtual cheque could be written by a secure element that checks that you are present via a biometric test such as a finger print scan, or by requiring you to input a PIN. The bank underwriting the cheques would issue account holders with a virtual chequebook. This would be invoked from the web payment API in the same way as other payment solutions.