Jay Fienberg thoughts on payment protocols:
The “web” answer is more in the client / user agent than in the cloud.
Generally, payment mechanism on the web rely on someone being registered with a service, and then authenticated for each transaction.
That service handles a bunch of stuff that has to do with banking, and so is designed fundamentally as a node in the bank network rather than as a node on the WWW.
I don’t think that can be moved to the web in an open way. But, it’s possible to make that whole experience much more streamlined.
For example, someone who has a Google Checkout account can easily buy anything sold via Google Checkout. Same with PayPal and Amazon.
And, same with iTunes.
(And, on the other side: same with sellers, albeit with different restrictions about who can sell what / where through each service.)
And, that layer of web-to-banking service, theoretically, can be built on. And, I think it’d be most direct to work at the browser level, e.g. smart user agents.
In this case, an online seller would present, via a data format, a manifest of acceptable payment services, behind the scenes to the user experience. The buyer’s user agent (say, web browser) would then, behind the scenes and without hassle to the end-user, select the user’s preferred payment method and present the user with the minimal confirmation steps necessary to complete the transaction through that mechanism.
This could be akin to how Firefox handles subscription to RSS feeds, allowing the user to have a preset feed reader application that is invoked automatically when the user clicks a “subscribe to RSS” link.
However, in the case of online financial transactions, the user agent would want to allow for many services or protocols, and let the user define which is preferred for which types of transactions.
So, it’s “web” in the sense that it’s web browsers working directly banking APIs.
Flattr is a cloud service rather than a protocol.
PaySwarm is a protocol, not a cloud service.
The PaySwarm web platform is an open standard that enables web browsers and web devices to perform micropayments and copyright-aware, peer-to-peer digital media distribution.
Who can implement and use the technology?
Anybody. The entire PaySwarm standard is implementable on a patent and royalty-free basis, just like HTTP, HTML 4.01 and Javascript. This means that anybody may implement any part of the system without worrying about technology licensing fees or patent suits from any of the participating W3C member companies.
Four aspects:
1) Create a meta-payment system standard to enable PayPal et al to be integrated into the browser.
2) Facilitate the ability for the recipient of copies to pay the copyright holder.
3) Facilitate the ability for those interested in the production or development of intellectual work to commission the producer.
4) Provide a completely decentralised means whereby people can publicly declare financial transactions.
It seems to me that Jay is addressing the first aspect.
Flattr (cf Kachingle) and PaySwarm are addressing the 2nd aspect.
I’m addressing the 3rd (along with surprisingly few others).
The (distant) future is the 4th aspect (as per one of my previous comments).
I’m impressed with Paypal’s new “Adaptive Payments”.
Very good stuff. Just integrated it and it seems to fit well in the listener/musician context.
And could even become listener/label/musician/radio… split.
In reading your previous related posts, I was going to chime in with exactly what Jay Fienberg has suggested. I immediately think of how browsers handle RSS subscribing to how a Payment Transaction could be made.
Also….
This assumes that the page represents a single purchasable object.
Back in 2006, their was a proposal for rel=payment for more granular usage.
It’s also worth noting that crowdfunding is appropriate here. Meaning, your web app would be free and then you provide new features or game levels based on crowdfunding campaigns. if what you gave away for free is good stuff and garners a good following of fans/supporters, then a good percentage may be willing to contribute funds in order to get new stuff released. It’s the same common tactic used within app stores etc. So it should not be ignored for the open web approach.
Another thing to consider is media packaging technology that can control versioned dynamic network content. As you know, i’ve been paying attention to MAF (http://maf.mozdev.org) as a solution to test.
What this may lead to is having browsers be able to have a web app manager as part of the addon/plugin framework. So you can “install” or “register” a web app into the browser and have versioning etc. So the Browser becomes an App Store. The public website is open and free but the installed/registered version has more exclusive access to content/features…. effectively the pro version of the website.
Sull
sorry, my meta tag code got parsed out of the post. but yes, auto-discovery meta tags for payment gateways….
Tim, can you say more about how you used the adaptive payments thing? I didn’t really get it from the docs.