Today I would like to look into the case when a customer has items in their authenticated shopping cart, browses the site anonymously as a guest, creates a new shopping cart, and then logs in. The question is what should happen to the items in the account-linked cart versus the items in the anonymous cart.

For merchants, there is a reason behind merging carts: they do not want customers to forget the products they intended to buy earlier. From the customer’s perspective, having extra items in the cart after logging in may be confusing and undesired, especially if this happens during the checkout process and especially if the shopping carts are large and complex.

There are five possible solutions:

• Non-interactive
  • “Session cart priority”. If a customer has an anonymous cart, the account-linked shopping cart will be ignored after login. If the anonymous cart is empty, the shopping cart contains the items from the account-linked cart.
  • “Cart Archive”: Replace the old cart with the latest cart, move the contents of the old cart to the wish list or archived carts list, and inform the user about the actions taken.
  • “Merge”: Combine the shopping carts so the user still has a single shopping cart, and the merged cart replaces the old account-linked cart. Inform the user about the changes.
  • “Multiple carts”: Merge carts by default, but let the customer undo the operation and restore one of two saved carts: “anonymous/guest” or “old account-linked”.
• Interactive:
  • “Interactive”: Explain the situation to the customer and let them decide what they want to do: which cart to keep or whether they want to merge them:
    • You have items in your present cart, but you also have items stored in a previous cart. Would you like to:
      • Continue with your present items
      • Merge your saved items into your present purchase

I find “Merge” and “Multiple carts” to be the best options. The second strategy is explained at the end of this article as an “experimental solution”. It is not enough to explain how additional items appeared in the cart; you should also let the customer decide which of the shopping carts they want to keep or merge.

In SAP Commerce, the default strategy is “Restoring an account-linked cart only if the anonymous cart is empty”, which is titled “Merge” in the list above. The idea is simple: SAP Commerce ignores an account-linked cart if a session cart is present.

The alternative SAP Commerce out-of-the-box strategy merges the account-linked and anonymous carts so that the resulting account-linked cart contains all their unique items combined together. However, it is not designed to be interactive: you can’t pause the operation to let the customer decide.

Online stores such as Amazon, eBay, Target, Etsy, Walmart, Aliexpress, and Barnes and Noble use this approach too. More specifically, they use “a silent cart merge”: the cart from the session is combined with the cart from the account after the customer logs in, without any messages or popups.

Using cart-merging functionality raises new questions and challenges.

For example, if you have the same SKU in both carts, how many products should be in the final cart after merging is done? Common sense tells us that the right answer is one product in the amount of two pieces. That is exactly how I ordered two iPhone 6 cases instead of the one I needed a month ago.

If one or more products are not available at the time of cart recalculation, SAP Commerce simply removes them from the shopping cart and informs the user. This simple strategy is used by default. Is it correct? It works well in most cases, but for some businesses and setups, such as online grocery stores or B2B portals, you may find it inappropriate. For such cases, consider an alternative approach in which the products are marked as temporarily unavailable and the system offers substitute products instead of unavailable ones. Marking products as unavailable instead of removing them from the shopping cart has another advantage: the unavailable products can be back in stock the next time the customer visits the website.

You also need to check the case when incompatible, mutually exclusive products exist in the basket after the merge. The products should remain in the basket, but your shop should notify the customer and prevent the order from being completed until the incompatible product has been removed.

If anonymous customers are able to change the state of their shopping cart by adding a coupon or specifying delivery details, the merge process may become challenging if the session cart and account-linked cart configurations are in conflict. If the anonymous cart already has a coupon code, the coupon code of the new cart should be discarded.

Yet another question is often raised: should we restore the anonymous cart after the customer signs out? Of course, the cart must be emptied at the end of the session. The rationale is the following:

• Leaving the account-linked cart doesn’t seem right because of security and privacy considerations.
• Restoring the anonymous cart is not correct either, because one of the products from the original cart, or the whole cart, may have already been purchased by the end of the customer session.

SAP Commerce Out-of-the-box Merging Carts Strategy: Architecture and implementation details

To use mergingCartRestorationStrategy:

• Create a your-customized-addon extension.
• Add the following code in the your-customized-addon-web-spring.xml:

<alias name="mergingCartRestorationStrategy" alias="cartRestorationStrategy"/>

• Install the addon via:

ant addoninstall -Daddonnames="customized-addon extension" -DaddonStorefront.yacceleratorstorefront="your acceleratorstorefront"

Let’s look closer at how it is implemented under the hood.

A customer logs in to the system. The Spring Security config defines the bean responsible for the successful login scenario, which is loginGuidAuthenticationSuccessHandler. This bean is linked to the class/method GUIDAuthenticationSuccessHandler.onAuthenticationSuccess(request, response, auth). In this class, the system sets up cookies and passes the baton to StorefrontAuthenticationSuccessHandler.onAuthenticationSuccess(request, response, auth). If the user is not from the admin group, the system attempts to restore a cart by calling CartRestorationStrategy.restoreCart(request).

So, to activate a merging cart strategy, you need to change a cartRestorationStrategy parameter of the defaultLoginAuthenticationSuccessHandler bean in <yourstorefront>/web/webroot/WEB-INF/config/spring-security-config.xml.

Scenario 1. DefaultCartRestorationStrategy (“Restoring an account-linked cart only if the anonymous cart is empty”).

The restoreCart method of this strategy checks if the current shopping cart is empty or not. If it is empty, the latest account-linked cart will be restored. Otherwise, nothing will be changed: the session cart will be left untouched, as is.

Scenario 2. MergingCartRestorationStrategy (“Merging the account-linked and anonymous carts”).

The case when both a session cart and an account-linked cart exist is processed by restoreCart in the mergingCartRestorationStrategy.

The system finds the most recent cart — let’s name it “A” — for the current user and the current website and merges it with the session cart — let’s name it “B”. The process has the following steps:

• Recreates a new session cart — let’s name it “B” — from the current session cart (B)*
  • Removes all payment transactions linked to cart B.
  • Regenerates the cart GUID for B*.
  • Recalculates cart B* — entries, totals, discounts, taxes, and so on — via commerceCartCalculationStrategy.
    • If any entries aren’t available, they won’t be added.
  • Updates promotions on B*.
  • Executes cart calculation hooks — “before” and “after” — on B*.
• Recalculates the cart (B*) again — entries, totals, discounts, taxes, and so on — via commerceCartCalculationStrategy. This time it is done for the new cart object, which is a duplicate of the original session cart.
• Updates promotions again on B*. This time it is done for the new cart object, which is a duplicate of the original session cart.
• Calculates external taxes if needed.
• Merges the recreated session cart (B*) with an account-linked cart (A, the most recent one if there is more than one):
  • Special processing for entry groups (if any).
  • Moves all cart entries from the account-linked cart (A) to the current session cart (B*).
  • Removes the old session cart (B).
• The merged cart is a union of A and B: C = A + B*.
• Recalculates the resulting cart (A + B*).
• Calculates the (A + B*) cart again via commerceCartCalculationStrategy.
• Updates promotions again on A + B*.

In terms of performance, merging carts can be slow and resource-intensive, because your shopping cart is recalculated against different sets of products several times within a single session.

As you can see from the process above, the shopping cart is recalculated three times. Moreover, in fact, there are another three recalculations outside this process, which makes six recalculations per session. In all these six calls, cart recalculation is followed by the process of applying promotions, which is also slow and CPU- and memory-intensive, especially for large carts and a large number of promotions. I recommend including this scenario in your performance tests, then planning and implementing changes if necessary.

How to reproduce:

• Prerequisites:
  • Account-linked cart — 6 items
  • Anonymous cart — 1 item
• Scenario:
  • A customer signs in with 6 items in the account-linked cart and 1 item in the session cart.
• In total, after the customer logs in, the following methods are called six times (!):
  • calculateEntries, calculateTotals, updatePromotions — 6 times
    • First — From onAuthenticationSuccess → loginSuccess → updateSessionCurrency → setSessionCurrency → recalculateCart → calculateEntries
    • Second — From onAuthenticationSuccess → loginSuccess → recalculateCart → calculateEntries
    • Third — From onAuthenticationSuccess → restoreCart (mergingCartRestorationStrategy) → restoreCartAndMerge → restoreCart (service) → restoreCart (DefaultCommerceCartRestorationStrategy) → recalculateCart → calculateEntries
    • Fourth — From onAuthenticationSuccess → restoreCart (mergingCartRestorationStrategy) → restoreCartAndMerge → restoreCart (service) → restoreCart (DefaultCommerceCartRestorationStrategy) → calculateCart → calculateEntries
    • Fifth — From onAuthenticationSuccess → restoreCart (mergingCartRestorationStrategy) → restoreCartAndMerge → restoreCart (service) → restoreCart (DefaultCommerceCartRestorationStrategy) → recalculateCart → recalculate → calculateEntries
    • Sixth — From onAuthenticationSuccess → restoreCart (mergingCartRestorationStrategy) → restoreCartAndMerge → restoreCart (service) → restoreCart (DefaultCommerceCartRestorationStrategy) → recalculateCart → calculate → calculateEntries

Alternative solution: Undo/Multiple carts

I consider this solution experimental. I haven’t seen any live shops using this approach. If you know any, please let me know.

In this solution, the carts are automatically merged too, but the difference is in what the customer can do afterward. If the carts are merged, the customer is redirected to the shopping cart page, where they can undo the operation and restore one of two saved carts — “anonymous/guest” or “old account-linked” — or leave things as they are.

If the customer decides to merge the carts, clear out the anonymous cart and move the items to the account-linked cart. If the user chooses to keep the carts separate, let the customer continue shopping with the account-linked cart. Once the user signs out, or is automatically signed out, revert to the anonymous cart.

If implemented correctly, this could be a really slick feature unique to SAP Commerce.