A shopping cart should answer three questions before checkout: What am I buying? What does it cost so far? What happens next? Show each product and quantity, explain every automatic discount, label the subtotal accurately, and say when shipping and tax will be determined. Give shoppers clear ways to correct the selection, but verify those behaviors in the actual store rather than assuming how they work. On mobile, keep the checkout action easy to find without covering totals, errors, or item controls.
The cart is a decision surface, not a receipt. It supports inspection and revision before checkout.
Make every product line verifiable
Each line should let the shopper recognize the intended product without returning to its page. Review the image, specific title, quantity, price, and line total where shown. Use the same identity and price language as the rest of the storefront.
Test similar products together. If two mugs differ only by capacity, their catalog identity and cart lines must preserve that distinction. Define any launch-specific product relationships during onboarding, then test every intended selection as a real cart line before publication.
The image should aid recognition, not take over a small screen. Long names must wrap without colliding with prices or controls. If a product becomes unavailable, verify the live behavior instead of inventing a reservation message.
Put quantity and subtotal in a clear relationship
A shopper must be able to distinguish a unit price, line total, and cart subtotal. Avoid two unlabeled figures beside one product.
If quantity can be changed, test minimum and maximum input, the controls present, slow updates, repeated taps, and recalculated amounts. Confirm that the display cannot remain contradictory. Otherwise, provide only the verified route instead of drawing a control that cannot work.
Place the subtotal after the product lines and label it Subtotal, not Total, when shipping, tax, or other charges remain undecided. Recalculate it from the catalog and promotion rules; never use a manually composed number in a visual mockup as evidence that the commerce calculation works.
Explain automatic discounts where they change the price
Setka applies configured promotion rules across eligible products, categories, baskets, and shipping. Reveal an eligible offer when it changes a line, shipping charge, or subtotal. Shoppers should not have to reverse-engineer different totals.
A truthful treatment identifies the benefit, shows the amount accurately, and does not imply a countdown, combination, or rule that is not part of the campaign. Test below, at, and above any threshold. Remove an eligible product and confirm that discount and subtotal update together.
Promotion economics and eligibility belong in the guide to discounts without damaging margins. Use the exact campaign rule configured for the store in cart copy and tests.
Set shipping and tax expectations without false precision
Before checkout has the information required by the store’s rules, the cart may not be able to present a final shipping or tax amount. Say so plainly. Useful wording names the next decision, for example: “Shipping is calculated from your delivery details at checkout” or “Tax is confirmed at checkout,” but only when that wording matches the configured behavior.
Do not show a guessed cost, tax figure, delivery promise, or “free shipping” message unless active rules support it. Configure shipping and product-type tax treatment in Setka, use the shipping zones and delivery rates guide, then compare the cart expectation with checkout.
The subtotal area can use a compact sequence:
Items subtotal €84.00
Automatic promotion −€10.00
Subtotal €74.00
Shipping and tax Confirmed at checkoutThis is an information model. Verify labels, currency formatting, and layout in the store.
Treat edit and remove as behaviors, not decorations
An edit succeeds only when the change persists, amounts recalculate, feedback appears, and checkout uses the revision. Remove must target the intended line, handle the last item, and leave an understandable state. Whether it is immediate, reversible, or confirmed is behavior to test.
Run each action with one and several items. Tap twice during a slow update. Revisit the cart if persistence is expected. Check focus or viewport placement, especially on mobile. Do not promise save for later, quick add, stock reservation, or recommendations.
Use an empty cart to restore direction
An empty cart should say there are no products and provide a clear route back to shopping. Test where “Continue shopping” leads. Remove stale prices, promotion messages, and checkout actions.
Test both an initially empty cart and one emptied by removal. Do not add personalized recommendations merely to fill the space.
Cart-state matrix
Use this matrix with representative products and the store’s real rules. Record unsupported states as N/A with a reason, not as an automatic pass.
| State | What the shopper must understand | Action to test | Pass evidence |
|---|---|---|---|
| One product | Identity, quantity, price meaning, subtotal | Open cart and continue | Product data matches catalog and checkout |
| Several products | Which amount belongs to which line | Review each line | Lines remain distinct; subtotal recomputes correctly |
| Quantity change | New quantity and resulting price | Use every supported quantity method | One update persists; all affected amounts agree |
| Automatic discount eligible | Why the price fell and by how much | Meet the configured rule | Discount appears truthfully in cart and checkout |
| Automatic discount lost | Why the benefit disappeared | Remove or reduce an eligible item | Discount and subtotal update together |
| Remove one line | Which product will leave | Use the supported remove action | Correct line leaves; remaining amounts are correct |
| Remove last line | That the cart is empty | Remove the only product | Empty message and route back replace checkout |
| Invalid quantity or stale data | What failed and how to recover | Trigger a safe supported failure | Message is near the problem; no false total remains |
| Slow or failed update | Whether the action is pending or failed | Constrain connection and retry | Duplicate changes are prevented; recovery is clear |
| Shipping/tax undecided | Why subtotal is not final | Continue with test details | Cart wording agrees with checkout calculation |
| Narrow mobile | What is selected and how to proceed | Review, edit, and continue by touch | No overlap, hidden error, or covered action |
Annotated mobile cart example
The following wireframe is Markdown-safe planning material, not a product screenshot or a promise of exact controls.
┌────────────────────────────────┐
│ Cart (2 items) │ 1 State is named
├────────────────────────────────┤
│ [image] Column lamp │ 2 Product remains identifiable
│ Qty 2 │ 3 Verify supported edit behavior
│ €32.00 each €64.00 │ 4 Unit and line price are labeled
│ Remove │ 5 Verify target and result
├────────────────────────────────┤
│ Automatic promotion −€10.00 │ 6 Explain a real applied rule
│ Subtotal €54.00 │ 7 Do not call this the final total
│ Shipping and tax at checkout │ 8 No invented estimate
│ │
│ [ Continue to checkout ] │ 9 Visible; covers no content
└────────────────────────────────┘On a real phone, scroll from the first product to checkout and back. Enlarge text, use the longest name, trigger an error, and open the keyboard if relevant. A sticky action fails if it hides a product, message, subtotal, or control. The mobile ecommerce UX checklist covers the full path.
Validate errors before sending shoppers onward
Cart errors should preserve trustworthy information, identify the affected line or rule, and give a recovery step. “Something went wrong” is insufficient when quantity or subtotal may be stale.
Test safe reproducible failures: an invalid supported quantity, interrupted update, or controlled rule change. Observe actual behavior before writing final error copy. Never use customer data for QA.
Then continue to checkout. Payment activation belongs in the Stripe setup guide; this cart guide stops at the handoff. After a successful payment creates a paid Setka order, follow the first-order runbook for fulfilment.
Generate the cart as part of the storefront
Setka generates the cart with the homepage, category, product, navigation, and mobile surfaces. It connects to product, promotion, shipping, tax, checkout, and order context instead of becoming a separate theme-code project. A merchant can preview, direct a refinement, and publish after review without maintaining separate theme code.
That gives a small brand one storefront and commerce system under one design direction. The merchant still confirms product facts, rules, amounts, supported states, mobile behavior, and the cart-to-checkout handoff.
Your next step is to test every supported cart state in the Setka preview with representative products and real configured rules. Record the expected result, observed result, device, and evidence. Refine any unclear surface, then rerun the complete cart-to-checkout handoff before publishing.