Re: Payment Links

Thanks for this, Pelle - I understand your proposal on last week's call 
a bit more clearly now. I can see some benefit for what you are 
proposing, so don't think I'm completely opposed to the idea when 
reading the rest of this e-mail. I do have a number of concerns that I 
hope can be addressed in time... more below.

On 10/01/2011 02:49 PM, Pelle Braendgaard wrote:
> *First why are Payment Links important*?
>
> They are not just tip jars but the first and simplest integration into a
> payment system by a blogger or small business. It is something they can
> generally speaking do without any outside technical help.

Merely adding a link to a web page is something that is "lowest common 
denominator", so I'm with you so far.

> *Not just for tips*
>
> A non technical person could quickly set up a little e-commerce site
> with Payment Links the way they do now using PayPal.
>
> As part of a users hCard they can have various payment links pre
> formatted with payment details.
>
> People can paste email links into invoices, emails, tweets, sms for
> requesting payments from clients.

Yes, but people can already do this with PayPal, Amazon Payments, 
Flattr, Google Checkout, etc.

PayPal:
https://www.paypal.com/cgi-bin/webscr?cmd=_pdn_xclick_techview_outside

Amazon:
https://payments.amazon.com/sdui/sdui/business/asp/standard

Flattr:
http://flattr.com/support/integrate/js

Google Checkout:
https://checkout.google.com/seller/checkout_buttons.html#generate_button_url

Granted, each approach is different, so what you are proposing is 
standardizing on one approach. However, by standardizing to one 
approach, what do we really accomplish?

To me it seems as if all we accomplish is making the URLs more 
standardized - but we don't really address any of the important 
problems. I agree that it's a nice-to-have, but it doesn't make the 
world a better place... it doesn't really move society in a positive 
direction, does it?

One of the goals of the Web Payments work is to make good progress on 
democratizing finance - to revolutionize the way we reward each other 
online - to create a system for open payments, transactions and digital 
contracts on the Web.

Payment Links, at best, are just a small part of the puzzle. Sure, we 
can start here - but I don't understand what you mean by "we need 
something that is going to catch on quickly". To put it another way, 
assume Payment Links take off and catch on - what has changed in a 
fundamental way? Why will PayPal, Amazon, etc. all of a sudden start 
implementing Payment Links when there really isn't a clear advantage for 
them doing so? I assert that with just the addition of Payment Links, 
nothing much has changed.

However, that does not mean I don't think there is value in Payment 
Links... but I think the value is in standardizing Payment Links so that 
open systems can use them, not because proprietary systems will want to 
standardize on them. If proprietary systems use them, then that's a nice 
side effect, but we should keep in mind that supporting pre-existing 
proprietary systems' lock on the market is a non-goal.

> *So what is a Payment Link?*
>
> A Payment link is essentially a request for payment in the form of a
>   IRI. Most cases that would be https links, but for non http cases such
> as BitCoin a new IRI scheme.

All of that makes some sense from a technical standpoint. My concern, 
however, has always been from the societal standpoint. IMHO, Payment 
Links are just part of a bigger solution and they are not, in and of 
themselves, a good solution for payment on the Web. As far as I 
understand, they require manual verification by the person receiving the 
payment... nothing gets automated. They also require that the person 
paying and the person receiving the payment, in general, reside on the 
same payment system (except in the Bitcoin case). There is no 
standardized receipt. There is no protection against spoofing/phishing. etc.

I do think that if we were to standardize Payment Links, that PaySwarm 
could use them... but you probably wouldn't want to because there is no 
notion of what is being transacted. They're useful when you don't have a 
plugin for your software and are not capable of writing software to 
process payments on your Website.

> Now the above is just the payment part. PaySwarm contracts are an
> exchange of a transfer for an asset. How would we allow this kind of
> thing in the most generic way?
>
> I suggest a simple field requiring a url. Maybe 'ref' or 'for'. For a
> PaySwarm enabled system that for would be the url of the asset listing.
> But it could be a url to anything, e.g. a product page.
>
> The payment prover might just display and record the link, but it could
> also check the url for semantic information about the item and present
> that to the user.

The URL is often insufficient when specifying what is being transacted 
because the contents of the URL can change from year to year. If I 
transact this one year:

http://example.com/articles/front-page

and I transact this the next:

http://example.com/articles/front-page

There is no guarantee that the thing being sold between 2010 and 2011 is 
the same thing. PaySwarm addresses this problem with the notion of a 
"Listing"- which is semantically published by the Vendor Website. The 
Listing contains an "Asset", a license description and the price for 
which the Asset is being sold. Having this information available, and 
verifiable, is vital in order to automate some of the manual processes 
that people have to use online today - such as the generation of a 
detail receipt of sale (or pre-purchase screen).

The other issue is being able to verify that the item being listed was 
actually listed by the vendor - that is, no spoofing, DNS hijacking, or 
other form of MITM attack happened. We can't just wave those problems 
away and say that "most people won't have that problem" when working on 
something that is intended to be a world standard.

All this to say that you can't just list a URL and be done with it - 
there are temporal implications and security issues for doing that.

> https://pay.me/usd?to=manu@…&amount=10&for=http://payswarm.org/ebook
>
> We might want a quantity parameter as well to indicate the amount of
> items I want to purchase. To avoid confusion maybe 'for_amount' makes
> more sense than 'quantity'. Adding the for and for_amount parameters
> opens it up for exchange applications.
>
> Lets say you used a currency trading site for bitcoin and/or national
> currencies. They could allow for market prices by creating the following
> link.
 >
> http://bitcointrader.null/trade/usd?for_amount=10&for=http://bitcointrader.null/trade/btc
> <http://bitcointrader.null/trade/usd?for_amount=10&for=http://bitcointrader.null/trade/btc>
>
> The exchange website could fill in the current market price when asking
> for authorization.

Sure, that seems useful.

> *BitCoin*

Yes, we would hope that one would use the parameters across all payment 
mechanisms.

> *Brower integration*
 >
> Obviously for non http systems like Bitcoin, the bit coin app needs to
> register a scheme on the browser. This is easily done in most OS now,
> including mobile phones.
>
> There is absolutely no need for anything new in the browser for straight
> http/s links. It is just regular http. The payment provider already
> knows who I am and what my accounts are.

Ah, but how does the website know who your payment provider is? That's 
the real problem here - not that your payment provider knows who you 
are... but that the browser can know what is being bought and sold on a 
page and that it has information available to it on your preferred 
payment provider.

This "Browser Integration" step requires absolutely no work on our part 
because what is proposed in Payment Links doesn't change how these 
payments work today. It doesn't address the real problems of payment in 
the browser, namely:

1) How does your browser know that there are items for sale on the page
    and the terms under which they can be transacted?
2) How does the page communicate with your browser to find out who your
    payment provider is? (OR)
3) How does your browser perform a financial transaction without
    directly involving the Vendor website and how does it report the
    result of that transaction to the Vendor website?

Being able to click a link is not "browser integration". There is power 
in being able to utilize browser technology today - we don't want to 
wait on the browsers to catch up in order for these specs to be 
successful. However, we can't ignore the fact that the best customer 
experience is probably going to be achieved with very tight browser 
integration.

> *The Nascar problem*
>
> If there are 100 different payment providers out there we could run into
> what is called the Nascar problem. (too many logos). I don't think in
> general use it would be much of a problem. Most users of these links are
> only going to support a small about of links.

That is not a solution. It just ensures that the only payment 
authorities that are going to be allowed on the Web are the biggest ones 
with the largest marketing budgets. It creates an uneven playing field. 
For example, local banks and credit unions would be excluded from the 
proposed solution because they're "too small to matter". This "solution" 
establishes and promotes monopolies and will ultimately harm the market.

If we are successful, I would hope that there are not hundreds, but 
thousands of payment providers out there. If that happens, we must 
strive to make sure that they can compete with one another on as even of 
a playing field as possible.

> That said the problem could easily be handled by a 3rd party app or
> maybe even an embedded javascript app.

X-Auth is the only deployable solution that I know of today that does a 
good job of handling the NASCAR problem... and it leaks financial 
information in the process. 3rd party apps are a non-solution when it 
comes to standardization. The reason we're attempting to standardize is 
to not need 3rd party apps - we want the technology to be ubiquitous.

What kind of embedded JavaScript app is capable of solving the NASCAR 
problem? Could you be more specific?

There are privacy implications as well - you don't want just anybody to 
be able to know who your payment provider is... just like you don't want 
just anybody to be able to find out who you bank with... it enables a 
certain class of phishing attacks against your financial data.

> *But what about receipts/contracts etc?*
> For a simple payment link that is out of scope of this section. But
> needless to say the payment systems can do this in many different ways.
> They might start with just sending an email receipt to the recipient.
> But this also easily extends into the PaySwarm model of a contract being
> created.

"Standard" and "payment systems can do this in many different ways" are 
two concepts that are fundamentally opposed to one another. :P

The goal is to not have "many different ways to do one thing" it is to 
have "one way to do one thing". You are correct in that PaySwarm 
provides this level of detail in the transaction, but we believe that 
this level of detail should be provided for /all/ transactions if 
possible. More transaction data is better than less transaction data.

There are certainly implementation concerns that must be addressed, and 
the point you make about PaySwarm being more complicated than Payment 
Links is a very fair point. We are very sensitive to the implementation 
burden of PaySwarm.

However, I think that Payment Links go too far in the other direction. 
Payment Links, in and of themselves, don't change the status-quo - they 
don't move us forward socially.

Now, all that said - I'm willing to hack together the Payment Links 
specification because I'm not entirely convinced that we definitely 
shouldn't create a spec for Payment Links. However, I still hold that 
we're not going to see a great uptake because we just put a Payment 
Links spec out there. I don't understand why a large company would 
choose to implement it unless they have some standards geek in some 
position of power at their company. That is, what competitive advantage 
does it give them? It also doesn't really change the competitive 
position of the little guy from where they are today.

"Build it and they will come" - so, let's build it and see what happens. 
The worst case is that nothing of importance changes.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
http://manu.sporny.org/2011/payment-links/

Received on Wednesday, 5 October 2011 16:28:12 UTC