Re: payment "diagrams"

I think an aim is to make payments from your smart phone, or tablet, etc. at least as secure as with a physical card.  In other words, to prove the presence of a “virtual card” and of its owner as appropriate to the value of the transaction.  This may require the use of tamper proof hardware, which could be integrated as part of a system on a chip, or in a SIM card or even using NFC and a contactless credit card held next to your phone.

Is it necessary for W3C to standardise a lot of this?  I don’t think so, as the associated means for  authenticating the device and proving the user’s presence is the responsibility of individual payment instruments, and could rely on the OS level APIs available to native implementations.  However, it remains interesting to look at the role of JavaScript executing on a trusted platform separate from the browser. This would motivate work on the corresponding APIs, e.g. for access to secure storage, for secure user interfaces, for access to contactless devices via NFC and BLE, etc.

— Dave


> On 9 Mar 2015, at 17:12, VIGNET cyril <Cyril.VIGNET@bpce.fr> wrote:
> 
> Sorry, I was unclear. Far from me to push a hardware solution (years ago, I join a project that counted on the availability of card reader for PC and it never happened).
>  
> My point was only that the security would be more difficult to achieve.
>  
> regards
>  
>  
> Cyril VIGNET
> +33622040856
> +33158400234
> Cyril.vignet@bpce.fr <mailto:Cyril.vignet@bpce.fr>
>  
> De : Mario de Armas [mailto:Mario.Dearmas@walmart.com] 
> Envoyé : lundi 9 mars 2015 16:09
> À : VIGNET cyril; Dave Raggett
> Cc : Adler, Patrick; Web Payments IG
> Objet : RE: payment "diagrams"
>  
> While it may be easier to have unique hardware, it is a friction point that slows adoption and is ultimately rejected by stakeholders.  Back when the internet was just starting, there was a push by some to install card readers onto every laptop to securely enable ecommerce.  This proved to be too expensive, incompatible and that effort failed.  Also, in some markets around the world in order to enable ecommerce, banks issue their credit cardholders dynamic tags that change passwords every 60 seconds.  Consumers must enter the dynamic password in order to complete an ecommerce transaction.  These transactions are certainly more secure, but they have been identified as a friction point that is slowing down ecommerce growth and completely excludes non-credit card holders from ecommerce. Since W3C is about creating the next generation of internet browsers, I think we should focus on securing payments traditionally seen as CNP (Card Not Present).  A next-generation solution already exists for card present transactions inside a merchants’ place of business called EMV.
>  
> From: VIGNET cyril [mailto:Cyril.VIGNET@bpce.fr <mailto:Cyril.VIGNET@bpce.fr>] 
> Sent: Monday, March 09, 2015 9:24 AM
> To: Dave Raggett; Mario de Armas
> Cc: Adler, Patrick; Web Payments IG
> Subject: RE: payment "diagrams"
>  
> The analogy with a payment terminal seems to me very interesting. If we look at all the functions performed by a POS terminal we have both “merchant functions” and “cardholder functions” that are entangled. As mentioned Dave, the “user agent” should provide “cardholder functions” and the “server agent” should provide the “merchant functions” in a secure way (security easier to implement when having a unique hardware that a distributed system, I believe). Thanks Dave.
>  
> regards
>  
>  
> Cyril VIGNET
> +33622040856
> +33158400234
> Cyril.vignet@bpce.fr <mailto:Cyril.vignet@bpce.fr>
>  
> De : Dave Raggett [mailto:dsr@w3.org <mailto:dsr@w3.org>] 
> Envoyé : lundi 9 mars 2015 10:33
> À : Mario de Armas
> Cc : Adler, Patrick; Web Payments IG
> Objet : Re: payment "diagrams"
>  
> With Square, the tablet/phone + fob becomes a payment terminal.
>  
> On 8 Mar 2015, at 19:22, Mario de Armas <Mario.Dearmas@walmart.com <mailto:Mario.Dearmas@walmart.com>> wrote:
>  
> What does one need a payments terminal for?
>  
> If the register (or the browser on the register) can authenticate the merchant, and a mobile device (or the browser on the mobile device) can authenticate the purchaser, what is the purpose of an additional piece of hardware?  Merchants need register functions and software to track sales, but not necessarily a separate payments terminal.
>  
> Consider Square which is both the register and payments terminal all in one.  The only reason one needs the fob for Square is to accept card payments.  If one registers with Pay with Square, no additional payment terminal is required, everything can be processed with a tablet or phone.  Quickbooks today doesn’t even have a fob to process card transactions, it allows merchants to take a picture of the front of the card and it processes with no additional hardware at all.
>  
> From: Dave Raggett [mailto:dsr@w3.org <mailto:dsr@w3.org>] 
> Sent: Sunday, March 08, 2015 6:45 AM
> To: Adler, Patrick
> Cc: Web Payments IG
> Subject: 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 <mailto: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>>
>  
>  
>  
> This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. *** Walmart Confidential ***
>  
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
>  
>  
>  
>  
> Ce message et toutes les pièces jointes (ci-après le 'message') sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'en avertir immédiatement l'expéditeur.
> Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération.
> BPCE décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.
> 
> This message and any attachments (the 'message') are confidential and intended solely for the addressee(s). If you receive this message in error, please delete it and immediately notify the sender. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. « BPCE » will not be liable for the message if altered, changed or falsified.
> This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. *** Walmart Confidential ***
> 
> Ce message et toutes les pièces jointes (ci-après le 'message') sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'en avertir immédiatement l'expéditeur.
> Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération.
> BPCE décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.
> 
> This message and any attachments (the 'message') are confidential and intended solely for the addressee(s). If you receive this message in error, please delete it and immediately notify the sender. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. « BPCE » will not be liable for the message if altered, changed or falsified.

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