Learn / Platforms
Custom checkouts and AI agents
Every step in a custom checkout was added deliberately by somebody, which makes it the place where agent purchases most often end. The failures are not exotic: required account creation, fields that appear at the last step, custom controls that are not real form elements, and state kept client side across a redirect that an in-app browser does not preserve.
A custom checkout is a set of decisions somebody made rather than a default somebody accepted, and every one of those decisions was made with a human shopper in mind. That is why it is the place agent purchases most often end.
The four that account for most failures
- State kept client side across a redirect. An in-app browser may restrict storage, so the return leg loses the cart. This produces an error rather than an obstacle and reads as a broken store. See checkout error.
- Required account creation. An agent has no inbox to confirm from and will not register. See how to offer guest checkout for agents.
- Custom controls that are not form elements. A styled div acting as a radio button is not selectable by anything that did not run your scripts.
- Fields that appear only at the last step. A phone number suddenly required, a box that must be actively unchecked, a terms control with no accessible label.
Deviation is the risk, not customisation
The useful frame is not that custom is bad. It is that a platform checkout has been exercised against a far wider range of clients than yours has, so each deviation is a small untested surface. Listing your deviations from a standard flow is usually a faster route to the defect than testing blindly.
Test it the way it will be met
Cold session, signed out, narrow mobile viewport, ideally inside an actual in-app browser. Add a product that requires a variant choice, proceed, and stop at the payment step.
Note every point where you supplied something an agent could not: dismissed an overlay, accepted a banner, chose a region, created an account, solved a challenge. That list is your work.
Put it in the pipeline
A custom checkout changes more often than a platform one, so this belongs with every checkout and payment change rather than on a calendar. See how to test checkout in an in-app browser.
Questions
Is a custom checkout worse for agents than a platform one?
Usually, not because custom is bad but because every deviation was a decision made for human shoppers. A platform checkout has been tested against a much wider range of clients than yours has.
What breaks most often?
State lost across a redirect, because it produces an error rather than an obstacle and looks like a broken store. Then required account creation, then custom controls that are not real form elements.
How far should an agent be able to get?
To the payment step, with a real product in the cart, from a cold session, without a human intervening. Stopping there is correct: there is no reason to submit a payment to test a checkout.