Lucas, I think your problem statement is right on. But I think 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.

What do you think?