How I hate Authorize.Net. Let me count the ways.

Recently, I had the opportunity to write a full green-field eCommerce implementation. I was, at the time, very excited! I had never done so before and believed that it would prove challenging.

I had no idea how true that would prove to be–and for all of the wrong reasons.

We chose Authorize.Net as our vendor because it seemed to best meet our requirements and ActiveMerchant as our preferred route to interact with the Authorize.Net Payment Gateway.

The first sign of trouble came when I made a support phone call to Authorize.Net asking them about their test environment for their recurring billing API. The customer service representative insisted that (1) the recurring billing API (known as “ARB”) is not actually an API and (2) as such, test environment support for it is minimal. When I say “minimal” I mean that most of the time it would acknowledge a request had been sent to it – and I say “most” specifically because our integration tests to this day still sporadically fail because of a connectivity issue to their test environment. When we asked about more support, we, quite literally, received a tone from the representative that made plain how little the customer service person was interested in providing us with good service.

Despite the customer service representative’s insistence that their so-called non-API API (if I can invoke it remotely, you tell me on or more URLs to use to communicate with it, they all take XML data and return data in XML, then it’s an API) test environment does not perform any validation, I found that the ARB test environment in fact seemed to perform some small modicum of validation of test credit card data supplied to it. Cool! It’s not necessarily the most performant way to validate a credit card but, at least initially, it saves some time, right? Therefore, my implementation expected that same behavior from their production environment.

How foolish of me to assume consistency…

As soon as I began integrating my code against their production system, many problems appeared:

When a user attempts to create a recurring payment (i.e., a “subscription”), validations performed by the test environment are not performed in the production environment. Therefore, the credit card data that we supplied to the production environment was entirely unvalidated.

Authorize.Net does not provide a way to attempt to re-bill a failed payment. It would be a simple matter to provide another API call to ask the recurring payment system to attempt to re-bill the latest failed charge. When I spoke to their customer support about this, they said that they thought that this sounded like a useful feature. Duh. Instead, you have to use another interface, the so-called Merchant Integration interface (AIM), to perform an authorize and capture operation immediately to bill the user. Thanks, Authorize, for making still more work for me that you could have fairly easily automated.

Authorize.Net also provides a simple shared-key encrypted method for POSTing to an application real-time information about payment successes and failures. The API that they expect is even reasonably well documented (I believe… but I’ll know full well shortly when Authorize.Net actually begins to use it). However, they don’t provide a test consumer of the API! Of course, being a good BDDer, I rolled my own. That still doesn’t give me the least bit of assurance that they actually implement to their own API.

Why?

Because, in the ARB guide, on page 13, they claim that you can update a customer’s subscription start date so long as the customer has yet to make a single payment. Guess what? Complete and utter bullshit. That’s right. Can’t be done. But their documentation says that it can.

ActiveMerchant itself actually got in the way. By attempting to provide a payment gateway-agnostic interface for speaking eCommerce, ActiveMerchant had to attempt to map all of Authorize.Net’s arcane arguments and return values to its own API. Essentially, ActiveMerchant attempts to fit a square peg into a round hole. After a couple of months of using both, had I to do it again, with Authorize.Net, I would have written my own Authorize.Net-specific abstraction layer to marshal and unmarshal their XML data into Ruby objects. ActiveMerchant, ultimately, proved to be a net loss for me.

In conclusion, given the bevy of eCommerce gateways out there, I would never ever recommend Authorize.Net to anyone. As far as I can tell, they basically hate eCommerce. Just don’t use it. Please. For the sake of whatever higher power you may believe in. Don’t.

Update 4/30/09: Add to my list of grievances that, should you have a technical question regarding integrating with Authorize.Net, your only recourse is to mail the developers at Cybersource, the parent company, who tend to have a turnaround time of approximately 24 hours. All of this while you could conceivably losing money!

Of the customer service representatives that I have dealt with at Authorize.Net, approximately half have been between rude or grossly incompetent. My second-most-recent (I called a second time today simply because this guy was so awful) would listen to what I said, type something, and then several seconds to a minute later ask a question. He was having more dialog with his keybaord than me!

Posted by evan on Friday, April 24, 2009

blog comments powered by Disqus