By platform
Shopify reached checkout but no sales
Your checkout count looks healthy and the paid orders do not match it, so shoppers leave somewhere after the cart. Mimiq sends simulated visitors through checkout and shows the step where they stop.
Why do Shopify shoppers reach checkout and still not buy?
Shoppers who reach checkout have already accepted the cart, so the loss happens on a later step, usually a cost that appears late, an account requirement or a payment method that is missing for them. Compare the count of sessions that reached checkout with the count of paid orders, then find the step where the gap opens. A simulated visitor shows the step it stopped on, with a screenshot.
What this looks like in a report
“The throw looked affordable, and now delivery adds a line I did not expect. I gave the address already, and I will wait to see whether the total drops before I pay.”
The fix. Show the delivery cost on the product page or in the cart for the common destinations, so the delivery step does not change the total. Then run a new-shopper checkout to a different address in a private window and compare the total at delivery with the cart total.
An illustration. Run a test to see your own.See a real sample report
The shopper leaves at the first step that asks for more than they expected
Checkout is a sequence, and each step asks for something new. The contact step asks for an email. The address step asks for personal details, and then the delivery step shows what shipping costs, so the total can jump after the shopper has already committed. The payment step lists the methods the store accepts, and a missing method looks like a broken store to the person who wanted it. A stop caused by a requirement, such as a login, looks the same in your analytics as a stop caused by price. The loss sits between two screens, so the numbers show the gap but not the reason.
- Compare the sessions that reached checkout with the completed orders over the same period.
- Walk the checkout as a new shopper on a phone, with a delivery address in another city, and note the total at each step.
- Look for the first screen where the total changes, since a late cost is a common reason to leave.
- Check which payment options appear for the shopper's country, and whether the option they expect is listed.
The checkout steps, and what each one asks a shopper for
Checkout asks for things in a rough order: contact details, a delivery address, a delivery method, then payment. Depending on how the store is set up, these can sit on one page or several. Each step adds a demand, and each one can lose a shopper for a different reason. A shopper who stops at delivery has usually seen a price they did not expect. A shopper who stops at payment has usually met a method they cannot use. Find which of those two happened before you change anything else in the store.
Late costs and account requirements look like the same drop
A late cost and an account requirement both show up in analytics as sessions that reached checkout and never completed. The screen tells them apart. A late cost shows the total changing after the address or the delivery method is picked, so the shopper meets a higher number at the point of no return. An account requirement shows a sign-in or create-account request before the shopper can continue, and some shoppers will not finish that on a phone. Look at the screen where the number changes, then at the screen that asks for a login.
A missing payment method is the third cause. A store that offers a method only in some countries, or shows an option only on some devices, leaves a shopper who expects that method at the last step. The shopper sees no error, only a payment step without the option they wanted, so they go back to the cart. A complete checkout can still lose the sale this way.
Why a simulated run ends at payment, and what that leaves out
A simulated visitor goes through checkout as a new shopper, fills in the contact and address fields, and goes up to the payment step. The run records the total at each step, the methods shown, any request or script error on that page, and a screenshot of each step. That shows whether the total changes and which methods appear for that address. The run stops at payment, because visitors cannot pay with a real card, so a bank decline or a verification step is outside what it can show.
Ways to find the checkout step where shoppers leave
| Method | What it shows | What it misses |
|---|---|---|
| Checkout counts in your analytics | How many sessions reached each checkout step | What a shopper saw, and why they left |
| Recordings of real shoppers | What a real shopper did on the checkout page | Shoppers who never reached checkout |
| Asking a shopper who left | The reason, in their own words | Shoppers who left without answering |
| Simulated visitors through checkout | The step and the total where a new shopper stopped, with a screenshot | Whether a real shopper would buy, and any bank decline |
Analytics finds the step. A simulated run shows the screen behind it.
Mimiq is independent and not affiliated with the platforms it names. Names belong to their owners.
What you get with Mimiq
- 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.
- 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.
- 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.
- 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.
- 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 shipping rule or checkout app can move the drop to another step
A new shipping rule, a checkout app or a changed account setting can move the drop from one step to the next. Run a new-shopper checkout after each change, on a phone and on a laptop, to a new address. The step that lost shoppers last month can be fixed while a new one opens, so the same test catches both.
Starter
Try it on one launch
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
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Which count should I compare with paid orders?
Use the count of sessions that reached checkout, not every cart visit, since a cart visit can end before anyone enters an address. Compare both counts over the same dates, so the numbers measure the same stage of the sale.
Should I remove the account step to fix this?
Not until you know what the account does for your store. Some stores need accounts for subscriptions or saved addresses, and removing the step can break those flows. Check whether the requirement is set in your checkout settings, and whether any shopper needed it, before you change it.
Can a simulated run show me a bank declining a card?
No. The run stops at payment, so it does not show a bank decline, a verification step or an order confirmation. It shows the total, the methods and any error recorded before that point. It also does not tell you how many shoppers would buy once the total is clear.
How many runs do I need before I trust the step I found?
Enough to see the same step repeat. One run can show a fault in your checkout, but it cannot show how often real shoppers meet it. Run the same new-shopper checkout a few times with different addresses, and compare the steps where it ends.
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.