Stall library · Buy
AI agent could not reach the payment step
An unreachable payment step means an AI agent got as far as your checkout and never found a payment form, so no purchase could be attempted. This is the terminal case of the buy stage: the agent chose your product, added it, and reached checkout, and everything up to that point worked. The sale was lost at the last screen.
Why the agent stops
Checkouts commonly build the payment step from scripts after several conditions are satisfied: a shipping method chosen, an address validated, a third party frame loaded. Any one of those that an agent cannot satisfy leaves a checkout that renders but never offers a way to pay.
Because the page loads without error, nothing in your monitoring registers a failure. From the store side this looks like an abandoned checkout, which is a category that is easy to attribute to shopper hesitation rather than to a step that was never rendered.
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
- Add a product to the cart and open the checkout in a browser with JavaScript disabled. Note what renders and what does not.
- With scripts enabled, work through the checkout using only the keyboard. Anything that cannot be reached by keyboard is likely unreachable to an agent.
- Note whether a payment field appears before any address validation or shipping selection completes.
- Check whether a third party payment frame is required for the form to exist at all.
What to change
- Render a payment step that does not depend on scripts an agent cannot run.
- Do not gate the appearance of the payment form on optional steps such as marketing consent or account creation.
- Make every checkout control reachable and operable by keyboard.
- Test the checkout with a plain automated browser and no extensions, which is much closer to what an agent drives than your own browser is.
What Ottom looks at
Ottom drives the journey through open product, choose an option, add to cart, open cart and start checkout, and raises this finding when the checkout renders but no payment field is found. Ottom never submits payment: the run stops at reaching the payment step, which is the measurement, not the transaction.
Questions
Does Ottom actually try to pay?
No. The journey ends at reaching the payment step. Reaching it is the thing being measured, and completing a real transaction against a live store would be a cost imposed on a merchant rather than a measurement of one.
Can a checkout hosted by my platform still block agents?
Yes. Hosted checkouts are configurable, and apps, custom fields and risk rules are all inserted into them. The finding names where the journey stopped so you can see which part of the configuration is responsible.