RE: Observations on vouchers, coupons and loyalty cards

Hello David, and Katie,

A great topic – actually one that made us build the wallet the way we did! Through the ‘itemization’ approach we have built common ground for coupons/ loyalty in the physical and the virtual world. Particularly being able to combine modes – get your coupon online, redeem it in the supermarket, etc. The coupon btw. is important to be visible for planning your shopping, as a customer you might focus on the discount, for the issuer it needs to be visible as often as it makes sense. This can be served much better in the client/ itemization approach. BTW: once introduced – as Katie already referred to – online implementations are absolutely feasible.

However, the most important aspect from a (what I hope W3C stands for) privacy point of view: There’d be no way to avoid that the issuer gets to know exactly when and where I attempted to use these coupons if we based our work on this approach. If we do it item-based, we can easily adopt existing processes and allow for a decoupling of receiving and using these items. There are even rules and regulations in many countries (not only mine – but they usually take this very serious here) which might cause difficulties…

Cheers,
                Jörg

From: Dave Raggett [mailto:dsr@w3.org]
Sent: Dienstag, 24. März 2015 13:52
To: Katie Haritos-Shea GMAIL
Cc: Web Payments IG
Subject: Re: Observations on vouchers, coupons and loyalty cards


On 24 Mar 2015, at 00:47, Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>> wrote:

Dave,

I do not want to stem your enthusiasm or your very broad technical ideas and input – but (you knew that was coming….:-)……

and apologies once more for the length/complexity of the reply :-)



I am thinking that vendors/merchants and financial institutions shall want to brand/skin an open web digital wallet – and offer their ‘vouchers, coupons and loyalty’ offerings maybe most prevalently in their skinned versions.

Will consumers like that though?  It might be okay if you are a frequent shopper with a given merchant, for some people, but not all.  This can be seen as analogous to not everyone liking to wear clothes that function as advertisements. Wallets provided by banks will naturally be convenient for the debit and credit cards they support, but I would find it a little odd/uncomfortable if my bank tried to steer me to particular stores through loyalty offerings for those stores.

I can envisage different ways to monetise wallets, and we could brainstorm about that, if we think it would effect the standards that W3C needs to produce.


 From the users perspective, me (in this case), I very much like the idea of having those items (vouchers, coupons and loyalty) easily available for immediate in my digital wallet (just as I would in leather one) to pick and implement in the process of a purchase, without having to exit - additionally – I also want to easily be able to add them to my wallet via a web ad that I might see here or there.

Excuse me if a missed a discussion about reducing the amount of features that we do not want to include as in-scope for any W3C standards related to web payments……..if I did I apologize.

It seems like an attractive, shiny, and very useful type of feature set that will draw the attention of vendors, financers and users……….I also think including it as one possible feature set does not in the least inhibit the myriad of other options you proposed. Having an interoperable way to include this in a W3C digital wallet architecture seems to be a win-win for all. What self-respecting advertiser would want to exclude any way to improve driving sales?

The idea of having vouchers, coupons and loyalty cards as part of the user experience for wallets seems clear enough, however, the way this is reflected in the standards is another matter.  From a merchant’s perspective, when only some of your customers have digital wallets, it might be preferable to use a technical approach that works for all of your customers.

 Does the wallet-included approach not allow support for cloud based digital wallets as well?

Assuming the “wallet included model”, when purchasing from an online store, the store’s web page would be able to use a standard API to access vouchers, coupons and loyalty cards without needing to know where and how the wallet is implemented. To preserve the user’s privacy, this API would not allow web pages to iterate through the contents of your wallet. Instead, the API would only provide access to vouchers, coupons and loyalty cards owned by that merchant. This could be based upon the Web’s single origin security model, which in turn relies on the Internet’s Domain Name System (DNS).

An exception is where the merchant supports a loyalty card that covers a group of merchants, such as in the UK’s Nectar card.  We could perhaps borrow the CORS model for that.  In other words, the loyalty card could specify which origins it can be used with.  In a brick and mortar store, we then need a secure way to provide the origin for the store to the wallet. I think this could be based upon DNSSEC which supports digitally signed DNS lookup using public key cryptography. In essence, this would involve the wallet storing the public key for the owners of vouchers, coupons and loyalty cards and using this key to verify the legitimacy of the payment terminal's claims about origins.

If on the other hand, you look at the model where the wallet does not store vouchers, coupons and loyalty cards, the payment terminal needs to be able to link the user’s device (a smart phone or card) to an account with this merchant. This raises the question of the level of fraud around loyalty cards? I found the following links:

   http://www.paymentsleader.com/how-real-is-loyalty-and-rewards-fraud/

   http://www.mnn.com/family/protection-safety/stories/why-identity-thieves-love-loyalty-cards

   http://www.pcmsgroup.com/retail_systems/loyalty_giftcard_abuse.jsp


So it seems that fraudsters are aware of the potential!  Magnetic stripe loyalty cards offer little protection as they can be easily cloned. For online purchases, the user can be authenticated prior to the checkout phase.  We need something similar for brick & mortar stores that enables the payment terminal/cash register to authenticate users before retrieving and applying their vouchers, coupons and loyalty cards.  If the payment terminal uses HTML5, this is analogous to using your smart phone or smart card to log you into the website.  I am expecting a new W3C Working Group on stronger use authentication, and we would need to ensure that this use case is brought to their attention.  Note that authenticating the user in this way isn’t needed if the user isn’t participating in loyalty schemes for that store.

I can imagine people wanting to use vouchers and coupons without having registered with a merchant or cross merchant loyalty card operator. My previous email explained how that can be achieved for online purchases, where the vouchers/coupons are held by the merchant or advertising network, e.g. based upon using persistent cookies or local web storage. This could be emulated for brick & mortar stores as explained in my email.

You may be thinking that storing vouchers and coupons as part of the wallet would be simpler.  If the wallet is on the user’s smart phone, then the wallet’s user interface would appear on that phone. If the wallet is cloud based, and the user is making a purchase at a brick & mortar store, we then have a choice in where the wallet user interface appears. It could be on the payment terminal, or it could be on the user’s phone. This latter possibility isn’t applicable of the user is paying with a card.   If the user interface is on the phone, then we need to ask how that is possible.  One idea is for the phone to have Internet access, e.g. via WiFi or a cellular connection. Another idea would be to tunnel Internet access through NFC or Bluetooth, which may not be that practical.

Note that this raises the issue of how the user selects the means of payment at a brick & mortar store.  One idea is for each payment instrument to be associated with a physical plastic card that you select from your leather wallet. Another is for you to open your digital wallet on your phone before tapping it to the payment terminal. A further possibility is to use the payment terminal’s touch screen to make a choice. This is likely to require a second tap with your phone to the terminal’s contactless reader.  It also implies providing the payment terminal with an API that gives it access to the range of payment instruments you have that are accepted by the store.

In summary, we need to understand the technical ramifications for different approaches, and to check with merchants and banks to understand their perspectives on these.  There are consequences for the user experience and this should be reflected in our use case narratives.

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