Why it isn't converting

Why do customers abandon checkout: late costs

Shoppers add the item, reach checkout, and leave before paying. Mimiq sends simulated shoppers through the same steps as guests, up to the payment screen, and shows where each one stopped.

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

Why do customers abandon checkout?

Shoppers who leave checkout are usually reacting to something new on the step they are on: a shipping or tax line that was not on the cart, an address form that rejects a valid address, or a required account. The step where the drop starts is usually the step where that surprise first appears. Check the step names and drop counts, then the totals at each step. Mimiq sends a simulated shopper through the same steps as a guest, up to the payment screen, and reports where they stopped and why.

What this looks like in a report

Who
Ivo, who wants one shirt for a wedding and has never bought from this store
How they arrived
Clicked a shirt in a shopping ad
Where they stopped
Shipping step, after the address form

“The cart showed a fair price, and now the total has a shipping line I did not see. My unit number was rejected twice, and it wants a login. I am out.”

The fix. Show the shipping estimate on the cart page for the country selected. Accept any value in the address line 2 field without validation, and put Continue as guest above the login prompt.

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

The total rises at a step the shopper did not expect

Checkout is a chain of small decisions, and each step can end it. A shopper who saw one price on the cart page is making a comparison when a shipping line appears on the next step. A form that rejects a valid address shows an error only after the shopper presses Continue, so they retype the address and feel they are doing something wrong. A required account adds a step that asks for a password before the shopper can see the total. Each of these is small. Together they end visits at the same few steps, and the step name in your checkout report is where to look first.

  • Step names and drop counts: which step loses the most people between the cart and the payment screen?
  • Totals: does the cart total match the payment screen total, with shipping and tax included?
  • Address fields: is a unit number or a postal code from another region rejected on submit?
  • Guest checkout: is there a clear guest option, or does the form ask for an account first?
  • Coupon field: does applying a code send the shopper to a page with no way back?

Find the step where the cost first appears

Checkout reports count each step, so start there, but read the totals as well. Pull the cart total from the cart page, then the total on the first screen of checkout, then the total on the shipping step and the payment screen. If the number changes between the cart and the first checkout screen, a shipping or tax line appeared that the shopper did not see before. A drop at that exact step is the first suspect. Do not start by rewriting the payment form. Shoppers who leave earlier never reach it, so the form is not where most of the loss happens. The cost line is the thing to read first.

Address forms that reject a real address

An address form is a set of rules, and some of them were written for a single country. A required region list with no option for a shopper's area, a postal code pattern that rejects codes from elsewhere, or a second address line that refuses a unit number will all show an error. The error often appears only after the shopper presses Continue, so the form looks finished until the moment it fails. The shopper then retypes the address and starts to doubt the order. Enter your own address with a unit number and one foreign postal code, and press Continue each time. Every error that appears is one a real shopper can meet.

The login wall and the wallet that is missing

A required account asks a new shopper for a password before they can see the total, so many of them leave at that door. A payment option missing on their device has the same effect: a shopper who expects a fast wallet and finds only a card form may stop. Check the checkout from a new browser with no saved details, on a phone and on a laptop, and list the payment options each one shows. Look for a guest option that is easy to find, not one tucked under a login prompt. A simulated shopper stops at the payment screen, because card entry needs a real card, and the report says so.

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 can add a cost line back into checkout

Shipping rules, tax settings, discount rules and payment methods change often, and each change can move a cost onto a later step. Rerun the simulated shopper to the payment screen after every change to shipping, tax, discounts or accounts. The cart page can look right while the payment screen does not. Test a second address in a different region, and a guest with a unit number, since a rule that works for one address can fail for another.

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

Is the payment step where most shoppers leave?

The payment screen is the last thing a shopper sees, after the total, the address and the account question have been settled, so a drop there can hide a problem from an earlier step. Check the step counts before you assume the card form is the problem. A simulated test goes up to the payment screen and shows the path to it, but it cannot finish the card entry.

Can a simulated shopper pay with a real card?

No. Visitors cannot pay with a real card, and the test stops at the payment screen. Anything after that, including a declined card, a bank check and the confirmation page, needs a checkout you run yourself in your payment provider's test mode.

Does a test show how many shoppers will abandon?

No. It does not predict the abandonment rate on your store, and it does not forecast how many shoppers will leave at each step. It shows where a simulated shopper stopped, what the total and the form looked like there, and what they were thinking. Use your checkout analytics for the rate.

Should I offer free shipping to reduce abandonment?

That is a pricing decision, and a test cannot tell you what it will do to your margin or your sales. It can tell you whether a shipping cost appears where a shopper expects it. Show the cost early, then decide whether the offer is worth making.

Why does the test check out as a guest?

A new shopper who has never bought from you usually checks out as a guest, if your store allows it, and the test follows that path. If your store makes shoppers log in before paying, say so in the task, and the visitor will follow the account step instead.

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 .