I’ve currently in the process of integrating Magento (1.8.1 ce) with the authorize.net gateway using the direct post method (DPM). Despite Magento being configured to work with authorize.net straight out of the box there have been a few issues and abnormalities. So I thought I would just run through a few in case anyone else out there is suffering with any of the same issues. Or maybe it will give the uninitiated an overview of what they can expect. Although I’m using Magento, there maybe information here that is useful to other platforms such as WordPress.
Sandbox and Currency
My first issue came with testing using a sandbox account. I was getting an error:
gateway error: (TESTMODE) The supplied currency code is either invalid, not supported, not allowed for this merchant or doesn't have an exchange rate.
This is due to to all sandbox accounts having their default currency fixed to USD… so when using a Magento site set to a different currency (GBP in this case) it cleanly doesn’t like it. The solutions are either to set your Magento site to USD for testing. Or in the knowledge that the error message at least shows to two systems are communicating, skip this process and step and jump in with registering a live account (the route I choose). Authorize.net did supply me with details of a ‘shared’ account that can be used for other currencies, but with the absence of an MD5 hash I guessed this wouldn’t work with the DPM so didn’t bother to peruse this. After the rather lengthy application process (which I will write a post about soon) and being supplied with my live gateway credentials I thought it would be plain sailing from this point forward. Or so I thought…
Before I get stuck into that though, let me just point out that you need to make sure that you are using the correct API Login ID and Transaction Key in your Magento ‘Payment Methods’ settings. These are found in the ‘Account’ tab or your Authorize.net account and are not your login and password that are used to login to the web interface (https://account.authorize.net). You will also need to set a ‘Merchant MD5′ if using the DPM. This again is found under the ‘Account’ tab. Your Authorize.net account should be set to test mode upon creation, so there is no need to set test mode in Magento to ‘yes’ or to use the test gateway URL . These can be left to ‘no’ and ‘https://secure.authorize.net/gateway/transact.dll’.
Forever ‘Submitting Order Information’
The next issue I encountered was upon submitting an order from my Magento one page checkout, Magento just hangs and displays the message ‘Submitting order information’. My first thought was, although my gateway was setup, I was still waiting for my AIB merchant account to be setup… so maybe this was causing the issue. I submitted a support ticket via email to Authorize.net and had a phone call the next morning from a guy who was quite helpful. He verified all the setting I was using were correct and also submitted a transaction via my virtual terminal. That went through ok meaning the gateway was set up and operational. This confirmation was all I needed to warrant spending time investigating Magento as the route of the issues. I set about using the setting my site to run the default theme, disabling all community modules, removing all local edits to core files, yet it still didn’t work. My next course of action was to install a totally clean ‘out the box’ instillation of Magento in a new directory. After creating a sample product and setting a few basic configurations in the systems tab of Magento I submitted an order and it miraculously communicated with the Authorize.net server. There was an error message but I was happy with the progress at this stage. Next I stated to add my bespoke skin, template phtml files, edits to core and extensions one by one. After every step I did a test transaction and everyone went through ok… scratching my head I decided to look at mirroring more and more of the settings. Again, one by one every thing was ok… untill there is was… the dreaded woring AJAX ‘Submitting order information’ message stuck on the screen. The answer, Magento compilation mode. I had this enabled on my site. Disabling it fixed the issue. Now this isn’t enabled by default, so I’m guessing that’s why I couldn’t seem to find my solution on support forums anywhere. So hopefully, if like me you have this mode enabled and are suffer the same issue you will stumble across this post. I’ve not looked into the reasons why the two seem to conflict, but will update if I get around to it. The only lead I have to work on is that when analysing the process of the working and non working sites side-by-side (with the network tool in Google Chrome) path that hangs on the non working site has a request URL of http://www.madaboutboxes.co.uk/authorizenet/directpost_payment/place/form_key/[random key]/ (I’m guessing this is a step prior to the one where the transaction information is posted to Authorize.net). The difference between this and the working site is the response header has a different ‘content-type’… ‘text/html’ in the non-working site and ‘text/html; charset=UTF-8′ on the working one. Whether this is a cause or symptom I’m not sure at this stage.
Transaction ID Is Empty!
So now I thankfully have my live site talking with Authorize.net using DPM. However, as I said above, it’s now generating an error when submitting an order. The error says:
payment authorization error. Transaction id is empty
The anomaly here, is while Magento is saying there is an error and it marks the order as cancelled, Authorize.net sends you an email saying entitled ‘Merchant Email Receipt’ with everything looking in order. Looking at the Authorize.net log file (see tip at bottom of page) in Magento the response from Authorize.net has a line reading:
[x_response_reason_text] => (TESTMODE) This transaction has been approved.
Upon investigation, while Authorize.net approved the transaction, because it’s in text mode it doesn’t set a transaction id (or sets it to zero). Magento obviously doesn’t like this (probably quite rightfully so), so it shows the error and doesn’t process the order. Apparently this is normal. The problem it creates though is you are then unable to precess a full transaction while your Authorize.net account is in text mode. The same happens if you set your Authorize.net to live, but your Magento settings for Test Mode to ‘yes’. So great, there’s a test mode that doesn’t let you test the system at all.
Ok, So I’ll Go Live
I then attempted to run a transaction in live mode using a test card. It now responds with a transaction ID but also a different error:
gateway error: The request field(s) are either invalid or missing.
I fully checked my post request (using the debug log file) and all seemed in order. A call to the Authorize.net support line sheds light on the matter though. As my merchant account is still in the application process the processor hasn’t yet been enabled meaning this is literally as far as I can go. I’m a little disappointed that I can’t run test transactions due to the inadequacies of Authorize.net’s test mode, you would have thought that this 2-3 application process for the merchant account would have been the ideal opportunity to not only test the gateway with the checkout, but also with all the back office functionality of Magento.
While I hope this process would be a little more straight forward from other merchants, I think it demonstrates that just because Magento comes out the box with an Authoize.net integration module, don’t think that it’s going to be as straight forward as I, maybe naively, did. The compilation mode issue is clearly an issue with Magento. But with regards to the testing issues. undoubtedly Authorize.net would point the finger at Magento, but in my opinion it’s Authorize.net’s test procedure that is lacking here… I don’t think expecting a transaction ID on a test order is asking for too much.
Let me leave you with just one little tip. It’s not entity obvious what the ‘debug’ option in the Authorize.net settings (in Magento) actually does. When it’s set to ‘yes’ it means all the request and responses to and from Magento and Authorize.net get logged in a log. You will find this file in the ‘var/log’ directory. payment_authorizenet_directpost.log is for the DPM and payment_authorizenet.log for the AIM (other) method.