Stall library · Buy
Checkout returned an error to the AI agent
A checkout error is a checkout that produces an error page instead of a payment step, so no purchase can be attempted. This one is worth reading differently from the rest of the taxonomy: a checkout that errors for an ordinary automated request is usually erroring for some humans too, and the agent has simply found it first.
Why the agent stops
Checkout errors cluster around conditions your own testing rarely reproduces: an empty or unusual session, a cart built by a direct request rather than through the interface, a missing optional field, a third party service that timed out.
Agents hit those conditions constantly, because an agent journey is a plain path through the store with no cookies, no history and no tolerance for a retry that a person would perform without noticing.
How often we see this
Not stated here. A frequency means nothing without the cohort it was counted over, and this page is about one stall rather than one category. Where a category has enough stores measured at every stage, the share of them showing this stall is published on its benchmark page, with the methodology beside it.
See it for yourself
- Build a cart in a private window and start the checkout. Note the exact error text.
- Repeat with a second product, and with two items in the cart.
- Check your server logs and error tracker for the same timestamps. This stall almost always has a matching server side exception.
- Try from a different network and a different country if you serve more than one market.
What to change
- Investigate the underlying error. It is failing for ordinary requests, not only for agents.
- Check third party checkout apps first. An app that fails open is invisible; one that fails closed produces exactly this.
- Make sure error states return a usable page rather than a generic failure, so the cause is visible in monitoring.
- Re test after any checkout app install or theme update.
What Ottom looks at
Ottom raises this finding when the checkout page carries error language and offers no payment field. The evidence capture records the page, which is usually enough for a developer to match it against a server side exception.
Questions
Could Ottom’s agent have caused the checkout error?
It is a plain browser following a plain path, so everything it did is available to any shopper with a mouse. It does not send unusual headers, replay requests or submit values a form did not offer. If a normal sequence of clicks produces an error, that is a fact about the checkout rather than a fact about the agent, and the evidence in the report shows the page it was on when the error appeared so you can follow the same path yourself.
Why is an intermittent checkout error rated critical?
Because when it occurs, no purchase is possible at all. Severity here describes how completely a failure blocks a sale, not how many sales it touches. Intermittency changes the second and not the first, and an intermittent checkout error is still a checkout error for everybody who meets it. It is also the class of fault least likely to be reported by a customer, because somebody who cannot pay usually leaves rather than emailing.