rel="payment" + PayPal MassPayRequest API = Automated Payment Mechanism?

Last year, Jay Deadman had a good idea about creating a rel="payment" microformat. This was written up and submitted as a new microformat.

I haven't heard much about this microformat since I posted about it last year, and couldn't find it being used in the wild. I recently went looking for an update and found something in the spec I hadn't noticed before - specifically, the spec states

One of the goals with this microformat is to give content aggregators such as RSS readers a way to extract these support links and give them special attention (such as displaying a standard button along with the content).

A bit further in the spec:

rel="payment" is not intended to initiate an automated transaction.

In other words, rel=payment only provides for a manual mechanism for payment (i.e. a tip jar, etc).

This is still a good idea, but it would be even stronger with support for automated payment (even micropayments). Just imagine if the video in my RSS feed was picked up by Google Video and I was paid on the number of times it was viewed, etc. As the content creator, I wouldn't have to work out a payment mechanism with the various video sites (YouTube, etc).

As currently spec'd the rel="payment" tag needs two additional parameters:

  1. Payment Provider - PayPal, etc
  2. Payment Provider ID - Unique ID for the Provider

The spec would go from

<a href="[url]" rel="payment" title="Donate Money Via PayPal">

to something like

<a href="[url]" rel="payment" title="Donate Money Via PayPal" provider="PayPal" providerUserID="someUserName">

In the case of PayPal, their MassPayRequest API (requires PayPal Developer Network login) requires either an email address or PayPal User ID. Other payment providers would need to have a similar API.

Would providing this information in a feed open up a person to potential security concerns? The User ID is somewhat exposed already when sellers use it on eBay and other auction sites. PayPal provides a way to encrypt the link for a button, but it requires knowledge of OpenSSL, etc. They also offer a "button factory" to simply creation of the link, which could then be used programmatically in an HTTP POST. If the button factory concept would work, the spec could remain close to the original (url becomes encryptedUrl):

<a href="[encryptedUrl]" rel="payment" title="Donate Money Via PayPal">

This would be a much more secure mechanism and achieve the aim of providing an automated payment mechanism.

 

 

 

Tags: , , ,