The "recover_cart" link redirects to the homepage: why cart recovery stops working

The symptom

A cart recovery link generated from the back office, something like /order?step=0&recover_cart=ID&token_cart=TOKEN, does not open checkout: it bounces back to the homepage, with no visible error message. It is not a problem with the link itself: the token is correct (it is computed with a hash that combines the store's cookie key and the cart ID), and it has not expired. The click simply does not go where it should.

What it looked like, and wasn't

The first, reasonable suspicion was a link-generation problem: a badly computed token, or a URL format changed by a recent update. That was not it: comparing the link generated by the back office with what PrestaShop expects to receive, the two matched exactly. The second suspicion was a cache or a server-side redirect rule intercepting the URL before it reached PrestaShop. That was also ruled out: the request was reaching the right controller every time.

At that point it became clear the problem was not in the link, but in something about the cart or the customer it belongs to, since some links worked fine and others didn't, with the exact same format.

The real cause

Cart recovery in PrestaShop goes through the recoverCart() method, called during FrontController::init(). Comparing the carts that failed with the ones that worked reveals two distinct conditions that lead to the exact same symptom (redirect to home), and only one of them is the one to fix.

• The cart has already been ordered. If an order already exists for that cart, PrestaShop will not reopen it: that is correct behaviour, not a bug, and should not be touched.
• The customer who owns the cart has been "soft" deleted. PrestaShop never truly deletes a customer from the database: it sets a flag (ps_customer.deleted = 1) and keeps the order history. The recoverCart() method, however, will not recover a cart whose owner is flagged as deleted, even with a valid token: it simply does not find it, as if the cart did not exist, and the request ends up on the homepage.

A customer can end up flagged as deleted for reasons that are not a technical error at all: they may have used a GDPR compliance module that offers account self-deletion, or they may have been deleted by a back-office operator. In both cases PrestaShop's behaviour is correct from its own point of view: a deleted account should not be able to become active again just by clicking a link. The practical problem is that this link is often the only way a real customer has to resume a purchase they had started, and the response they get, some generic homepage with no explanation, does not tell them why.

The fix

The fix touches recoverCart(): when the token is valid but the owning customer is flagged as deleted, instead of abandoning the recovery, the code checks whether another, active, account exists with the same email address.

• If no active twin account exists, the deleted customer is reactivated (deleted = 0) and recovery proceeds normally.
• If an active account with the same email already exists (the typical case is a customer who re-registered after deleting their old account), the cart is moved to the active account instead, and its linked addresses are cleared so they get re-selected at checkout, rather than being carried over from an account that is no longer actively used. This distinction is the part that matters most: reactivating an account when another active one already shares the same email would create two parallel accounts with the same login credential, which breaks login in PrestaShop.

Both paths get written to an application log before the normal cart recovery proceeds: it is the only way to later reconstruct why a deleted account came back active.

There is a policy point here, not just a technical one, worth stating explicitly: if a customer had requested account deletion for data-protection reasons, this fix reverses that the moment they click their own recovery link. It is defensible because the customer themselves initiates it, on the same link that was sent to them, but it remains a policy call to weigh case by case, not a purely implementation detail.

How to verify it holds

• Reproduce both cases: a deleted customer with no twin account (should reactivate, and checkout should load), and a deleted customer with an active twin account on the same email (the cart should move to the active account, addresses cleared, without touching the old account's state).
• Verify that a cart already tied to an order correctly stays non-recoverable: this fix must not change that behaviour, which is correct as it is.
• Check the application log after every recovery that involved a deleted customer: there should be one line for each reactivation or move, stating which of the two cases occurred.
• If the store runs a GDPR compliance module with account self-deletion, include this scenario in the test pass after every update to that module: that is where soft-deleted customers are generated most often.

The store where this case was diagnosed stays anonymous on purpose. If a cart recovery link with a correct token redirects to the homepage instead of opening checkout, and the cart in question has not already been ordered, the right place to look is the state of the owning customer, not the link itself. For ongoing maintenance on a PrestaShop store, there is a summary of services on this page.