RE: Observations on vouchers, coupons and loyalty cards

Not to continue to throw a spanner in the works but …

 

There seems to be two issues here:

 

The skinning / branding of the wallet itself.  That is a marketing issue and has little to do with the process flow or workings of the loyalty system.  Yes, the bank / loyalty / merchant / processor / etc – will want the loyalty system to bear it’s logo/name in order to get mindshare and the like.   I think this was where Katie was originally going.  And will the consumers like this?  We are all in a different realm of what consumers expect and tolerate.  I think the consumers will expect a brand of some kind related to the method of payment.  And I don’t see that ending anytime soon – but again seems to have less to do with the workings of the payment / loyalty systems

 

The second area is the workings of the loyalty system itself.  Without regard to the brand doing the demonstration – I can assure the entirety of the team that there are loyalty systems that work based on PAN, on token, on anything that can be used that is unique.  My local coffee shop can tell you exactly what I’ve purchased and when because I happen to use the same payment method and they allow the usage of loyalty based on that without regard to a loyalty system nor permission.  (yes different rules / regs in different areas).

 

However, I have seen several systems that can take a PAN and return to me what I purchased, when, from whom, and linked to my demographics including age, gender, residence and other.  And no – I do not mean Uber (albeit I’m a huge Uber user).  My point here is not that these schemes are (or are not) happening – it is that since they occur and since there are means by which this information can be collected and analyzed, it might be a moot point.  Loyalty opt-in or opt-out is a “feel good” to consumers.  De facto, a purchase is trackable.  So it might be that our role is to codify how that is done and then leave to others the rules by which this is officially, non-officially, regulated or not – but consumer.

 

PS – Most grocery loyalty systems in the US REQUIRE the loyalty card in order to do a self check!  And if you don’t use it but use a card – it is already tracked by PAN or other identifying information.  So just to buy groceries – even without a loyalty card – my purchase history is tracked and studied.  So this part of the conversation just might outside our purview…

 

Unless we are creating the technical means to identify a consumer who has done the opt-out and actually not collect the data points which are used for most loyalty systems in the first place.  But this smell like a legal matter that is regional …

 

-- 
HYPERLINK "http://www.oracle.com/"Oracle
David Jackson | Senior Director
Phone: HYPERLINK "tel:+16144656654"+16144656654 | Mobile: HYPERLINK "tel:+16145601237"+16145601237 
Oracle Financial Services Industry Solutions Group
New York City | Columbus, Ohio 

HYPERLINK "http://www.oracle.com/commitment"Green Oracle

Oracle is committed to developing practices and products that help protect the environment

 

From: Dave Raggett [mailto:dsr@w3.org] 
Sent: Tuesday, March 24, 2015 11:53 AM
To: Joerg.Heuer@telekom.de
Cc: public-webpayments-ig@w3.org; ryladog@gmail.com
Subject: Re: Observations on vouchers, coupons and loyalty cards

 

My local supermarket, Sainsburys, supports the Nectar card.  If you sign up for this, and pass it to the checkout staff, they will indeed track your visit and exchange information about you with other companies participating in Nectar. Note that this is clearly an example of opting into sharing personal data (I don’t have a Nectar card for that reason).  The same model can apply directly for online and brick & mortar purchases where you shouldn’t need to log in with the merchant if you haven’t signed up for their loyalty scheme.

 

Moreover, you the consumer should be in control when you want to use your loyalty card, etc.  I would imagine that for most people who have signed up for a loyalty card, they would want to present it each time they visit the store (online or brick & mortar) to maximise their points. However, this should be user preference that they can control.  The user experience is critical. I presume you agree that most people are likely to want to have a single tap with a contactless terminal to pay and update their loyalty points, right?

 

>From what you say, it sounds like loyalty schemes work differently in Germany.  Could you please give some more details about what kinds of loyalty schemes are popular and how they work?

 

Cheers,

   Dave

 

On 24 Mar 2015, at 15:06, <HYPERLINK "mailto:Joerg.Heuer@telekom.de"Joerg.Heuer@telekom.de> <HYPERLINK "mailto:Joerg.Heuer@telekom.de"Joerg.Heuer@telekom.de> wrote:

 

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 <HYPERLINK "mailto:ryladog@gmail.com"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 <HYPERLINK "mailto:dsr@w3.org"dsr@w3.org>

 

—

   Dave Raggett <HYPERLINK "mailto:dsr@w3.org"dsr@w3.org>