Before you launch or pay for traffic

Shopping cart ecommerce best practices: the cart

Your cart page is the only place a shopper checks what they picked against what they are about to pay for. A shopper on a phone changes a size, a quantity or a coupon, and the page is where that choice can quietly go wrong.

5 visitors try to .
First test free with an accountRun it from your coding agent

What makes a shopping cart page keep the buyers who reach it?

Each cart line shows the size, color and quantity exactly as the shopper chose them, with a total that updates in place when the quantity changes. The Checkout button stays visible on a phone, larger than the link that goes back to shopping, and a coupon box does not push it off the screen. The header count matches the cart on every page. A simulated visitor shows the cart line it saw, the button it could reach and the step where it left, with a screenshot, so you can see which of these failed.

What this looks like in a report

Who
Jomo, buying a second pair of running socks for his brother
How they arrived
Tapped a product link a friend sent him, on his phone
Where they stopped
Cart page, after changing the quantity to two

“I picked a large and two pairs. The cart shows one pair in a medium, and the total did not change, so I cannot tell whether the second pair is in there. I will start again on my laptop.”

The fix. Keep the chosen size, color and quantity on each cart line, and recalculate the line total in the same step as the change. Test the cart on a phone by choosing a size, changing the quantity, and comparing the line with the product page.

An illustration. Run a test to see your own.See a real sample report

The cart line disagrees with the product page the shopper just left

A shopper picks a size, a color and two units, then the cart summarizes the line with the product name alone. The size reverts to the first option, the quantity resets to one, or the price shows the list price while the product page showed a sale. The shopper checks the line, sees the mismatch and wonders whether the store will ship what they picked. Owners rarely see this, because they test with the one variant they already know works, on a laptop. A shopper on a phone sees the whole mismatch at once.

  • Each line shows the chosen size, color and quantity as the product page showed them.
  • Changing the quantity updates the line total at once, without a reload that resets it.
  • The Checkout button sits above the fold on a phone, and it is larger than Continue shopping.
  • Opening a coupon box does not push the Checkout button out of view.
  • The item count in the header matches the number of items on the cart page.

Compare each cart line with the product page it came from

The wrong version is a cart line that shows only the product name. A shopper who picked two sizes cannot tell which line is which, and the cart gives them no way to check. The right version repeats the size, color and quantity as plain text on each line, with a small image of the chosen color, so the line matches the page the shopper just left. To check it, add two variants of one product, choose the second size, and read each cart line against the product page. A fault shows up as a line that names a size you did not pick.

Quantity and coupon changes that move the button off the screen

On a phone, a coupon box that opens into a long field can push the Checkout button below the keyboard, and the shopper has to scroll back past a list they just edited. Quantity fields cause the same trouble when the total only refreshes after a full page load, because the shopper changes a number, sees no change and taps again. The wrong version keeps the total in place until a reload. The right version recalculates in place and keeps Checkout within reach of a thumb, close to the total. In a simulated run, the screenshot of the cart step shows whether the button is off the screen after the coupon box opened, which points at the layout.

Keep the cart when the shopper signs in

A guest cart is often stored only in the browser, and a sign-in can start a new, empty account cart. The shopper who added two items, then signed in to check out, sees an empty cart and assumes the items were lost. The right version merges the guest cart into the account cart at sign-in, and keeps the items if the shopper signs out and back in. Simulated visitors cannot sign in with Google or single sign on, so check this path yourself with a regular account. With paid credits, you can give a visitor a test account, and the report then shows whether the items were still there after the login.

What you get with Mimiq

  1. 01

    Run it by hand, or on every pull request

    Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.

  2. 02

    Bugs and usability problems in one report

    The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.

  3. 03

    Visitors that behave like your audience

    Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.

  4. 04

    A prompt to fix each problem

    Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.

  5. 05

    Follow every visitor

    See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.

The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.

A new bundle rule can change a cart line after the shopper agrees to it

A store adds a bundle discount, a gift wrap option or a size chart, and the cart line changes its wording or total after the shopper has already picked. Rerun the same visitors through the product page and the cart after each change, choosing a variant and a quantity each time. With paid credits, a test account can reach a cart behind a login, and each preview deploy can be checked before it goes live.

Starter

Try it on one launch

$9 once
120 credits, never expire

About 4 tests of 5 visitors

  • Visitors on your landing page, signup and checkout
  • Where they left and why, with a fix to copy for each problem
  • Run it in the app or on every pull request
  • Ask any visitor a question, included
  • Test accounts and protected previews
Buy 120 credits

Builder

Test every build

$19 a month
500 credits every month

About 20 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Builder

Pro

Test every release, as a team

$49 a month
1,500 credits every month

About 60 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Pro

Scale

Test at scale, every day

$149 a month
6,000 credits every month

About 240 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Priority support
  • Cancel anytime
Choose Scale
$0for your first test, with a free account (Google sign-in, no card). It includes 50 credits, enough for 10 visitors. After that a visitor uses 5 credits, and packs start at $9 for 120 credits.
See a sample report

Questions

Should the cart page show shipping before checkout?

Show an estimate, or say that shipping is added at checkout, before the shopper taps Checkout. A shopper who learns the shipping cost on the next screen often leaves, and the cart page is the last place they expect a surprise. The test shows whether a visitor saw a shipping line on the cart step, but not whether the amount is right.

Is a side cart better than a full cart page?

Neither is better by itself. A side cart keeps the shopper on the product page, but on a phone it can cover the page, and the buttons under it get missed. A full cart page makes the choice easier to read. Pick one, and make sure the header count matches it on every page.

Can a simulated visitor tell me how many shoppers will reach checkout?

No. It does not predict how many shoppers will go on from the cart, and it gives no rate. It shows where each simulated visitor stopped on the cart step, with a screenshot, and whether the line matched what the visitor picked. Rates come from your analytics on real traffic.

Do I need to test every product in the cart?

Start with the products that have options, since a size or color choice is where cart lines go wrong. A product with no options is less likely to fail on the cart step. Test one product with a discount too, because a discount changes the line total in a way the shopper can check.

Keep reading

Send visitors and see what breaks first.

Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.

5 visitors try to .