Paypal also allows you to add extra information to your button, which shows up in various ways (some useful, some less so) as part of the resulting Paypal transaction. Mysteriously, at some point when you start adding particular fields, Paypal claims that it is unable to encrypt your button, which means that theoretically someone could futz with your unencrypted button (although this would probably be caught), but more importantly you end up exposing your raw email address as part of the unencrypted button code. It's been this way for quite awhile, and it seems an obvious thing to fix.

Google Checkout encrypts everything, but the additional information you can add is quite limited. Since Google Checkout is the newcomer and is eager to please, I'll direct my comments at them, but I think Paypal might also be open to suggestions, because they've done some very good things lately -- in particular the postage-labeling system.

One answer to the issues I raise here is "hey, we have all that. It's possible to program to our API." I spent a fair amount of time about a year ago learning Paypal's API, so I know this is true. The Google Checkout API doesn't look much different, and the effort required to use that looks the same as Paypal's. Nontrivial. We need the simplicity of the "Buy Now" button applied to the other parts of the transaction. So "possible" doesn't cut it; we need the lazy web builder's solution.

My first observation is that data storage is split. I have to collect some information, and Google or Paypal collects other information. So if I want to keep track of things I have to capture that information, which means the user could easily end up being asked multiple times for the same information.

Why does the "Buy Now" button only capture some information? If Google is storing all the vast amounts of email I'm generating, why not a relatively small amount of information that goes along with each transaction? That way I don't have to decide what is stored on my server and what goes on Google's server. It all gets stored safely on Google.

So that's step one: The "Buy Now" button should allow me to add capture fields for any information that I need from the customer, and all this information will be collected via HTTPS just like the credit card information, and it will be stored in the same safe place as the credit card information.

Step two is the callback. Right now, a "Buy Now" button allows me to begin the transaction, but in order for me to know when a transaction is completed I have to climb the complexity cliff. Paypal actually has a callback in their "Buy Now," which simply takes the user to a page where you can say "thank you for purchasing," but without any information transferred about the transaction. To get the information you really need requires fancier programming, far from the abilities of the average (or lazy, like myself) "Buy Now" button user. Google Checkout appears to be the same.

The problem is that we're dealing with asynchronicity, the normal situation on the web. In effect, a "Buy Now" button starts a function call, but you can never know when that call will be completed, or even if it will be completed, and so it's not like a normal synchronous function call where you wait and it returns a value to you so you know it's done and you can move on. With an asynchronous call, you start it and then you need some other mechanism to know when that call is completed.

One solution, which we saw introduced in the concurrency library in Java 5 (although the concept was older than that) is the "Future", which is an object that is immediately returned from a function call. You can query the future to find out if the call is completed (which reduces you to polling -- not a good solution here).

What we need is to be able to go about our business and then, if and when the transaction is ever completed, we get called back. But in the case of both Paypal and Google, setting up such a callback is much, much harder than starting the transaction with the Buy Now button. For one thing, both services require that you create an API that operates within HTTPS. Not unreasonable, since they are sending you information that should be kept secure. But not something that the average "Buy Now" button creator can do.

I think the answer is to (again) move the complexity onto Google. For starters, if the problem is security, then don't send me anything that needs security. Instead, just tell me that "transaction 11238298398 completed." And this information will do no one any good unless they can connect back to Google (via Google's security) and find out what that means.

To do this, the "Buy Now" button user will need a simple messaging API on their server, which should be provided by Google in a form that can be relatively easily installed on any server. There may be minimal requirements (the server runs PHP, for example), but somehow a simple message can get from Google Checkout to your server, and the queue of messages would ideally be plain text or simple XML.

This definitely raises the requirments of the web developer, but only a little, rather than starting with the simplicity of "Buy Now" and then making a quantum leap into full-fledged programming. With this system, the web developer does need to be able to examine messages on the queue and write code, but that code is vastly simpler than what's required now.

When a message arrives in the queue, the queue calls code that you provide for responding to messages. You look in the queue and decide what to do. Multiple boilerplate examples of response code in different languages could be provided.

As mentioned earlier, the messages are trivial and safe to leave unencrypted. However, your response code can turn around and call back to the Google server, using all the security mechanisms provided by Google, and find out what transaction 11238298398 actually contains (short of the critical credit-card information, for example). In fact, at any time I should be able to call into the Google server and generate a report containing, for example, how many people are signed up for my next event. When I get the initial callback, I can reduce the number of seats available for that event, automatically send out the welcome information package for the event, etc. And since all the information I need has been collected via the "Buy Now" button and is stored at Google, it's easy for me to recover and use any of that information, without even needing to know anything about database programming.