Saved Cart Concepts — Reasoning & Recommendations

01TL;DR

02What BigCommerce gives us (and doesn't)

BigCommerce's stock Stencil cart template has the standard cart actions — qty edit, remove, edit options — but no native per-item "Save for Later" affordance. The platform's help center has open threads requesting it; the official answer is consistently "use a Wishlist or third-party app."

What Stencil does provide

• Template overrides. templates/components/cart/ partials are fully overridable in a custom theme.
• JS event hooks. stencil-utils exposes cart-item-update and cart-item-remove events plus AJAX helpers like utils.api.cart.getContent().
• REST Storefront Cart API. /api/storefront/carts/{cartId}/items/{itemId} supports DELETE and POST same-origin from theme JS. This is the path a custom Save-for-Later implementation uses to remove a cart line.
• Wishlist API. /v3/wishlists and /v3/wishlists/{id}/items can be the storage layer for the saved-for-later list. Wishlists are tied to logged-in customers and persist indefinitely.

Stencil gives you the plumbing (template overrides + Storefront Cart API + Wishlist API). You build the UX.

What B2B Edition adds

• Shopping Lists — named, shareable, multi-list collections scoped to a Company account. Junior buyers can build a list and submit it to an admin for approval. Closest mental model: a named, reusable order template with org-level permissions.
• Quote Lists / Quotes — request-for-quote workflow. A buyer assembles items, submits for sales-rep pricing.

03The Amazon Save-for-Later pattern

The canonical behavior

• A single saved list renders directly below the active cart on the same page.
• Per-item actions: "Save for later" in the cart row, "Move to cart" in the saved row. Both also have Remove.
• No page reload — both lists update via AJAX.
• Persists across sessions and devices for the logged-in account.
• Distinct from Wish List (longer-term, often shared) and Subscribe & Save (recurring).

Why this is the right starting pattern

• Recognition over recall. Buyers don't have to learn a new affordance.
• Cart-adjacent. The saved list is visible in the moment of purchase decision, not buried in an account page.
• Per-item, not whole-cart. Matches the actual indecision unit: "I want this and this, but I'm not sure about that."
• Storage layer is solved. BC's native Wishlist API supplies the persistence model without any custom infrastructure.

Prototype behavior

The live cart prototype implements this pattern: a saved section sits directly below the active cart, per-row buttons swap the item between sections with a fade transition, the cart badge in the header and the summary totals recalculate live. No page reload.

04How B2B distributors handle it

The B2C Amazon pattern doesn't generalize cleanly to industrial B2B. The pattern there bends toward durable named lists, not session-scoped cart-adjacent SFL.

Grainger

"My Lists" is the primary holding mechanism — named, shared across company users, supports "add entire list to cart." Structurally identical to BC B2B Edition Shopping Lists. They do not surface a separate Amazon-style SFL below the cart; the List is the persistent surface, the Cart is purely transactional.

McMaster-Carr

No surfaced Save-for-Later or wishlist. Their model assumes the cart is ephemeral and search is fast enough that you don't need to "hold" items — re-find them. Their famously fast search is the substitute UX.

HD Supply

Saved order templates similar to Grainger. List-as-persistence, not cart-adjacent SFL.

05Persistent Cart ≠ Save for Later

The BigCommerce app marketplace conflates these. They solve different problems:

BigCommerce's native Persistent Cart is a checkbox in the control panel — items added by a logged-in customer survive logout for N days. That's a store-level setting, not an app, and it does not give you a per-item action. The "Save Your Cart" app is essentially enhanced persistent cart with cross-device link sharing; despite the name, it is not Save-for-Later in the Amazon sense.

Turn on Persistent Cart regardless of the SFL decision. It's free, native, and solves the "don't lose my work" problem at a different layer.

06App shortlist

07Requirements coverage

How the recommended pattern satisfies the brief's hard requirements:

08Phased recommendation

09Implementation notes

Data + APIs (custom build path)

• Storage: a per-customer "Saved for Later" wishlist (auto-created on first save) via POST /v3/wishlists and POST /v3/wishlists/{id}/items.
• Move actions: Save for Later = POST /v3/wishlists/{id}/items + DELETE /api/storefront/carts/{cartId}/items/{itemId}. Move to Cart = reverse. Each is a 2-call AJAX sequence.
• Cart line item metadata: store the cart qty as a custom field on the wishlist item so we can restore it on Move to Cart (otherwise the qty defaults to 1).
• Price at save: wishlist items optionally carry a price_at_save field. Compare to current price on render to show a "Price dropped $X" or "Price went up $Y" chip — the prototype demonstrates the price-drop case.

Optimistic UI

The move action should feel instant: update the DOM first, then fire the AJAX calls in the background. If the API call fails, surface a toast and revert. The prototype's animation timing (220ms fade) is intentionally short — the user sees the row move, but the page never feels "frozen waiting for the server."

Stock + price guards

• On Move to Cart, re-check stock. If out of stock, leave the item in Saved and surface a "Currently unavailable — notify me?" affordance.
• If price changed since save, show the change inline. Don't auto-block the move — let the buyer decide.

Signed-out behavior

Phase 1 is signed-in only. For signed-out users, hide the "Save for Later" action and instead surface a "Sign in to save items for later" inline prompt. Don't try to localStorage-shim it — the cross-device persistence is the whole point, and a guest SFL adds complexity for a B2B audience that's almost always logged in anyway.

Accessibility

• Save / Move buttons should be real <button> elements with descriptive aria-labels ("Save 991-9042 for later").
• The move animation must respect prefers-reduced-motion. Snap-instead-of-fade for that audience.
• Announce the move via an aria-live="polite" region: "Moved to Saved for Later. 2 items now in your cart."
• Both empty states need to be reachable by keyboard, with focus management when the section becomes empty.

Analytics

Track Save / Move events with the SKU and the time between save and move (or save and remove). This is the data that tells us whether SFL is solving real indecision vs. being a dumping ground.

10Sources