Persistent Carts with Next.js and Laravel Sanctum: My Approach

Persistent carts with Next.js and Laravel Sanctum mean a customer's cart follows them across pages, sessions, tabs, and devices — not just within a single browser tab that resets the moment they close it. I build this by tying the cart to the customer's authenticated identity on the Laravel side, using Sanctum's token-based authentication, rather than relying on browser storage that disappears the moment a cookie clears or a customer switches devices.

Here's exactly how I structure this persistence, from initial authentication through to the guest-to-authenticated cart merge that keeps a customer from losing what they've already added.

Why Browser Storage Alone Isn't Persistence

Browser storage alone isn't real persistence because it's tied to one specific browser on one specific device — a cart stored in `localStorage` disappears if a customer clears their browser data, switches from their phone to their laptop, or simply opens a private browsing window. Real persistence means the cart lives on the server, associated with the customer's actual identity, so it's available wherever that customer logs in from.

This distinction matters commercially, not just technically. A customer who builds a cart on their phone during a commute and expects to finish the purchase on their laptop that evening will simply lose the sale if the cart doesn't follow them — and that's a purely technical failure that has nothing to do with whether they actually wanted to buy.

I see this pattern most clearly with considered purchases — furniture, electronics, higher-value fashion — where a customer often browses on mobile during a break and returns later, on a different device, once they've had time to think it over. A store that loses the cart in that gap isn't just creating minor friction; it's actively working against exactly the purchase behaviour a considered-purchase catalogue should expect and plan for.

How Laravel Sanctum Ties Identity to the Cart

Laravel Sanctum issues a token when a customer logs in, and the Next.js frontend attaches that token to every authenticated request it makes to the cart API. The cart itself is stored as a database record associated with the customer's account, so every device that authenticates as that customer reads and writes to the exact same cart — there's no separate cart per device to keep in sync, because there's only ever one cart per customer.

This is the same authentication pattern I use across a Next.js and Laravel storefront generally — I've covered the broader architecture in how I connect a Next.js storefront to a Laravel commerce API, and cart persistence is one of the concrete benefits that architecture delivers. The cart itself works exactly as described in how I build a Next.js shopping cart on a Laravel API — persistence is really just what happens when that same cart record is tied to a durable identity instead of a temporary session.

Handling Guest Carts Before Login

Handling guest carts before login means an unauthenticated shopper still gets a persistent cart, identified by a signed, long-lived token stored in their browser rather than tied to an account. This matters because requiring a customer to create an account before they can even build a cart adds friction at exactly the point where you want as little friction as possible — browsing and adding items should never require signing up first.

I generate this guest token the moment someone's cart becomes non-empty, and I sign it server-side so it can't be tampered with — a guest cart is still a server-side record, just associated with an anonymous token instead of a customer ID.

The signing matters more than it might seem. Without server-side signing, a guest identifier is just a value the client can read and modify — nothing stops a browser from sending a different guest token and reading someone else's anonymous cart. Signing the token server-side means only the Laravel API can issue a valid one, and any tampered or forged token is rejected outright, keeping guest carts as genuinely private as authenticated ones.

Merging a Guest Cart into an Authenticated One

Merging a guest cart into an authenticated one happens the moment a guest logs in or creates an account partway through shopping — their guest cart's contents are combined into their account's persistent cart, rather than the guest cart simply being discarded in favour of whatever the account's cart already contained. Losing a customer's in-progress cart at the exact moment they decide to trust you with an account is a self-inflicted problem, and it's one I specifically design against.

1. A guest browses and adds items, building a cart tied to their anonymous, signed token.
2. The guest logs in or registers an account partway through their session.
3. The API merges the guest cart's contents into the customer's existing authenticated cart.
4. Duplicate or identical configurations merge into a single line, following the same configuration-fingerprint logic used throughout the cart.
5. The guest token is retired once the merge completes, since the cart now lives entirely under the authenticated identity.

What Happens Across Tabs and Sessions

Across tabs and sessions, every authenticated request reads the current state of the cart from the Laravel API rather than trusting a locally cached copy, so a change made in one tab is reflected the next time any other tab requests the cart. If a customer opens the same account in two tabs and adds an item in one, the cart shown in the other tab updates the next time it's read — there's no separate, disconnected state per tab that can drift apart, because both tabs are asking the same server for the same underlying record.

Session expiry is handled the same way. If a Sanctum token expires or is revoked, the customer's cart data isn't lost — it's still sitting on the server, tied to their account, waiting for them to log back in. Signing out never deletes a cart; it just stops that specific token from being able to read or modify it until the customer authenticates again.

This also means a security-related token revocation — a customer changing their password after a suspected compromise, for instance — doesn't have the side effect of wiping out a cart they'd carefully built. Security and cart persistence are handled as genuinely separate concerns: revoking access is about who can act on the account right now, not about deleting the data the account has accumulated.

What This Means for Cross-Device Shopping

Cross-device shopping — starting on a phone, continuing on a tablet, finishing on a laptop — works naturally once the cart lives on the server tied to identity rather than to any one browser. There's no special cross-device sync logic to build separately, because the architecture already treats "which device is asking" as irrelevant to "whose cart this is." Every device is just another client authenticating as the same customer and reading the same record.

Frequently Asked Questions

What happens to my cart if I log out and log back in later?

Nothing is lost. Your cart is stored on the server tied to your account, not to your browser session, so logging out simply stops that session from accessing it — logging back in gives you access to the exact same cart again.

Do I need an account just to start adding items to my cart?

No. Guest shoppers get a persistent cart identified by a signed anonymous token, so you can browse and add items freely before deciding whether to create an account.

What happens to my guest cart if I create an account partway through shopping?

It merges into your new account's cart automatically. Nothing you added as a guest is discarded — the guest and authenticated cart contents are combined into one.

Will my cart look different if I switch from my phone to my laptop?

No. Both devices authenticate as the same customer and read from the same server-side cart record, so the contents are identical regardless of which device you're using.

What happens if I have the same account open in two browser tabs at once?

Both tabs read the cart from the same server-side record, so a change made in one tab is reflected in the other the next time that tab requests the current cart state.

If your current storefront loses a customer's cart between visits or devices, I can help you build a persistent cart architecture that actually holds up.

Ready to talk through your storefront's cart and authentication requirements?