Market Insights

What a checkout screen costs, and what the research measures

The checkout abandonment numbers everyone quotes, what they were actually measured on, and which reasons a redesign can move.

VVoqal · Engineering8 min readPart of Business

About this article

The 60 percent in this page’s address was never a measurement. An earlier version of this post told it as our own story, and it was not one: Voqal has not run a retail checkout, and no funnel of ours produced that figure. The URL stays because it is indexed. The claim does not.

What survives is the question underneath, which is a good one. Most people who reach a checkout do not finish it. The numbers describing that are among the most quoted and least read in commerce, so it is worth going through what they were measured on before deciding what to do about them.

The 70 percent number, read properly#

Baymard Institute maintains the figure everyone cites: an average cart abandonment rate of 70.22 percent. The part that usually falls off in the retelling is the method. It is an average across 50 separate studies published between 2006 and 2025. It is not this year’s rate, not your rate, and not a rate measured on any one population.

That matters for how you use it. As a sanity check on your own dashboard it is fine. As a baseline you are supposedly beating, it is meaningless, because the studies behind it span two decades of different sites, categories and definitions of abandonment.

The device gap is better evidenced and more recent. Contentsquare’s 2026 benchmark, drawn from 99 billion sessions across more than 6,000 sites between Q4 2024 and Q4 2025, found desktop converting 74 percent higher than mobile. Both fell year on year. The surface most of your traffic arrives on is the one that converts worst.

Which reasons a design can actually move#

Baymard also asks people why they left. Excluding respondents who were only browsing, the reasons rank like this: extra costs too high at 40 percent, delivery too slow at 20 percent, distrust of the site with card details at 19 percent, forced account creation at 18 percent, and a checkout that was too long or complicated at 17 percent, tied with site errors. Respondents could give several answers, so the column does not total 100.

The highlighted row is the one a checkout redesign owns outright. The three above it are pricing, logistics and trust decisions that sit with other teams.

Read the ranking and the scope of the design problem becomes clear. The top reason is a pricing and shipping-policy decision. The second is a logistics one. The third is a trust signal built over years. Design owns the fourth and fifth, and the fifth is the one this post is about.

Seventeen percent is a minority share of a large problem. It is also the share you can move this quarter without anyone’s approval, which the reasons above it are not.

The form, measured#

Baymard’s benchmark of the flows themselves found that the average 2024 checkout ran 5.1 steps and asked for 11.3 form fields, where its research says most sites need 8. So the average checkout asks for about three more fields than the task requires.

Three surplus fields per checkout. Worth deleting, and not on its own the difference between a 17 percent complaint and none.

Step count is the weaker of the two measures. A five-step flow that asks for eight things is a lighter object than a two-step flow that asks for fifteen, and users experience the asking rather than the screen boundaries. If you are choosing what to instrument, instrument what you request from the user rather than how many routes it spans.

The advice that follows is not new and is still right. Offer guest checkout. Support address autofill and the platform wallets. Never block paste in a card field, which also fails WCAG’s accessible authentication criterion when it happens on a login step. Delete fields you do not act on. All of it is incremental, and all of it leaves a form standing.

Where an agent changes the shape#

An in-app agent is a second path to the same operations, for the subset of tasks a user can state in one sentence. Reordering something they have bought before. Changing a delivery slot. Chasing a refund on a specific order. None of these needs a four-screen wizard, and all of them currently get one.

The mechanics are ordinary. The user says what they want, the agent calls the endpoints your app already calls, and the answer comes back as native UI. The part that matters for money is the last step, where the agent draws a single confirm card and waits. Nothing executes before the user accepts it.

A confirm card listing an amount, a fee, an arrival estimate and a total for an instant settlement, with one confirm button underneath.
One card against the four-screen wizard the post opened with. It carries the same figures a checkout form would collect, and the user reads rather than types them. Sample data from the widget renderer.
Both paths hit the same API in the same order. The agent path asks the user once.

Two honest limits on that. An agent does nothing about the 40 percent who left over shipping costs, because the costs are the problem and hearing them spoken aloud does not improve them. And a first-time purchase with a new address and a new card is not a one-sentence task; it is a form, and it should stay one. The gains are concentrated in repeat actions by users the app already knows, which is also where the reorder case lives.

The confirmation step is the one screen worth keeping#

There is an irony in a post at this address arguing for fewer screens. The confirm step is the screen you should not remove, and the reason is that it is the only place where the user’s intent and the system’s interpretation are both visible at once.

Conversation design has known this for a while. Google’s guidance for voice agents recommends explicit confirmation in the form “You mean x?”, repeating only the part that matters rather than reciting the whole request back. The same guidance suggests raising the no-speech timeout when the user has something in front of them to read, which is exactly the moment a confirm card creates.

On the platform side the primitive already exists. Android’s biometric documentation describes auth-per-use keys, where the user authenticates for each single cryptographic operation rather than for a window of time, and says plainly that they are “useful for high-value transactions, such as making a large payment”. That gives you a tier boundary to design against. A balance check needs no gate. A payment needs one, bound to that one operation.

What to measure instead#

Abandonment rate is a poor operating metric because most of its movement comes from things a product team does not control. Task completion is better: of the people who started this specific thing, how many finished it.

The self-service literature is a useful warning here. Gartner’s August 2024 survey of 5,728 customers found that only 14 percent of service issues were fully resolved through self-service, and that 43 percent of failures happened because people could not find content relevant to their issue. An agent that answers fluently and finishes nothing will look busy in analytics and change no revenue.

What to take from this#

Quote the 70 percent with its method attached, or do not quote it. Treat the reasons ranking as a map of who owns what, and accept that design owns a minority share of it.

Then separate your tasks into the ones that genuinely need structured input and the ones that have been wearing a form because there was nowhere else to put them. The second group is where removing typing from the path pays, and it is smaller than a vendor would like to tell you. There are tasks where voice is the wrong mode entirely, and a checkout in a quiet office with a card in hand is often one of them.

If you want the integration detail, the guide to the whole agent stack walks the whole path, and the widget reference covers what a confirm card can express.

Sources#

Filed underConversionCommerceAgentsConfirmation

Next

The catalogue of every widget kind the agent can ask your app to draw, and the payload each one takes.

See what a confirm card is

The rest of Business

Open the cluster

Build versus buy, what an agent changes about activation and support load, and the measurements that tell you before the quarter ends.

Elsewhere on the map