VMware ESXi and vSphere Cluster Management

Shopping Cart Fundamentals

Learn how shopping carts work, including cart data models, calculations, persistence, validation, checkout handoff, security, accessibility, and responsive design.

A shopping cart is a temporary collection of products a customer intends to purchase. It sits between product browsing and checkout: the customer selects products, adds them to the cart, reviews the selection, and then begins the process of completing a purchase.

What a Shopping Cart Does

A cart supports several related tasks:

  • Product selection: Customers collect products without immediately creating an order.
  • Quantity management: Customers increase, decrease, or remove selected quantities.
  • Pricing visibility: The cart shows unit prices, line totals, discounts, taxes, shipping estimates, and the amount currently expected at checkout.
  • Checkout preparation: The application validates the cart before collecting delivery and payment information.

Browsing a product is not the same as adding it. Adding creates or updates cart data. Reviewing the cart lets the customer correct quantities, options, and promotions. Checkout turns a validated cart into an order after fulfillment and payment details are collected.

Core Cart Data Model

A cart normally has an identifier, an owner or session association, one or more line items, calculation data, and lifecycle metadata. A cart line item represents one purchasable product or product variant and its selected quantity.

Field | Purpose | Example value | Validation considerations Cart identifier | Identifies the cart record | cart_8f31 | Must be unique and difficult to guess Owner or customer identifier | Associates a cart with a signed-in customer | customer_204 | Check authorization on every access Guest session identifier | Associates a guest cart with a secure browser session | session_91ab | Use secure, expiring session handling Product identifier | Identifies the catalog product | product_shirt_12 | Resolve it against the current catalog Product variant identifier or SKU | Identifies the exact purchasable option | shirt_blue_medium | Required when size, color, or configuration changes inventory Quantity | Number of units requested | 2 | Must be an integer within product limits Unit price | Current authorized price for one unit | 24.99 USD | Retrieve from trusted server-side data Discount data | Applied promotion or price reduction | 10% promo | Revalidate eligibility and expiration Tax estimate | Estimated tax for the current context | 4.20 USD | May change after address collection Shipping estimate | Estimated delivery charge | 6.00 USD | Recalculate when destination or method changes Currency | Currency used for monetary values | USD | Do not mix currencies in one cart unless explicitly supported Availability metadata | Stock or purchasability state | in_stock | Recheck when adding, updating, and checking out Session metadata | Creation, update, expiration, and recovery information | updated_at | Define expiration and cleanup rules

A product variant is a specific purchasable version of a product, such as a blue, medium shirt. A SKU, or stock-keeping identifier, distinguishes inventory items or variants. Store identifiers and quantities as authoritative inputs; do not depend only on a displayed product name or image.

Essential Cart Operations

Operation | Input | Successful result | Common failure cases Add an item | Product or variant identifier and quantity | Creates a line or increases an equivalent line quantity | Invalid variant, unavailable stock, quantity limit, expired session Update quantity | Line identifier and new quantity | Recalculates line and cart totals | Non-integer quantity, insufficient stock, unauthorized line Remove an item | Line identifier | Deletes the selected line | Stale line identifier, unauthorized access Clear the cart | Cart identifier or authenticated customer identity | Removes all eligible lines | Unauthorized request, concurrent update Merge duplicate items | Equivalent product variant and quantities | Combines quantities when options match | Different options, maximum quantity, stock limit Persist the cart | Cart reference and stored cart data | Restores contents later | Expired session, deleted product, failed storage lookup

Two additions can become one line when they refer to the same SKU and have the same options. Distinct sizes, colors, configurations, seller identities, or fulfillment rules generally require separate lines.

Calculating Cart Totals

The line total is usually the unit price multiplied by the selected quantity, after any line-level adjustment. The merchandise subtotal is the sum of line totals before shipping, taxes, and other cart-level adjustments. A discount is a reduction produced by a promotion, coupon, or pricing rule. A promo code is a customer-entered code that may activate such a promotion.

Calculation component | Formula or source | Example | Notes Line subtotal | Authorized unit price × quantity | 24.99 × 2 = 49.98 USD | Recalculate on every trusted server request Merchandise subtotal | Sum of eligible line subtotals | 49.98 + 15.00 = 64.98 USD | Excludes shipping and tax Discount | Promotion rule applied to eligible items or subtotal | 10% of 64.98 = 6.50 USD | Define eligibility, caps, and rounding Tax estimate | Tax service or configured jurisdiction rules | 5.85 USD | Often depends on address and product tax class Shipping estimate | Delivery method and destination rules | 6.00 USD | May be unknown until checkout Grand total | Subtotal − discounts + tax + shipping | 64.98 − 6.50 + 5.85 + 6.00 = 70.33 USD | Label as estimated when inputs are incomplete

Use decimal-safe money handling rather than binary floating-point arithmetic for authoritative totals. Store a currency code with every monetary calculation, apply one documented rounding policy, and format values consistently for the customer. For example, if a percentage discount produces a fraction of a cent, the system must define whether rounding occurs per line or after the discount is summed.

Inventory and Pricing Validation

The server must treat catalog prices, promotions, and inventory as authoritative. The browser may display a price and submit a product identifier and requested quantity, but it must not be trusted for unit prices, discounts, tax, shipping, or grand totals.

  • Check stock and purchase limits when an item is added.
  • Check them again when quantity changes.
  • Perform final inventory validation during checkout because another customer may purchase the remaining stock.
  • Detect price changes and show the new authorized price before order submission.
  • Flag discontinued products and unavailable variants instead of silently charging for them.
  • Recalculate promotions, taxes, shipping, and totals whenever relevant inputs change.

Depending on the business, checkout may reserve inventory for a limited period or validate stock immediately before order creation. Either way, the order must not be created from stale cart assumptions.

Guest and Customer Carts

A guest cart exists before a customer signs in. It can use a secure server-side session reference, a browser cookie that identifies server-stored data, or carefully designed browser storage. Server-side storage is usually easier to validate and synchronize across devices; client-side storage requires additional protection and cannot make client-provided prices authoritative.

After sign-in, associate the guest cart with the authenticated customer account. If that customer already has a saved cart, define a cart merge policy before implementation.

Condition | Recommended behavior | Customer-facing message Only a guest cart exists | Attach it to the authenticated account | Your cart is now saved to your account. Only an account cart exists | Keep the account cart | Your saved cart is ready. Both carts contain different eligible items | Combine the lines and recalculate totals | We combined your saved items with this cart. Both carts contain the same variant | Add quantities, subject to stock and purchase limits | We combined duplicate items and updated the quantity. A combined quantity exceeds stock | Use the available quantity or require customer resolution | Quantity was adjusted because fewer units are available. A line is discontinued or unavailable | Keep it flagged for removal or replacement; do not purchase it | This item is no longer available and must be removed. Merge is ambiguous or unsafe | Ask the customer to choose which line to keep | Review these items before continuing.

Cart expiration should be intentional. Expiration can remove abandoned server records, release reservations, and prevent obsolete prices or promotions from being treated as current. A recovery feature may restore a cart reference, but it must still revalidate product, price, and inventory data.

Cart User Experience

Each cart line should make the selected purchase understandable at a glance. Show the product image, product name, selected variant or options, unit price, quantity control, line total, and a removal action.

  • Give immediate feedback after adding an item, such as an updated cart count and a clear confirmation message.
  • Make subtotal, discounts, shipping estimate, tax estimate, and grand total easy to find.
  • Keep the primary checkout action visually prominent without hiding important conditions.
  • Provide an informative empty-cart state with a clear path back to product browsing.
  • Show unavailable, price-changed, or quantity-adjusted lines with an explanation and an action to resolve them.
  • If saved-for-later items are supported, keep them distinct from purchasable cart lines and explain whether they remain reserved.
  • Keep wish-list behavior separate unless the product explicitly supports moving items between a wish list and cart.

Checkout Handoff

Checkout begins when the customer proceeds from the cart to provide fulfillment and payment details. The handoff should carry a cart reference, not a trusted client-calculated total.

  1. Load the cart using the authenticated identity or secure session.
  2. Revalidate product status, variants, quantities, inventory, prices, promotions, currency, and applicable limits.
  3. Collect destination and delivery information needed for final tax and shipping calculation.
  4. Present updated totals and require the customer to resolve blocking errors.
  5. Create an order from the validated cart and record the calculation inputs and results.
  6. Begin payment processing using a payment provider token or reference, without storing sensitive payment information in the cart.

Repeated requests must not create duplicate orders. Use an idempotency key or an equivalent server-side request record for order creation and payment initiation. If payment fails, preserve the cart and its resolved state so the customer can retry. Do not silently empty the cart until the order creation policy confirms that the purchase was successfully accepted.

Security and Reliability

  • Authorize every cart read and update using the customer identity or a secure, scoped guest session.
  • Accept identifiers and requested quantities from the client, then retrieve prices, promotions, tax rules, shipping rules, and inventory on the server.
  • Enforce quantity limits and validate all input types, ranges, and identifiers.
  • Protect session identifiers and use appropriate transport and cookie security settings.
  • Use idempotent handling for repeated add, update, checkout, and payment requests.
  • Handle concurrent updates safely so two requests cannot bypass stock or quantity limits.
  • Do not place card numbers, security codes, or other sensitive payment data in cart records, URLs, logs, or browser storage.
  • Record enough calculation and state history to explain price or stock changes without exposing sensitive data.

Accessibility and Responsive Design

Quantity controls need an accessible label that identifies the product and current quantity. Buttons must be keyboard operable, have clear names, and provide visible focus indicators. Removal actions should identify the affected line rather than using an unlabeled icon.

When a quantity changes, announce the new line total and cart subtotal through an accessible status message. Error messages should explain what changed and how to fix it. Totals must have sufficient contrast, readable text, and a logical reading order.

On mobile screens, stack line-item details and keep quantity controls usable without horizontal scrolling. On tablet and desktop layouts, use columns carefully so the product information, controls, totals, and checkout action remain associated. Test keyboard navigation, zoom, screen readers, narrow widths, and touch targets.

Practical Examples

Adding a Product Variant

A customer selects a blue, medium shirt and adds two units. The cart stores the product variant identifier, such as the SKU for blue-medium, and the quantity 2. It should not rely only on the displayed name “shirt.” The server retrieves the current price and confirms that two units can be purchased.

Updating a Quantity

The customer changes the quantity from one to three. The server validates that three is an allowed integer and that stock is available, then recalculates the line total and merchandise subtotal. The interface reports the updated values.

Applying a Promotion

A valid promo code produces a percentage discount. The cart shows the merchandise subtotal, the promotion and its discount as a separate adjustment, tax and shipping estimates, and the resulting grand total. An invalid or expired code should produce a useful error without changing the cart unexpectedly.

Stock Changes Before Checkout

If a product becomes unavailable after it was added, checkout flags the line, prevents order submission, and updates totals after the customer removes or changes it. The application should not charge for an unavailable variant merely because it was once placed in the cart.

Troubleshooting Common Cart Problems

The Cart Is Empty After Refresh or Browser Restart

Likely causes include storing state only in memory, an expired or blocked session, missing cookie configuration, or failure to restore the cart identifier. Persist a secure cart reference and retrieve server-side data, or implement an intentional persistence strategy for guest carts.

A Customer Can Alter Prices with Browser Tools

This occurs when the server accepts client-submitted unit prices or totals, or when calculations happen only in the browser. Submit product identifiers and quantities, retrieve authoritative data on the server, and calculate all totals there.

The Cart Allows More Units Than Are Available

Stock may be checked only when the product page loads, or another purchase may reduce inventory after the add action. Validate on add and update, then perform final validation or reservation during checkout.

Guest Items Disappear After Sign-In

The authenticated cart may be replacing the guest cart, or the guest reference may be lost during authentication. Preserve the guest cart reference through sign-in and apply a documented merge policy.

Cart and Checkout Totals Differ

Tax, shipping, discount, or rounding rules may differ between services. Share calculation rules where practical, label cart values as estimates when necessary, and show every adjustment separately.

Repeated Clicks Create Duplicate Entries

Repeated submissions can create multiple requests. Disable or debounce the interface action and use idempotency or safe duplicate-line handling on the server.

Exam-Relevant Notes

  • The server, not the browser, is authoritative for prices, discounts, inventory, and totals.
  • A cart line identifies a product variant and quantity; different options may require different lines.
  • Inventory must be checked both during cart operations and again before order creation.
  • Guest-to-account merging requires an explicit policy for duplicates, stock limits, unavailable items, and conflicts.
  • A failed payment should normally preserve cart state for a retry.
  • Idempotency prevents repeated requests from creating duplicate cart effects or orders.
  • A cart is temporary state; an order is the durable result of a validated purchase workflow.

For a working cart flow, begin with a secure cart identity, authoritative line-item data, validated operations, consistent money calculations, intentional persistence, accessible feedback, and a checkout handoff that revalidates everything before creating an order.