Magento's default behavior seems to be to update a shipping quote for every single modification to a shopping cart. I find this very undesirable because it can cause the shopping experience to become unnecessarily slow while Magento waits from quotes from all carriers.

Magento also seems to be very loose on what it calls a "Quote", with there being Sales Quotes and Checkout Quotes. So, even though I have very little experience working with Magento Events, I am having a hard time figuring out where to even start.

How do I stop Magento from getting a shipping quote for every item added or removed from the cart? Just a point in the right direction would be a big help.

  • There is only one quote: sales_quote the complete logic of the checkout is based on the sales_quote. The cart doesn't exist, it is only a wrapper for the quote. What shipping quotes you are talking about? IF magento does this (what I don't know), it only looks things in the database up, this should be fast. Commented Aug 20, 2013 at 12:19
  • I'm talking about when it retrieves UPS shipping cost
    – andyjv
    Commented Aug 20, 2013 at 12:50
  • UPS is a extension? Then it is somewhere there in. Commented Aug 20, 2013 at 14:47
  • I think this does happen when the client already visited the checkout and provided an address and shipping method. The shipping costs are then displayed in the cart but I'm not sure if it's updated. 'Preventing' something like this would require quite some core editing I imagine, might not be the best way to go. Optimising your database, or perhaps upgrading your hosting might be a better solution. (But that's my honest opinion) Commented Aug 20, 2013 at 21:37
  • You're right, it happens after the customer has already provided an address. The problem is that if UPS takes a long time to return a quote, it will cause Magento to hang.
    – andyjv
    Commented Aug 21, 2013 at 1:16

1 Answer 1


I had a similar issue, where shipping lookups were done via australia post (using the fontis australia module located here:


If you dig a bit further, you'd most likely find that the lookup also happens via checkout, which is unnecessary, as the quote has not changed.

I implemented a fix (which was merged into the fontis module) a while back, which does a simple cache of the lookup in the session, and re-uses that on subsequent requests.

from: https://github.com/fontis/fontis_australia/blob/master/app/code/community/Fontis/Australia/Model/Shipping/Carrier/Australiapost.php

                 * Lucas van Staden @ doghouse media 
                 * Add a drc call cache to session. (valid for 1 hour)
                 * The call to drc is made at least 3-4 times, using the same data (ugh)
                 *  - Add to cart (sometimes * 2)
                 *  - Checkout * 2
                 * Create a lookup cache based on FromPostcode->ToPostcode combination, and re-use cached data
                 * The end result will kill lookups in checkout process, as it was actually done at cart, which will speed checkout up.

            $drcCache = Mage::getSingleton('checkout/session')->getDrcCache();
            if(!$drcCache) {
                $drcCache = array();
            } else {
                // wrap it in a try block, s it is used durng checkout.
                // prevents any mistake from stopping checkout as a new lookup will be done.
                try {
                    $time = time();
                            && array_key_exists($fromPostCode, $drcCache) 
                            && array_key_exists($toPostCode, $drcCache[$fromPostCode])
                            && $time - $drcCache[$fromPostCode][$toPostCode]['timestamp'] < 3600) {
                        if ($this->getConfigFlag('debug')) {
                            Mage::log('Using cached drc lookup for ' . $fromPostCode . '/' . $toPostCode, null, 'fontis_australia.log');
                        return $drcCache[$fromPostCode][$toPostCode]['result'];
                } catch (Exception $e) {

You would most likely need to implement something similar (at the cart level) in the provider module you are using. The fix above was to solve the lookups causing checkout to take very long, when the provider was busy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.