[use cases] some narratives from a user perspective

Here is my take on interesting use cases as a basis for testing my understanding and looking for gaps in the official set being prepared by the interest group, and if I am on track, for use in the IG’s reports. 

The idea is to start with a set of end user narratives that covers the scope that the Interest Group wants to address.  The next step is to analyse each use case, perhaps in a separate document, breaking the narratives down and relating the components to the payment flow and the terminology used for payment solutions, something that Ian has started to do.  This in turn suggests requirements for the web technology standards that will be needed to realise the use cases.

The use cases cover person to business, business to person and person to person payments. In addition, I cover refunds, discount coupons and loyalty cards, adding payment instruments, and identity verification.  I think further narratives are needed to further explore what kinds of user experience we want to realise with vouchers, discount coupons and loyalty cards. In addition, we need narratives that explore what the user experience is when things don’t go as planned, e.g. when there aren’t sufficient funds for the transaction to proceed, or the network fails or doesn’t support a particular payment instrument. I will try to work on some narratives for this over the next couple of weeks.

On a website, a common case is to check out and pay for the contents of your shopping basket. This involves the application of any discounts applicable, the choice of shipping method, and the means of payment you will use.

Jill wants a new outfit for a party and has added her choices to the website’s shopping basket. She reviews the items in the basket and after selecting next day delivery, taps on the pay now button.  Her wallet opens and she decides to pay with her regular debit card. She taps on the picture of the card. As the amount is over £20, she is asked to swipe her finger on the scanner on her smart phone. The transaction completes and the receipt is added to her wallet. She puts her phone back in bag and goes to make a cup of coffee.

The web page includes a script that handles the pay now button. This invokes the W3C payment request API, passing details on the amount and currency, the means of payment accepted by the website as well as the associated information for the merchant, and a description of what is being purchased. The browser passes the request on to the digital wallet registered with the browser. This could be a native application on the phone, a locally installed web application or a remotely hosted web application. The wallet shows the amount and the payment instruments in the wallet that matches the request.  The user selects which payment instrument to use. The payment instrument verifies that the user has sufficient funds, and uses an appropriate means to authenticate the user depending upon the amount to be paid. A proof of payment is passed to the merchant, and digital receipt is passed back to the wallet.

Joan is in the high street looking for some new shoes. She likes the look of the shoes in the window and enters the store.  A short while later, she has found the style she likes in her size and is ready to pay. The sales assistant holds out the portable payment terminal to show Joan the price. Joan pulls out her phone and touches it to the payment terminal. There is a “ka-ching” sound that signals a successful transaction. Joan’s phone shows the receipt for the purchase. Joan smiles, thanks the sales assistant and walks out of the store.

This use case could make use of NFC as a basis for the message exchange between the phone and payment terminal. It assumes that Joan has set preferences for how she wants to pay in various circumstances, so that she isn’t asked to choose between alternative payment instruments at the time of payment. The wallet listens for payment requests which may come from a web browser, from an external payment terminal, or even another phone.  If the payment instrument is a debit or credit card, a token is generated as a one time authorization on behalf of the user to pay the designated recipient. The payment terminal passes this to the card issuer, which verifies the token and checks if the user’s account holds sufficient funds and passes back a message for proof of payment or declined payment. If successful, the payment terminal passes a digital receipt to the phone for storage in the wallet.

A refinement is to handle the case where Joan posses a loyalty card for the store, where this card is held in her digital wallet. Each times she purchases something from the store (either online on in the brick & mortar store) her loyalty card is updated with the points that accrue from the transaction.

John tells Jim that he has a spare ticket for this Saturday's concert by the Kooks (a British rock band) and asks if Jim would like to come with him.  Jim says yes that would be great!.  John pulls out his phone and opens his wallet and taps in the amount that Jim now owes him for the ticket. Jim gets out his phone and taps it against John’s to make the payment. They chat about the latest tracks by the Kooks.

This requires the wallet to be able to function as a payment terminal and works the same way as the previous use case. 

Roger hears a ping on his phone. It is his wife Sue — she has sent him a shopping list for the items she wants him to buy at the supermarket on his way home from work. When he enters the store, his phone ask if he wanted to share the shopping list with the store, he agrees. He walks around the store ticking off the items on his phone as he adds them into the kart.  His phone draws his attention to special offers relating to the things Sue has asked for.  It also suggests a bottle of Italian Pinot Grigio that would complement the meal Sue plans to make. At the checkout Roger is pleased to see that he has got a reduction based upon his previous trip to the store. He taps his phone to the payment terminal and walks out.

This use case could be implemented using Bluetooth Low Energy, and illustrates opportunities for value added services around payments.

Mary has been given a dress by her mother. Mary doesn’t like the style and anyway it is too small! She asks her mother for the receipt. Her mother finds the receipt in her digital wallet and taps her phone to Mary’s to copy it to Mary’s wallet. Later, Mary visits the store and goes to the returns desk with the dress. The store offers to refund her, but will give her a $10 discount if she instead purchases another item from the store in place of the dress she is returning. Mary likes the sound of that, and soon finds a fashionable skirt she loves.  She checks out and leaves the store.

This use case covers business to person payments as well as discount coupons. Refunds are essentially similar to payments. The payment terminal makes a refund request. The user can select which matching payment instrument is to be credited. The payment instrument then passes sufficient information to the payment terminal to process the transaction. Upon completion, the payment terminal passes back a receipt for storage in the user’s wallet.

Mary chose to accept a discount coupon in place of a cash refund. This is for the price of the returned item plus $10 as an incentive for her to purchase another item from the store. When she comes back to the sales desk with the new item, her wallet matches the payment request from the payment terminal with the vouchers and coupons held by the wallet.  At this point she could be prompted to ask if she wants to redeem the coupon, along with an accompanying sound that informs Mary that the phone wants her input. Alternatively, the coupon could be applied automatically, and the sales assistant can then let Mary know as a human touch to the transaction.

Julian applies for a new payment card that gives him special discounts in many stores.  He applies online and after a credit check by the issuer, the new payment card is installed in his digital wallet.

The issue needs to verify Julian’s real world identity. It does so via a W3C web page API that passes the request to a matching identity agent registered with the browser. Julian is asked if he is willing to provide his full name, date of birth and address to the website. He agrees, and the card issuer uses this information to run a credit check and then to set out a new account.  The identity agent could be the mobile network operator, or a trusted third party on behalf of a government issued credential such as a national identity card, passport or driving license. There is a W3C API for adding or removing payment instruments from the digital wallet registered with a web browser.

Simon opens his digital wallet to review his recent expenditure. He scans the recent transactions, and chooses to open his bank account to pay off his credit card.

The wallet could provide its own user interface for reviewing transactions, vouchers and discount coupons. Better yet, would be a means for users to install third party valued added applications that integrate with the wallet. Payment instruments could provide a means for opening the website or application associated with that instrument.

Kevin is buying some beer for a party with his friends. He is very young looking for his age, and is asked to prove he is old enough to legally purchase alcohol. He brings out his phone, opens his wallet and selects his identity card. He touches it to the sales terminal to allow it to verify his age.

This is an example of identity verification. The requestor could pass the request as a expression over identity attributes, e.g. at least 18 years old, along with which kinds of identity agent are accepted. The digital identity card generates a zero knowledge proof for the requested expression. This is then checked by the requestor, which also verifies that is originates from an identity agent that the requestor supports. Some payment instruments may also function as identity agents.

The information that can be passed with a payment or refund request needs to be adequate to fulfil the needs of a broad range of payment instruments, although in any particular request, it only needs to cover the range of payment instruments that the requestor supports. This suggests an extensible API, perhaps with the data expressed in JSON.

Proof of payment may well depend on the solution chosen for that payment. It could be passed back to the requesting web page, or sent directly to the merchant. A standard for digital receipts would enable 3rd parties to interpret such receipts, and make it easer to present them in a variety of ways as compared with a representation tied to a particular presentation. On the other hand merchants are used to controlling the appearance of sales receipts. One solution would be to use HTML together with annotations for machine interpretability.

Given that things can go wrong at any stage, it is important to describe what happens in any case, for instance, if the communication channels fail during a transaction. Relying on a personal device like a phone for storing receipts could present problems when that device is lost or broken.  This suggests value in synchronising the wallet with the cloud, so that the user isn’t reliant on the device.  This would also help when you need to revoke a device so that it can no longer be used to make payments. Many users will value having the same wallet on all of their devices, rather than having to manage several different wallets.

How does the wallet determine which payment instruments match a given request? One approach would be to ask each payment instrument in turn. This has potential privacy issues. These could be mitigated by minimising the information passed to the payment instrument, e.g. omitting information that could identify the merchant and/or store.

More later.  Your comments are welcomed.

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