I have magento 1.9 installed. After placing an order while logged in, the shopping cart is not being emptied. If I place an order as "guest" though, the cart is emptied.

Is this an option somewhere, or just default behaviour? I would expect the cart to get emptied wether logged in or not.


This happens with persistent shopping cart both enabled and disabled.

  • 4
    why the downvote? it looks like a legitimate question. Commented May 28, 2014 at 9:01
  • I am on 1.8.1 and have exactly the same problem. Cart clears only for guests after the purchase but not for registered customers. @Maurice, were you able to find a solution? By the way our memory_limit is also at 256MB.
    – James
    Commented Jul 4, 2014 at 7:50
  • @James I'm sorry to say I haven't found a solution yet. Since I'm still working on the project, I decided to give it a rest and maybe see if there is going to be a patch coming out or not. I will definitely update this question when there's any new info.
    – Maurice
    Commented Jul 4, 2014 at 8:54
  • I have exactly the same issue on 1.8.1. Tried to increase memory limit up to 512M, but no change. Also tried disabling catching, Proxy catching, .htaccess rules for site optizmization etc, but so far without success. This is truly confusing.
    – Cninroh
    Commented Jul 8, 2014 at 0:28
  • @Maurice, did you end up leaving this bug in after going live, or?? I seem to have run into the same issue (Magento version just like your situation it only occurs for logged-in users, and disabling Persistent Cart doesn't help either, even after refreshing cache + reindexing... Are you running IWD Onepagecheckout as well? Commented Dec 10, 2014 at 9:45

3 Answers 3


I had a very similar problem with a controller that made orders programatically. What it came down to is that the quote is still active when it reaches the point that it should be cleared. take a look at my question and the answer I marked as correct.

Programatically clear the cart of a logged-in user

By setting the quote inactive ( $quote->setIsActive(0)->save() ) I was able to get it to clear.


I'm not sure about the following. I describe what I observe. I didn't debug it, because it went away after raising the memory_limit to 256MB (and there are still a lot of open tickets here :-()

We had the problem, that a memory_limit fatal error occured, this errors was "catched" by

public function __destruct()
    if ($this->_transactionLevel > 0) {
        trigger_error('Some transactions have not been committed or rolled back', E_USER_ERROR);

and because the transactionLevel > 0 the error was triggered, this error can be catched(?)... whatever...

It ended here in one of the ifs I think:

public function successAction()
    $session = $this->getOnepage()->getCheckout();
    if (!$session->getLastSuccessQuoteId()) {

    $lastQuoteId = $session->getLastQuoteId();
    $lastOrderId = $session->getLastOrderId();
    $lastRecurringProfiles = $session->getLastRecurringProfileIds();
    if (!$lastQuoteId || (!$lastOrderId && empty($lastRecurringProfiles))) {

In the end the order was written, the mail was send, but the cart was not cleared.

Turn on debug mode, then you see hopefully the

trigger_error('Some transactions have not been committed or rolled back', E_USER_ERROR);

And as I said, in our case, this was triggered by a low memory_limit.

  • In my case it's probably not a memory limit issue, since I have it a 256M as well. I take from your answer that at least it's not default behaviour or a wrong setting. Thank you for your answer and I'll dig a bit deeper into it.
    – Maurice
    Commented May 28, 2014 at 12:34
  • Of course it is no intended behaviour! This is a bug but not a known core bug Commented May 28, 2014 at 12:44

I finally got the time to debug this issue.

It traced the issue back to the MultiSafepay payment plugin, which is provided by the MultiSafepay payment provider. I contacted them and they helped me find the cause of the issue.

I am using the gateways checkout mode and this mode has an option under [Sales][MultiSafepay - Gateways][Settings][Cart remains active when the customer returns to the webshop or cancels an order], which does what it says. In my case this option is set to true, setting this option to false did not fix the problem.

Finally I discovered that another part of this plugin has a similar option under [Sales][Payment Methods][MultiSafepay][keep cart] which was set to true also. Even though this part of the plugin was disabled (by setting enabled option to false), this option still affected the behaviour.

So, after setting both the following options to no, the problem went away.

[Sales][MultiSafepay - Fast Checkout][Settings][Cart remains active when the customer returns to the webshop or cancels an order] = no and [Sales][Payment Methods][MultiSafepay][keep cart] = no

After changing both these values and clearing the cache, I still had a problem with a few users. But after clearing all carts with DELETE FROM sales_flat_quote WHERE is_active = 1;, the problem was gone.


MultiSafepay technical support has let me know that they've been able to reproduce this bug and are working on a fix. The current version of the plugin (which has this bug) is 2.1.1 and this will be fixed in a feature release.

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.