Re: payment "diagrams"

Further comments about the role of payment terminals.

Today’s payment terminals are designed for use with debit and credit cards. However, we would like to enable a level playing field for a broad range of payment instruments, so my question is what does that imply for payment terminals?

When paying at a restaurant or brick & mortar store etc. with your smart phone, the payment instrument you have selected may require direct access to the Internet. This would enable simple generic payment terminals that, from an abstract point of view, interface to payment instruments in the same way as an online store's web page does. This new generation of payment terminals would give businesses the opportunity to support a broader range of payment instruments than is possible today.

I can also imagine that payment terminals may support certain kinds of payment instrument  directly through the communication channels they open with the payment instrument. This would be case if you want to use your virtual debit or credit card with one of today’s contactless payment terminals.  Your wallet would need to implement  the protocol used by the payment terminal, and give you an opportunity to chose which card to pay with for a given transaction.

In principle, there could be devices that look like a conventional contact-based card to the payment terminal, but which actually serve as a communication link to the wallet in your smart phone. This would allow you to use the virtual debit/credit cards in you phone to pay when the store’s payment terminal doesn’t accept contact less cards!


> On 6 Mar 2015, at 18:27, Dave Raggett <dsr@w3.org> wrote:
> 
> Hi Patrick,
> 
> Following our call today, in which I promised to provide you with some sketches.  I have  brainstormed some notes, but haven’t got as far as new diagrams.  What follows covers three scenarios: paying an online store, paying at a restaurant, and paying another person. The first example has a web page making a payment request that is routed to a payment instrument via a browser and a digital wallet. In the second example the payment request is initiated by a payment terminal and routed via NFC and a wallet to the payment instrument.  In the third example, a digital wallet emulates a payment terminal to pass a payment request to the wallet in another phone.
> 
> The corresponding interfaces we would need to standardise at W3C include:
> payment request and response,
> passing digital receipts to a wallet
> presenting and updating loyalty cards
> If a payment transaction fails, the response indicates the nature of the problem, e.g. the payment instrument isn’t accepted, the back-end network failed, the payer has insufficient funds to cover the transaction, the payee is blacklisted, the payer was unable to authenticate himself, and so forth.
> 
> Further use cases would cover payer initiated payments, refund payments, and the handling of vouchers and discount coupons. These could be handled via additional interfaces.
> presenting a voucher and response
> presenting a discount coupon and response
> receiving a voucher
> receiving a discount coupon
> I haven’t thought much about how loyalty cards are issued and installed into the user’s wallet, but reckon that it would be similar to installing payment instruments. Note that the mechanisms for this are likely to be dependent upon the wallet. As such we don’t need to worry about standardising them, at least for now.
> 
> Beyond that I can envisage use cases for digital tickets and the use of identity cards. However, I don’t think these last two are in scope for the Interest Group and should be handled at a later stage in another W3C group.
> 
> Anyway here are my three use cases.  The bullet points could be made into diagrams.
>  Web page + browser + wallet + payment instrument
> Sue has selected some clothes at an online store and now wants to checkout and pay. The store’s website checkout page has a “pay now” button that invokes a web page script that in turn invokes the W3C payment API. This is routed via the browser to Sue’s digital wallet, enabling her to choose which means of payment she will use for this transaction. The payment request from the web page is then passed through to the payment instrument. This provides a proof of payment to the merchant via a back end communication channel appropriate to that payment instrument. When the transaction completes, a response is passed back through the wallet to the originating web page script. The W3C payment API returns a Promise, and the web page sets the “then” handler to update the web page accordingly when the transaction completes.
> 
> The payment API passes through sufficient details for the payment instrument to initiate the transaction. The API also passes a digital receipt for the purchase for storage in Sue’s wallet. In principle this could be passed at the same time as the payment request, or as a separate step following the completion of the payment transaction.
>  Payment terminal + wallet + payment instrument
> Roger has taken his wife Sue out to dinner at a local restaurant. After the meal has been cleared away, the waiter brings a hand held payment terminal. Roger looks at the amount and touches his phone to the terminal to make the payment. As the amount is over $20 he is prompted to swipe his finger across the scanner on his phone and then to tap his phone to the terminal a second time to complete the transaction.  A digital receipt is passed from the terminal to his phone for storage in his wallet.  In addition, the loyalty card in his wallet is updated to credit him for his custom.
> 
> This example works in just the same way as for the earlier online store example, with the payment terminal replacing the web page and browser. In this example, Roger isn’t asked which “card” he wants to use for the payment, perhaps because only one of his cards is accepted by the restaurant, or perhaps because of a previous preference setting he has made. The payment request is passed from the payment terminal to Roger’s wallet via a contactless interface such as NFC. The proof of payment is passed through the back end. The payment terminal signals when the transaction is complete.
> Wallet acting as payment terminal + wallet + payment instrument
> Roger’s friend John has a spare ticket to this evening’s concert. He asks in Roger wants to come. Roger says yes. John takes out his phone and opens the wallet application and types in the amount he wants Roger to pay him. Roger gets out his phone and touches it to John’s to make the payment. In this process, John’s phone emulates a payment terminal. Roger’s wallet asks him whether he wants to do a direct transfer from his bank account, or if he instead wants to pay John with bitcoins.
> 
> In principle, this example could be extended to include digital tickets, e.g. when John purchased the tickets these were stored in his wallet. He is able to transfer one to Roger’s wallet via a touch gesture. The concert hall turnstile checks each ticket as people pass through (you have to tap your phone to the turnstile reader), ensuring that each ticket can only be used once. However, I think we agreed to postpone work on tickets, is that right?
> 
> Hoping this helps.
> 
> Best regards,
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
> 
> 
> 

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