Amazon Turns Away My Money

I have just had the pleasure (and displeasure) to build a tool on top of Amazon's E-Commerce Service.

My overall feeling is that Amazon does not actually expect users to use this service and only built it as an entertaining joke on how not to build web services. After attempting to talk to their customer service who all use the usual canned responses to difficult questions that fail to answer your question, and even tracking down a few developers through friends of friends; I now can say with certainty that this web service isn't reliable, nor should it be relied upon.

Despite this, I still attempted to build a tool that both relies on Amazon and needs some level of stability. Cart Control - built for college bookstores - it is meant to automate the shopping of used books. Bookstores deal in bulk, and Amazon just didn't have the necessary tools for them to quickly buy books, so I did my best to supplement what I could.

Oh, the pain.

You cannot delete a shopping cart with one, two, or even three clicks. This is problematic when you use my tool to build a cart of 3,000 books and then decide you don't want the books. It takes on average two clicks to delete a single item, which means 6,000 clicks total needed. With an average page load time of 4 seconds after each post back, it can take up to 6 hours to clear the cart.

Amazon only half supports 13 digit isbn numbers. They use the EAN field for 13 digit numbers, and the Isbn field for 10 digit ones. This means in your code when building search requests you have to do something along the lines of :

ItemLookupRequest request = new ItemLookupRequest();
request.Condition = Condition.All;
request.ConditionSpecified = true;
request.DeliveryMethod = DeliveryMethod.Ship;
request.DeliveryMethodSpecified = true;

request.ItemId = new string[] { isbn };
request.OfferPage = page;
request.MerchantId = "All";
if (isbn.Length == 13){
request.IdType = ItemLookupRequestIdType.EAN;
request.IdTypeSpecified = true;
request.SearchIndex = "Books";
}
else {
//do nothing, 10 digit ones just work, Amazon designing at its best
//request.IdType = ItemLookupRequestIdType.ASIN;
//request.IdTypeSpecified = true;
}

You might be tempted on the above if statement to have an else that defines the IdType to ASIN, but don't, you'll get no results back.

Notice request.DeliveryMethodSpecified, request.ConditionSpecified? They have these member variables all over the place, basically after giving them a value, you also have to tell them you are giving them a value. These are terribly documented, and really make no sense. Couldn't they check if I sent them the value? The only way you'll know you forgot one of these is that Amazon ignores your request, so if in doubt, search for a corresponding bool field that you can set to inform them you want to set a member variable. They aren't that consistent, you'll notice in the above example I don't need them for everything, so be careful and double check your work.

1 query a second.

Okay, I know this service is free and given Amazon's history of crashing on Harry Potter launches, we all know their data centers are not the most reliable, but being restricted to one query a second is very frustrating when dealing with a bookstore's shopping list. If I have 3,000 books each of which needs 4 titles, I have to send a fairly large number of requests, each of which must be spread out to play nice with Amazon's query rule. I even sent them an email asking if there was some top secret service I could pay for for the right to send queries more frequently, but to no avail, there is now a "System.Threading.Thread.Sleep(1000)" in my code. Ugh, so ugly.

And how do I buy 3,000 books from Amazon?

Well first of all, Amazon.com's shopping cart seems to reliably crash if you have more than 50 books. Yep, Amazon does not want you purchasing too many items from them! I wonder if this is to curb the shopoholics who sneak around Amazon.com at late hours. By building in a natural restriction on cart size, they do the socially responsible thing and keep the orders of rubber ducks to a respectable level.

If you have found a work around to cart size (ie, building lot's of small carts), putting your credit card in to make your payment makes sense, right? Since I'm purchasing used books that is my only option. Amazon.com used to support paying by bank account but recently disabled it so I was forced to use my Visa. I woke the next morning and over my mug of coffee drearily logged into my email....and what did I have the pleasure of finding but 2,955 cancellation emails. Apparently no matter what you try, credit cards companies will not allow you to make a large number of purchases from Amazon.com due to fraud protection rules. I begged, pleased, and blackmailed Visa and MasterCard, but never had a successful order using a credit card. Now that Amazon Payments has launched we might be able to use it, but the jury is still out.

Wait, did you read the above paragraph completely? Did you skip over that number ... that 4 digit number. That is not an exaggeration. For every seller you purchase from on Amazon's used marketplace you'll get an email confirming the purchase. This results in a lot of emails. Even worse, I have a bank statement 4 pages long with entries like "Amazon Charge 4.55". The bank statement does not say for which order it is from, making accounting impossible. Suppose after all of this, I should just have faith that Amazon will bill me correctly.

And with all of my complaints and requests to Amazon I got mostly unhelpful responses. Given I'm trying to give them money by enabling more users to shop Amazon.com, one would think they might be just a little helpful, but maybe they just aren't in the business to make money.

This API is not for the faint of heart. I'm a happy Amazon shopper, and still am despite my disappointment in their API support. This post is overall a long list of negatives, but there are so me fantastic tools that you can build. Having access to a database of books and prices can result in fantastic informational tools. Just don't expect to have much success in using it to purchase books. To be fair, Cart Control is built and usable, but it is difficult not to look back and ponder whether all of those late nights really paid off.

Next for me: Research using an alternative used book reseller for Cart Control. Someone out there must want some more money and be willing to construct a useful process for buying large quantities of used books.