A shopper adds items on their phone while logged out, then signs in on a laptop where they already had a cart. What should happen?

There are two carts, and neither is obviously right

The framing that gets this wrong is "restore their cart". There is no their cart — there is an anonymous cart tied to a device or a cookie, and an account cart persisted against the customer, and at sign-in both exist.

Silently picking one loses items a customer put there deliberately. Which is why the first thing to say is that this is a product decision, and the options are enumerable:

Union. Keep everything from both. Nothing is lost, and the customer may find items they abandoned three weeks ago reappearing at checkout, which produces accidental purchases and returns.

Anonymous wins. The current session's intent replaces the stored cart. Matches what the customer was just doing, and quietly discards a considered basket they built on the laptop.

Account wins. Rarely right, because it throws away what they did most recently.

Ask. Show both and let them choose. Honest, adds a step at the worst possible moment, and is usually reserved for the case where both carts are non-empty and differ substantially.

Most retailers land on union with a visible summary of what changed, and the detail that makes it tolerable is the summary rather than the rule.

For the same product in both carts, quantities are usually taken as the maximum rather than summed, because summing turns two sessions of thinking about buying one into an order for two. That single choice generates a surprising share of "I never ordered two of these" contacts when it is wrong.

The prices have moved

This is where a session problem becomes a correctness problem, and it is the part that separates a considered answer.

A cart is not a set of prices. It is a set of intents — this product, this quantity — and the price is a snapshot taken when the item was added, which may be weeks old. Between then and now the list price may have changed, a promotion may have started or ended, and a coupon may have expired.

So the price shown at checkout must be recalculated, not read from the cart row. Storing the price at add-to-cart time is useful for showing the customer that something changed; it is not the price you charge.

The product question underneath is whether you honour the old price. Some retailers do within a window as a goodwill matter, some never do, and in some jurisdictions displaying a price and charging another has consumer-law implications. Whichever you choose, the customer has to be told: a basket that silently costs more than it did at the top of the page is the single most reliable way to lose the sale at the last step.

The stock has moved too

The same reasoning applies to availability, and it is easier to get wrong because nothing in the data looks stale.

An item added a week ago was available then. Now it may not be, and the cart is not a reservation — reservations are created at checkout and expire, they are not held for the life of a basket. Any design that treats add-to-cart as reserving stock will hold your entire inventory against abandoned baskets within a day.

So availability is rechecked at the point the cart is displayed and again at checkout, and the failure has to be graceful: mark the line unavailable, leave the rest of the basket intact, and tell them. Removing the line silently is worse than the disappointment, because it looks like a bug.

Where the cart lives changes what you can do

Worth raising, because the storage choice constrains the merge.

A cart held client-side disappears with the browser data, cannot follow a customer to another device, and cannot be recovered by support. A cart held server-side against a session survives a page reload and can be merged properly at sign-in. A cart held against the account is the only one that persists across devices before sign-in — which it cannot, by definition, until they sign in.

The conventional shape is server-side, keyed by an anonymous identifier in a cookie, and re-keyed to the customer at sign-in. That is what makes the merge a server operation with both baskets visible rather than a client-side reconciliation of two local states.

Lifetime is then a real decision. Anonymous carts kept for months accumulate storage and produce the reappearing-basket problem; kept for hours, you lose genuine returning intent. Thirty days is a common compromise, and it should be a configuration rather than a constant, because marketing will want it changed for peak.

What to say

The answer that scores names the two carts, gives the merge options with what each costs, commits to one with a reason, and then — the part most candidates miss — says that price and availability are recomputed rather than restored, and that the customer is shown what changed.

The underlying principle generalises beyond carts: a cart stores intent, not outcomes. Every derived value on it is a cache of something that has its own source of truth, and the checkout's job is to reconcile intent against current reality before taking money.

A cart is a list of things someone wants, not a list of prices they were promised. Merge deliberately, recompute everything derived, and tell them what moved.