Re: openpayee

Hi Anders,

Assuming this push-based model was adopted and the merchants payment
gateway advertised the fact that they are a registered MasterCard acquirer.
PayPal (the payer's payment provider) have the payer's MasterCard card
details on record and submit a MasterCard card payment to the gateway in
the same way as they would if the payer had submitted online via an
eCommerce website or similar.

I agree this is taking a scenario where usually the payment will be
card-present and we are using card-not-present which is not ideal but no
worse than any other "wallet" solution offered today.
This use case is intended to illustrate how the push payments model can
elegantly fall back to using traditional card based channels if no others
are supported by both the payer and payee.

And, I would contest, it is still better than the legacy card model
Bear in mind that the card details are provided by an entity that should be
trusted by the payee's payment gateway more than a random user on an
eCommerce website.
PayPal will not use fraudulent details to make payments on behalf of its
users and has usually verified any cards that it stores.

Adrian


On 23 June 2014 22:11, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> Hi Adrian,
>
> http://openpayee.org/use-cases/use-case-2-nfc-wallet/
>
> I must confess I don't understand how a PayPal account holding a MasterCard
> can be used for emulating MasterCard payments in a real-time process.
>
> Anders
>
>
> On 2014-06-23 21:20, Adrian Hope-Bailie wrote:
>
>> /"Can you show us what an example of this would look like? Just a simple/
>> /blog post or outline of the data going back and forth would be helpful."/
>>
>> This is/was my intention with openpayee.org <http://openpayee.org>
>> Unfortunately this has been a lone effort and I do have a day-job :)
>>
>> I was hoping to combine my work on OpenPayee with what you are all doing
>> in the CG and add it to the efforts you have already made.
>> Having developed my ideas independently I have the benefit of an entirely
>> fresh perspective on your work so far so excuse me if it seems like I am
>> attacking everything you say :)
>> It's obviously not the case, I simply have a lot of content and ideas to
>> share and debate.
>>
>> I arrived at the idea for OpenPayee from my analysis of the current state
>> of payments networks and my conclusion that the idea of handing any form of
>> credential to a payee that allows them to debit money from your account is
>> just wrong and outdated. i.e. Card payments are bad in principal. The
>> system is expensive, loaded with risk and only really serves to protect the
>> oligopoly of the existing big networks.
>> As such, OpenPayee started as an intention to simply promote the idea of
>> "push payments".
>> I.e. payments should be controlled by the payer and pushed (in the form
>> of a credit) from the payer's account to the payee.
>>
>> Obviously the world is not ready to up and abandon card payments entirely
>> however it's worth noting that in many countries real-time ACH payments or
>> EFTs (the terminology differs in different territories) is already a
>> reality.
>> (The UK, Singapore and one or more of the Scandanavian countries that I
>> am aware of, the elephant in the room is the US where inter-bank payments
>> that don't run on the card networks are still done with paper checks!)
>>
>> For this reason, the process needs to fall back elegantly to support card
>> payments and I believe this is easy to do without entirely compromising the
>> integrity of the push payments architecture.
>> The approach would be for the payment to still be initiated by the payer
>> through their agent/bank/wallet provider but that provider would simply
>> pass the payer's card details onto the payee's agent/payment
>> gateway/acquirer.
>>
>> It is that the payer chooses who to trust with their payment details.
>> They select a provider that they believe is secure but also has existing
>> trust relationships with other key stakeholders in the payments ecosystem.
>> i.e. If I live in South Africa I probabaly want a provider that can, at a
>> minimum, make direct payments into any South African bank account.
>>
>> The choice will be a balance between convenience (many supported payments
>> channels) and security but what is key is that the choice is with the payer.
>>
>> OpenPayee is based on two fundamental goals:
>> 1. Use push payments and put the payer in control.
>> 2. Standardise the way the payee's details are shared with the payer so
>> that the payer can make a payment through a channel supported by both the
>> payer and payee.
>>
>> I would suggest you look at what I have put up on OpenPayee.org thus far
>> (it's rough and could use some critique) and give me your feedback.
>> Particularly, the use cases may be illustrative of the idea.
>>
>> /"The identity problem is separate from payments for the most part."/
>>
>> This is fundamental to my approach.
>>
>> I realise you want to come up with a solution that supports the large
>> group of use cases on the wiki.
>> This is the ideal but likely to be very difficult to achieve without
>> defining the whole stack from end-to-end as I think you have already
>> discovered.
>> Unless... you break the problem into smaller pieces and solve these
>> one-by-one.
>>
>> Lets break the end-to-end payments process into stages and try to
>> standardize these individually?
>> That way we can avoid needing to standardise for edge case scenarios with
>> a large and complex standard.
>>
>> Off the top of my head we should start by defining a standard way for the
>> payee to advertise the channels that they will accept payments on (either
>> with a specific transaction context or in a general context).
>> That's the purpose of OpenPayee.
>>
>> The next piece that needs to be standardised is the negotiation of terms.
>> i.e. Now that I know you accept payments via a card gateway that can
>> process VISA cards, via bitcoin, via UK bank transfers and via SWIFT what
>> are the terms of using each channel.
>> If I want to pay by card via your card gateway what currencies do you
>> support and what is the conversion rate from the base currency you quoted
>> my original transaction in?
>> If I pay via UK bank transfer what is the maximum and minimum amount
>> you'll accept on that channel and how long will it take for the payment to
>> clear so I can can get a digitally signed receipt?
>> I think you get the gist?
>>
>> One could then standardise an additional information exchange process
>> whereby the payer must supply the payee with information (perhaps depending
>> on the channel used?):
>> i.e. Now I know that you accept payments via X channels what additional
>> information do you need from me to complete the payment (age, delivery
>> address etc)
>>
>> The advantage of this is that each channel is then free to define how the
>> payment is actually processed.
>> This may not even happen over the public Internet if the two agents have
>> an existing relationship on a proprietary network such as two banks that
>> are members of SWIFT.
>>
>> To me, that is sufficient to handle almost all payment scenarios and is
>> loosely coupled enough so that it can be overlaid on existing channels and
>> leverage existing standards that provide the other services required, such
>> as identity exchange. By the way, the standard for exchanging payee info
>> should define how this can be done on top of as many existing identity
>> exchange protocols as possible to ensure it's easy to adopt. Right now I am
>> using Open ID Connect as a starting point.
>>
>> I am focusing, initially, on the payee info exchange with OpenPayee but
>> that would need to be followed quickly with the terms negotiation piece.
>> I haven't dug into it in detail but I think there is a great deal of
>> stuff in the webpayments.org <http://webpayments.org> specs that could
>> help here.
>>
>>
>> On 23 June 2014 17:52, Manu Sporny <msporny@digitalbazaar.com <mailto:
>> msporny@digitalbazaar.com>> wrote:
>>
>>     On 06/17/2014 09:24 AM, Adrian Hope-Bailie wrote:
>>      > Why not simply provide a specification for a PaymentInfo endpoint
>>      > and dictate that this endpoint returns JSON-RD? i.e. Once I have
>> your
>>      >  Open ID Connect identifer I can discover the various channels you
>>      > support to accept payment, pick the one I want to use and process
>> the
>>      > payment.
>>
>>     Can you show us what an example of this would look like? Just a simple
>>     blog post or outline of the data going back and forth would be
>> helpful.
>>
>>      > I'm afraid I still see no value in inventing another new federated
>>      > identity protocol if you are doing it simply to facilitate
>> payments.
>>      >  The ones we have offer enough to solve the payments initiation
>>      > problem.
>>
>>     Just to be clear, we're not doing it "simply to facilitate payments".
>>
>>     The identity problem is separate from payments for the most part.
>> There
>>     is an area of overlap, and that's when additional details are required
>>     to do a payment, most notably when a customer needs to:
>>
>>     1. Transmit which payment processor should be used for a payment.
>>     2. Transmit any high-stakes credential information (such as the
>>         transmission of proof of age, or license to purchase a controlled
>>         substance (chemicals, fertilizer, alcohol, etc.), KYC information,
>>         etc.)
>>     3. Transmit any low-stakes information (such as shipping address).
>>     4. Do all 3 above in a loosely coupled way that allows market
>>         verticals to extend the information exchanged w/o having to
>>         go through the W3C/IETF standardization process.
>>
>>     Basically, when the customer needs to provide any information in an
>> easy
>>     to use way to the merchant. In many cases, the customer should only
>> have
>>     to transmit the payment processor to use for most digital goods.
>>     However, there are many cases where extra information is required to
>> be
>>     transmitted as a part of the transaction. A set of technologies that
>>     intend to be a world standard can't ignore those set of use cases.
>>
>>     Ideally, we'd be able to extend OpenID Connect to address the use
>> cases
>>     above, but our initial attempt at doing so led to a technology stack
>>     that was far too complicated while still not addressing many of the
>> use
>>     cases that we need to address. Again, we'd love to see an example of
>>     OpenID Connect meeting all of the use cases we need to address:
>>
>>     https://www.w3.org/community/webpayments/wiki/
>> CategorizedWebPaymentsUseCases#Identity
>>
>>     -- manu
>>
>>     --
>>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>     Founder/CEO - Digital Bazaar, Inc.
>>     blog: The Marathonic Dawn of Web Payments
>>     http://manu.sporny.org/2014/dawn-of-web-payments/
>>
>>
>>
>