Payment Links

Based on our talk on the call yesterday I wanted to add my thoughts about
Payment Links.

*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.

*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.


*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.

When you click one of these links the intention isn't that a payment is made
automatically, but that the payment system presents a repopulated payment
screen allowing the user to authorize the payment.


   1. Click link
   2. Payment Provider authenticates user
   3. Payment Provider presents user with a payment screen asking for
   authorization.


For smaller payments e.g. flattr like sites the payment provider might
already have you authenticated and might automatically approve small
payments.

*Reasons for standardizing payment links?*

There is no good reason that providers use different parameters since they
all require more or less the same parameters. Having a standard vocabulary
for amount, recipient, description etc just makes sense. It makes life
easier for tool developers, web site owners etc.

*
*
*Proposal for standard*

This proposal is based on what we've implemented for open transact. More
than anything it is just a simple vocabulary of http query parameters to be
added to the payment link.

In OpenTransact http://opentransact.org the payment link is what we call the
OpenTransact Asset URL.

If you link straight to that url without parameters you will be presented
with that payment applications standard payment page with no fields filled
in.

Add at will any of the following:

Core parameters we picked based on most common usages in current payment
apis. Preferred shorter names rather than longer. (e.g. to over recipient or
payee)

  amount - The amount requested
  to - The account identifier (often an email address) used by the Payment
provider.
  memo - description

OpenTransact prefers different urls for different currencies as they are
fundamentally different resources. eg:

  http://pay.me/usd
  http://pay.me/eur

That said I'd be happy to have a currency parameter for the link as well to
make it easy for existing providers to support this.

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.

I like the 'for' parameter personally but I'm thinking there may be better
names:

  "Pay $10 to Manu for PaySwarm eBook"

Which would translate to this:

  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

The exchange website could fill in the current market price when asking for
authorization.

*BitCoin*

The proposed bitcoin scheme fits well into this scheme.


bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50X8&label=Luke-Jr&message=Donation%20for%20project%20xyz

I would change it to use the above naming schemes. Obviously leaving out to
as that is replaced by the Address.

*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.

*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 said the problem could easily be handled by a 3rd party app or maybe
even an embedded javascript app.

*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.



-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking