Re: payment "diagrams"

Hi Daniel,

I agree that having standardized, web-based payment rails that support all
of the use cases you mentioned would be a big win.

At the last face to face meeting I proposed creating a Value Web / Web
Settlement task force
<https://www.w3.org/Payments/IG/wiki/Value_Web_/_Web_Settlement_Task_Force>
focused on exactly that idea. The proposal hasn't generated enough interest
yet for it to be worth really starting the task force but we're recruiting!
We're actively working on this idea within Ripple Labs and we would love to
join forces with others thinking about web payment rails.

Daniel (or anyone else) let me know if you'd be interested in talking more
about this,
Evan

On Sun, Mar 8, 2015 at 5:46 PM, Daniel.Buchner <Daniel.Buchner@target.com>
wrote:

>
> Bits for thought, and my 2 fiat cents:
>
> I keep hoping the group will transition to pursuit of one underlying
> protocol/system/rail that is capable of supporting all the use-cases I read
> about in these exchanges (payments, person-to-person unique asset transfer,
> non-monetary asset verifications, etc.). Even if the "last mile" surfaces
> as a myriad of diverse, consumer-facing tools, products, and services (be
> they open source, publicly owned, or proprietary), I find this to be a far
> better long-term solution.
>
> Agreeing on a keystone protocol/system/rail would, in my opinion, simplify
> implementation, provide for greater generativity, and create a solid
> foundation on which we can build solutions for almost any use-case.
>
> Consider the following: coming to agreement on HTTP as a primary, standard
> protocol was a very important step for the Web - it worked out well and has
> flexed with our needs (HTTP/2 here we come!). Why not pursue
> standardization at an equivalent level in this sphere of technology?
>
> I know this stance may be controversial or vexing for some, but it seems
> important to surface diverse opinions from time to time in order to test
> our assumptions against all possible options.
>
> - Daniel
>
> ________________________________________
> From: Dave Raggett [dsr@w3.org]
> Sent: Sunday, March 08, 2015 4: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>>
>
>
>
>
>


-- 
Evan Schwartz | Software Engineer | Ripple Labs
[image: ripple.com] <http://ripple.com>