Summary
I finally got around to setting up Google checkout for an upcoming conference. It rocks!
Advertisement
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.
> <p>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.</p>
Thanks for the good feedback Bruce, I'll forward that to the Google Checkout API team. We're striving on making the API easier to use: would you care to elaborate on what kind of callback system you'd like to see us implementing?
Google Checkout does actually have asynchronous callbacks, including new order notifications, fulfillment & financial state change notifications, and others. If I read your post right, this should be what you are looking for.
PayPal's IPN (Instant Payment Notification) system is our current offering for asynchronous notifications. There are several business built around the reliability of this messaging system. https://www.paypal.com/IntegrationCenter/ic_ipn.html
I'm also a happy Google checkout user, both as a seller and a buyer.
I can answer what *I* want to see in a Buy Now button.
First, along the lines of what Bruce described, providing access to limited resources is key. So let's say that I have 45 seats available for a conference. It would be great to be able to set up the buy now button to decrement the number of available seats, and turn off registration when the max is reached. I suppose that it would also be advantageous to be able to change this number manually within the "settings" area, so that if (for whatever reason) seats were sold outside of the checkout interface, then things could be kept in sync.
Second, I want to allow my customers to buy "n" seats, all at the same price, all on the same bill. I didn't see a way to do this other than listing items explicitly.
Third, it would be great for my customers to be able to enter some textual description for me when they purchase, so that they can tag a purchase with someone else's name (e.g., admin buys a seat at a conference for employees).
If I could do these 3 things, I could manage an event without venturing into the API at all. That would be FANTASTIC!
I also found PayPal IPN a few years back, and it worked like a charm as the actual payment processing piece in a dynamic event registration system I built. The fact that it was built on open standards (just a simple http callback) made it a snap to integrate into a ColdFusion based system (something that tended to be dicey before ColdFusion MX's conversion to Java).
I am curious about Google Checkout now though.... I'll have to weigh the risks of giving them my transaction data. I know Google pledges to "do good", but who knows what the future brings. Of course, it's not like PayPal has a sterling record.
DEFINITELY try it! The selling points for me were: 1. It's free through the end of 2007. NO credit card fees. That's really nice. And their published fee structure is less than paypal's (unless you are at the highest tier for paypal, and then paypal is 1.9% vs. google's 2%). 2. The money goes directly into your "connected" bank account once you process the transaction. You do not have to do anything special for a payout. There's a few days holding while the credit card transaction is processed, and then the money gets transferred. None of the nonsense where paypal holds onto the cash until you remember to move it over.
The "Buy now" button was really easy to set up. I did offer some suggestions above, as to how I hope that it might be improved to add even more functionality, but for the most part, it's cool.
And, I hear that Google checkout is now supported in the UK as well as in the US, so that's great too.
Now, if EventWax had a google checkout plugin, that would be very cool. I hear it only supports paypal at this time.
Let's review them in order. I will first explain what I think about the suggestion, then provide a workaround for how to achieve the effect with the system as it is today.
1. Having the option to cap the number of available items and have it managed on the Google side is a great idea. I'll add that as a feature request. We'd also eventually need to open an api to let you manage that number automatically.
As the system exists today you can achieve that effect by maintaining the total number on your site and using the HTML API to create your own buttons. It is not very complicated, you just build a form with a variable parameter for the number of items, but you need some kind of backend storage in order to keep the count. If you want something simple you update the count yourself when you receive email notifications of orders, if you want something more fancy you can process notifications (we have sample code in many languages that show how to do that) and update the count when the order is billed.
2. For the Buy Now button with a quantiy. You can definitely do that with current Buy Now buttons, by using a button with options and prefilling harcoded N options with the right price. This is a bit clumsy, and it wold be even easier to use the HTML API and just make the number of items field visible.
Thanks for the workarounds Patrick. I think that the main point of Bruce's post (or at least mine) was that "non-programmers" want to be able to use "Buy Now" buttons and so it's imperative to make the most common things that they will want to do possible WITHOUT any attention to web programming. No managing forms. No managing internal storage of quantities. Having Google manage the quantity would be IDEAL, and an API to allow the "programmer" to access this number would be nice.
I knew about the workaround for n options with the prices specified, but it was simply too clumsy for me to want to bother with! Instead, I simply invoiced people who indicated (via email) that they wanted to do multiple registrations!
I'll really look forward to some improvements in the Google Checkout Buy Now button. As I said, I'm quite pleased with it, for what I used it for. With a few tweaks, I think that it will be quite powerful.
Previous Topic
