Observations on vouchers, coupons and loyalty cards

I have been thinking further about prepaid vouchers, discount coupons and loyalty cards, and how these are related to the architecture and functional requirements and wanted to share them with you for your comments. I apologise for the technical complexity of this email.

In principle, prepaid vouchers, discount coupons and loyalty cards could be handled by a user’s digital wallet using an API exposed by web browsers and brick & mortar payment terminals. This email, however, explores alternative approaches that don’t rely on the user having a digital wallet, and which furthermore minimises the need for new standards.

For online purchases with a merchant, vouchers and coupons previously issued by that merchant to you, could be held on your device by your browser using cookies or HTML5 web storage. The merchant’s website would be responsible for managing this.  The browser enforces the single origin policy so that data is sandboxed and not shared with other sites.   A variant is to hold the vouchers/coupons on the merchant’s backend system and rely on a means to identify the user, e.g. with a persistent cookie, or by having encouraged the user to register with that merchant, e.g. to unlock special offers and discounts only available to registered users. The merchant’s website would enable you to apply the vouchers/coupons when you make a purchase. There is nothing new about this and no new standards are needed.

For marketing purposes, a merchant might have an advertising campaign that places ads on different websites.  The ads are delivered by an advertising network.  The ad could in principle include a graphical depiction of a voucher or coupon. If the user clicks/taps on that, it is held by the ad network on behalf of the user in the same way as vouchers/coupons issued directly by the merchant.  For example, the ad network could set a persistent cookie to identify the user in subsequent browser sessions.

When the user visits the merchant’s site, the webpage includes an image or an iframe with content from the ad network.     A session specific unique id is included in the URI for that content. This allows the merchant’s server to communicate with the ad network in the background to access information on which vouchers/coupons users have collected while browsing the web.

A variant on this is to replace the ad network with a cross vendor loyalty card.  Each time the user makes a purchase with a merchant that supports the card, then points are added to the user’s account, and can subsequently be used to offset future purchases. Participating merchants include an image for the loyalty card as part of their web pages, where this image is loaded from the web server for the company that operates the card.

All of this is based upon existing standards, e.g. for cookies, web storage, HTTP, scripting and so forth. There is no need for integration with a user’s digital wallet.

What about purchases at brick & mortar stores?  It would be nice if the vouchers/coupons can be collected and used in both online and brick & mortar stores, right?  What do we need to do to make this work together with the technical approaches outlined above for online purchases?

In one model, the user pays by tapping her phone to a payment terminal at the checkout. The terminal treats the phone as a contactless payment card for payments. However, the terminal is also able to identify the phone in some way (e.g. an NFC id) and link it to the user’s registered account with the merchant. This allows the merchant to apply any applicable vouchers/coupons before making the payment request.

A refinement is for the payment terminal to be implemented in HTML5 and executed by an embedded browser. This enables the merchant to ask users whether they want to apply the vouchers/coupons or to save them for use with future purchases. The payment terminal could have a touch screen that allows user to interact with the HTML5 page the terminal is displaying. This approach allows the merchant to customise the user experience which could be an attractive feature compared to existing payment terminals.

The user could be issued with a plastic loyalty card that has to be swiped to identify the user’s account. Today it is common to rely on the card’s magnetic stripe, but it is easy to imagine a contactless loyalty card based upon NFC. You would be asked to tap this to the payment terminal before tapping your phone or payment card.  In principle, payment cards could also play the role of loyalty cards, so that you can use one card for both purposes.  A phone could also play this role. A single tap would be sufficient for the payment terminal to identify and apply applicable vouchers/coupons, and to make the payment.  This would be extended to two taps if the payment terminal asks you to choose whether to apply applicable vouchers/coupons and tap again to make the payment. If the payment terminal is implemented in HTML5, this would require a new browser API for accessing the loyalty card.  We already have a W3C NFC Community Group working on this API, and just need to convince them of our use case.

Rather than a physical loyalty card,  we could allow the payment terminal to access cookies/web storage held by the browser on the user’s phone. This could be based upon a peer to peer message exchange. The challenge would be to enforce the single origin security policy.  This could involve the payment terminal proving that the merchant  owns the designated origin.  This would require a protocol supported by browsers along with a means for managing the communication session (e.g. over NFC, BLE or WiFi). This requires a new relatively complex standard.

Another model is for the payment terminal to be dumb and to rely on the browser in the phone to provide the user interface. Tapping on the payment icon at the checkout triggers the browser to load the checkout web page. This might, for instance, involve an NFC action that loads the checkout page with the URI embedding an id for the checkout. This allows the merchant’s checkout page to identify the transaction including the amount to be charged, and the list of items being purchased. This is then effectively the same as an online purchase, and has the advantage of reducing the cost of the payment terminal to a dumb NFC ID tag.  The downside is that it requires the user’s phone to be online, e.g. using the store’s wifi access points.  This approach uses existing standards!

What about digital receipts?  Users will want to accumulate these within their digital wallet. For online purchases, the merchant’s web page would save this to the wallet via a browser API that W3C defines for that purpose. In the brick & mortar scenario where the payment terminal uses HTML5, then we would need a means to inform the merchant of the URI for the wallet. Several possibilities come to mind.  We could use NFC to request the wallet URI from a loyalty card or phone at the time of a purchase, or we could do this when the user sets up an account with a merchant — using a web page that is able to ask the browser for the wallet API. Both of these possibilities call for a new, but simple standard.

In the above, the wallet doesn’t hold vouchers, coupons or loyalty cards. However, in principle, the wallet could keep a list of the loyalty schemes you are enrolled with, and provide a means to view the status for each of these. This would require a new standard for registering a loyalty scheme with the wallet.

In summary, whilst we have been talking about holding vouchers, coupons and loyalty cards as part of the user’s digital wallet, there are other possibilities that minimise the need for new standards.  Using HTML5 in payment terminals along with a simple NFC API to identity the user’s account with a merchant, and server-side storage seems like an attractive solution that could work with existing loyalty cards and contactless payment cards. This approach favours cloud based digital wallets.

I look forward to an opportunity to discuss the implications for the architecture with other Web Payments IG members!

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>