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.

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

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

Who
Benedikt, buying a wool throw as a gift for his mother in another city
How they arrived
Came from a shopping ad for wool throws on a laptop
Where they stopped
Delivery step, after entering his mother's address

“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

MethodWhat it showsWhat it misses
Checkout counts in your analyticsHow many sessions reached each checkout stepWhat a shopper saw, and why they left
Recordings of real shoppersWhat a real shopper did on the checkout pageShoppers who never reached checkout
Asking a shopper who leftThe reason, in their own wordsShoppers who left without answering
Simulated visitors through checkoutThe step and the total where a new shopper stopped, with a screenshotWhether 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

  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 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

$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

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.

5 visitors try to .