openpayee

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/
>
>

Received on Monday, 23 June 2014 20:12:00 UTC