Summary
I finally got around to setting up Google checkout for an upcoming conference. It rocks!

One thing I like is how straightforward it is -- they take the customer right to a form to fill out, and don't try to get you to use their own account like Paypal does (which forces me to put an explanation up on the page before about how you don't need a Paypal account, and you can use a credit card if you skip past that part).

Until Google checkout comes up with something as slick as Paypal's label-printing and postage-printing setup, I'll continue to use Paypal for physical orders. But for events, no question about using Google checkout. Especially the no-cost part until the end of the year. And what's even better is that it costs me nothing to use Google checkout for some things, and Paypal for others. I would never have considered using Authorize.net and another service. After using (or I should say struggling; the programming was much harder) it for years, I just canceled the Authorize.net merchant account and it felt quite liberating. I am saving at least 38$/month to the bank in monthly fees, plus all the random little fees the bank would tack on -- I swear it looked like they invented them and kept the fee low enough that it made it too much trouble to ask about it -- plus the higher percentage per transaction. And that percentage was never refundable if I gave a refund -- the bank always kept it. Paypal has a flat percentage on a transaction, which is significantly lower than what I was paying to the bank, and they refund that percentage if you give a refund. Plus no monthly fee. Google checkout, until the end of the year, has no fees at all. I'm guessing that the banks are seeing more and more cancellations like mine.

Google checkout has the same problem as Paypal, in that the moment you want to do something more complex you're faced with this complex API and messy programming. What happened to the simplicity we were supposed to get with web services, where a web site ends up looking like an API and you just make SOAP calls like they were local function calls?

The big problem with web services in general shows up in both Paypal and Google Checkout. Web services seems primarily based on a synchronous function-call API, but the web is an asynchronous system. What's missing is the ability to set up a callback when a task is completed. There are messaging systems, but when you want to do something simple -- like set up a "buy now" button and have Paypal or Google Checkout call back to your system after the transaction is complete (so you can, for example, reduce the number of available tickets for a play), the process is either impossible, or so monumentally difficult that most people don't bother. We need a "buy now" button callback system.

Until the design of web services acknowledges that the web is an asynchronous system, and simplifies the callback process, it doesn't bring that much to the table. It's still too hard to program in the world of the web, which needs quick, easy and dynamic.

Talk Back!

Have an opinion? Readers have already posted 9 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.