I’ve had one of my worst days programming ever – which is a big call I know – but seriously after today I think no Magento bug will ever faze me again.
So for anyone Googling about Magento 1.4.2 and Google Checkout, here’s a couple of tips based on this bug report.
Flat Rate Google Checkout shipping
There’s a warning generated by Magento if you do not have all 3 flat rate options filled in:
Warning:number_format() expects parameter 1 to be double, string given
Warning: number_format() expects parameter 1 to be double, string given
I’ve had a love/hate/hate/hate relationship with Google Checkout and Magento for a long long time. Today marks a new low in our relationship. I’ve wasted so much time on this bug that I have made up a pie graph that illustrates the situation using Google’s charting API:
I’ve been on a journey to the bowels of the Magento Tax system and having spent the better part of 6 hours debugging through my issue I can safely say I will not do that again. The issue is that the totals are only collected once per address so depending on how many addresses you have and whether they are shippable or not, you get all sorts of weird results out of the shipping tax calculation. My issue was the calculated VAT amount on merchant calculated shipping in Google Checkout was wrong by a factor of tax % on shipping. So for £10 shipping in the UK, £1.75. Annoyingly it meant that Google would charge less than Magento recorded the order as being worth so now I have all sorts of mismatched order totals to deal with too. The issue could manifest itself as shipping tax being charged in Magento but not in Google Checkout too, if the tax was calculated on paid method, but the customer chooses a free method, for example.
This post is about the Magento Event system – a full explanation of how it works and a couple of issues I had with it resolved. Hope it is a help for people wrestling with the Magento event dispatch mechanism.
My particular situation was this: when automatically fetching tracking details from our carriers via a Magento cron job, the resulting Google Checkout Magento event did not fire, so the end customer was not receiving the notification properly – even though the ‘shipment’ object within Magento was correctly displaying the tracking details. Continue reading Magento Events Explained and a few Gotchas avoided!
I was recently asked for help on a Google Checkout problem where the Google Checkout Button on the Magento cart page was disabled with a message saying: “Not available with these items“.
I had a look at the Magento store in question and found a few clues to go on but a Google search on the subject proved to be of little help unfortunately. The button looks like the one shown in the screenshot below:
The underlying URL for the button is:
<img src="https://checkout.google.com/buttons/checkout.gif?merchant_id=5677186919&w=180&h=46&style=white&variant=disabled&loc=en_US" alt="Fast checkout through Google" />
<img src="https://checkout.google.com/buttons/checkout.gif?merchant_id=5677186919&w=180&h=46&style=white&variant=disabled&loc=en_US" alt="Fast checkout through Google" />
The big clue was the parameter on the Google Checkout button image URL on the problem store. It had variant=disabled which is generated server side, and so had to be coming from somewhere within Magento. A big fat grep over the code uncovered a variant=' string fragment in Link.php.
There is a lot going on when Magento actually sends a cart to Google Checkout, even more so if you are using Merchant calculated shipping. As a result lots of things can go wrong, with the merchant calculated shipping callback or with the actual server to server posting of the cart contents.
To help you with diagnosing problems I thought I’d shared my top 3 methods for finding out what is going wrong when Magento and Google Checkout are not communicating properly.
1) The Intergration Console
The first and most obvious place to try is the Google Checkout Intergration Console. As you can see in the screenshot below the console is hidden away in the Tools tab of the main seller dashboard. You’ll find it at the bottom of the left menu.
If the Google callbacks have failed or incorrect XML has been sent to Google you will find a report of the errors here. It is a good idea to keep an eye on the timestamps as you do not want to wind up chasing an old problem. It’s also good to periodically check this console while in production, just in case something starts to go wrong. I found when I upgraded to the latest Magento that the HTTPS callback was failing, but I hadn’t found it during development because I do not use SSL in development environments.