Ecommerce Checkout Optimization: The A/B Testing Playbook
The complete checkout optimization playbook: the real reasons people abandon, what to test in order of leverage, how to size it and what to guard.
Checkout optimization through A/B testing means attacking, in order of evidence, the documented causes of abandonment: extra costs that only surface at the end, forced account creation, forms that are longer than they need to be, and missing trust signals and payment methods. It is probably the most heavily studied stretch of ecommerce anywhere: the Baymard Institute documents an average cart abandonment rate of 70.22%, calculated across 50 studies, and estimates that the average large site can gain roughly a 35.26% increase in conversion rate by fixing known checkout usability problems. This playbook covers the checkout funnel and where to measure each step, the real abandonment causes ordered by data, what to test in order of leverage, how to size each test (with the good news that a high baseline rate makes the experiment cheap), an end to end worked example including incremental revenue, and the guardrail metrics that stop a false win.
Why checkout is the best place on the site to test
Three reasons, and none of them is “because that is where the money is”, which is true but shallow.
The first is weight of evidence. Checkout abandonment causes are among the most studied in ecommerce, with surveys repeated over more than a decade. You do not start from zero: you start from a hypothesis list already validated at scale, which is rare in conversion work.
The second is a high baseline rate. A site-wide conversion test works on a base of 2% to 3%, which demands enormous volume to detect anything. A checkout completion test works on a base of 40% to 60%, and a high rate means a far smaller sample for the same rigor. A test that would be unaffordable across the whole site fits into a week inside checkout.
The third is no dilution. Anyone you recover at the top of the funnel still has to cross every step that follows, and most of them will not. Anyone you recover on the last step of checkout converts one for one. That does not automatically make checkout the biggest bottleneck (see the next section), but it does make each person recovered there the most valuable in the funnel.
The size of the prize, according to Baymard: applying the 35.26% figure to combined US and EU ecommerce sales of 738 billion dollars gives roughly 260 billion dollars in abandoned orders that would be recoverable through better checkout flow and design alone (Baymard Institute). That is an aggregate research institute estimate, not a promise for an individual store, and it should be read as the scale of the problem rather than as a revenue projection.
The checkout funnel and where to measure each step
Before testing anything you need to know which step is leaking. And here comes the first honest point in this playbook: checkout is not always the biggest bottleneck in your funnel.
The arithmetic behind that is dilution. Recovering 10% of the drop at each step, accounting for the fact that anyone recovered still has to cross the steps that follow, yields:
| Step | People lost | Recovering 10% | Extra final conversions |
|---|---|---|---|
| Visitors to product view | 58,000 | 5,800 people | ≈ 371 |
| Product to cart | 28,000 | 2,800 people | ≈ 538 |
| Cart to checkout | 8,400 | 840 people | ≈ 403 |
| Checkout to purchase | 2,912 | 291 people | ≈ 291 |
In this funnel the biggest gain sits in the middle, not in checkout. The correct reading is not “so leave checkout alone”, it is: check your own funnel before deciding where to invest, and know that in checkout each person recovered is worth exactly one conversion, with no discount.
Run your own funnel in the calculator below, swapping in the numbers from your analytics:
Funnel stages (name and how many people reached it)
-
One stage has more people than the one before it. Check your numbers: in a sequential funnel nobody appears out of nowhere.
| Step | In | Lost | Pass rate | Drop | Gain if recovered |
|---|
Pass rate = people at the next stage ÷ people at this stage. The gain accounts for dilution: anyone you recover at the top still has to survive every later step. Leave a stage blank to use fewer than five.
Each step has its own metric and its own family of hypotheses:
| Step | Metric | Kind of hypothesis that belongs here |
|---|---|---|
| Visitor to product page | Product view rate | Navigation, internal search, categories, speed |
| Product to cart | Add to cart rate | Photography, description, social proof, availability, visible price |
| Cart to checkout start | Checkout start rate | Total costs visible in cart, call to action, distractions |
| Checkout start to purchase | Checkout completion rate | Fields, forced account, payment methods, trust, errors |
This playbook is about that last row, and a little about the one above it, because the decision on extra costs happens in both.
The real reasons people abandon, ordered by data
The Baymard Institute maintains the most cited survey of why people abandon during checkout. Excluding those who were only browsing with no intention to buy, the distribution of reasons is:
Notice three things in that list.
First, the leading cause is not a usability problem, it is a price transparency problem. Extra costs being too high (40%) and not being able to see the total cost up front (12%) are the same problem at two moments: the person finds out too late that the price was not the price. No amount of field reordering fixes that.
Second, technical errors rank high (17%). Before testing copy, it is worth confirming that your checkout simply works across browsers, screen sizes and payment methods. That is not an A/B test, that is a bug.
Third, the account requirement (18%) is the highest-ranked cause with the cheapest fix. It is a product decision, not a rebuild.
Checkout optimization: what to test, in order of leverage
The table below orders the playbook: it starts with what the evidence points to as the biggest cause and with what is easiest to isolate, and ends with what changes many things at once.
| Order | What to test | Hypothesis | Cause it attacks | Effort |
|---|---|---|---|---|
| 1 | Total cost (shipping and fees) visible in the cart | Showing the total before checkout removes the surprise that makes people leave | Extra costs (40%) and not seeing the total up front (12%) | Low |
| 2 | Guest checkout against forced account | Letting people buy without registering removes the barrier before the purchase | Account required (18%) | Low |
| 3 | Reducing the number of form fields | Fewer fields, less friction and less chance of error | Checkout too long or complicated (17%) | Medium |
| 4 | Trust signals next to the card field | Badge, security policy and reviews reduce the fear of paying | Not trusting the site with card details (19%) | Low |
| 5 | Explicit delivery date in checkout | Seeing the real arrival date removes abandonment through uncertainty | Delivery too slow (20%) | Medium |
| 6 | Return policy visible in the flow | Knowing returns are possible lowers the perceived risk of buying | Unsatisfactory return policy (13%) | Low |
| 7 | More payment methods and decline recovery | Offering alternatives avoids losing people whose card was declined | Card declined (10%) and insufficient methods (9%) | High |
| 8 | Progress indicator and step order | Knowing how much is left reduces mid-flow drop-off | Checkout too long or complicated (17%) | Medium |
| 9 | One-page checkout against multi-step checkout | Fewer screens reduce the chance of leaving along the way | Several at once | High |
One rule holds across the entire table: isolate one variable per test. Changing the field count and adding a security badge in the same experiment produces a winner nobody can explain, and explaining is what lets you apply the lesson on the next page. The same reasoning from the step by step guide to running an A/B test applies here, with the aggravating factor that checkout has more coupled elements than any other screen on the site.
Extra costs: the number one cause
If your store charges shipping, a service fee or any amount that only appears on the last screen, that is the first test to run. Two honest variations:
- Total visible in the cart: calculate and show estimated shipping (by postcode or regional default) before the person enters checkout.
- Free shipping above a threshold: a clear threshold, communicated in the cart, showing how much is left to reach it.
The second carries a side effect that needs a guardrail: it can raise checkout completion while moving average order value in either direction (up, if people add items to reach the threshold; down, if the shipping you absorb costs more than the gain). Measure revenue per checkout session, not just the completion rate.
Guest checkout: the cheapest change on the list
18% of abandoners name the account requirement. The answer is not to abandon registration, it is to invert the order: let the purchase happen as a guest and offer account creation on the confirmation screen, once the order is secured and the person has already typed almost every field it needs. The test is clean (one variable, one extra button) and the metric is direct.
Reducing fields
Baymard notes that for most checkouts it is possible to cut the number of form elements displayed in the default flow by 20% to 60%. Where that reduction usually hides:
| Field | Why it usually survives | Alternative |
|---|---|---|
| Separate address line 2 | Rarely mandatory | Optional field, or folded into the address |
| Email confirmation | Duplicates typing | Inline validation with a clear error message |
| Separate billing address | Same as shipping in most cases | Checked as identical by default, with an option to change |
| Mandatory phone number | Not every operation needs it | Optional, with an explanation of why it helps |
| Prominent coupon field | Sends the person off to hunt for a code | Discreet link, collapsed by default |
That last one deserves a note: a large, prominent coupon field is an invitation to open another tab and go looking for a code, and a share of those people do not come back. It is a classic testable hypothesis and easy to isolate.
Trust at the moment of payment
19% of abandoners point to not trusting the site with their card details, the third largest reason on the list. It is an uncomfortable cause because it does not yield to argument: nobody changes their mind about security by reading an institutional paragraph. What tends to be testable are concrete signals placed close to the moment of decision:
- Physical proximity of the signal. A security badge in the footer is decoration; the same badge next to the card field sits where the fear actually appears. Moving the element without changing its content is already a valid test.
- Company name and contact details visible. A store that shows who it is reduces the sense of buying from an anonymous address.
- Reviews and social proof inside the payment flow. Not the overall store rating in the footer, but the signal that other people completed purchases there.
- An explanation of what happens next. Saying what will be charged, when, and how the confirmation arrives removes part of the uncertainty that blocks the final click.
Each of those is an isolable variable. Stacking all four into one variation produces a winner that teaches nothing about which signal mattered.
Payment methods and card declines
Adding “card declined” (10%) to “insufficient payment methods” (9%), nearly a fifth of abandonment mentions live in the payment layer, and that is the most expensive part to change, because it involves integration rather than interface. Two fronts with very different effort:
The first is decline recovery: what your screen does when a payment is refused. A generic error message loses the sale; a screen that explains what happened, keeps the order data and offers another payment method has a chance of recovering part of it. That is an interface test, it is cheap, and it addresses 10% of mentions.
The second is adding a new payment method, which requires integration and is not reversible with one click. Treat it as a product decision informed by payment attempt data (how many people reach payment and do not complete, and what they tried to use), not as a casual A/B test.
What is not worth testing in checkout
Not every lever that moves the number should be pulled. Three categories this playbook recommends leaving out, for practical rather than moral reasons:
- Manufactured urgency. A countdown that resets, “only 2 left” that never changes, a warning that the cart expires when it does not. This tends to raise completion inside the test and come back later as cancellations, refunds and complaints, three things the primary metric does not measure. If you are going to test urgency, test real urgency and read the refund guardrail over 30 days.
- Auto-added items or services. Insurance, gift wrapping or express shipping pre-checked raise the order value in the report and generate a proportional volume of disputes afterwards. The honest test is to offer it unchecked and measure whether people accept.
- Hiding a cost to reveal it later. That is exactly the number one abandonment cause from the Baymard list, applied deliberately. Even when it raises completion on one isolated step, it pushes the abandonment to the next step and the total does not improve.
The practical criterion is simple: if the variation wins because the person understood better, it survives the month-end close; if it wins because the person understood worse, the gain comes back as a return.
How to size a checkout test
Here is the mathematical good news about checkout: because the baseline rate is high, the test is cheap. The table below starts from a checkout completion rate of 48%, at 95% confidence and 80% power:
| Minimum relative effect sought | Target rate | Sample per variation | Days at 3,500 checkouts/week |
|---|---|---|---|
| +10% | 52.8% | ≈ 1,703 | ≈ 7 |
| +5% | 50.4% | ≈ 6,811 | ≈ 28 |
| +3% | 49.4% | ≈ 18,913 | ≈ 76 |
Compare that with the same exercise on a site-wide conversion rate of 2.7%: detecting 5% relative would require roughly 231,776 visits per variation, or about 130 days at 25,000 visits per week. The same rigor, in the same business, costs roughly 34 times more sample when measured on the small base.
Work out your own case, using initiated checkouts per week as the volume:
Two-proportion normal approximation, 2 variations (50/50). Tweak the inputs and watch it update live.
Set the calculator above to baseline rate 48, minimum detectable effect 5 (relative) and 3,500 weekly visitors to reproduce the 6,811 per variation and the 28 days from the table.
One caveat that matters more in checkout than anywhere else: the effect you can detect falls along with the volume available, and checkout has, by definition, fewer people than the rest of the site. Do not resolve that by running the test site-wide and measuring only those who reached checkout. Anyone who reaches checkout is already a selected population, and comparing that slice across variations that changed something earlier introduces exactly the selection bias that invalidates the reading.
A worked example, from test to revenue
A store with 5,200 initiated checkouts per arm tests showing the total cost (product plus shipping plus fees) on the cart screen, against its current behaviour of revealing shipping only at the last checkout step. The primary metric is checkout completion:
- A (control, shipping revealed at the end): 2,496 completed purchases out of 5,200 initiated checkouts, a rate of 48.00%.
- B (variation, total cost in the cart): 2,652 completed purchases out of 5,200 initiated checkouts, a rate of 51.00%.
Paste those numbers into the calculator below to check:
Two-sided two-proportion z-test. "Not significant" almost always means not enough sample, not that the versions are equal.
The result: an absolute lift of 3.00 percentage points (a relative lift of +6.25%), a z score of roughly 3.06, a two-sided p-value of about 0.0022, and a 95% confidence interval for the difference from 1.08 to 4.92 percentage points. The interval does not cross zero and the p-value sits well below 0.05: variation B wins with real significance.
The incremental revenue arithmetic: with 14,000 initiated checkouts per month, a difference of 3.00 percentage points and an average order value of $85, projected incremental revenue is $35,700 per month, or roughly $428,400 over a year, purely from showing the total cost earlier. Treat the annual number as a linear projection: it assumes stable volume and order value, which rarely holds across twelve months.
The guardrail metrics a checkout test demands
Checkout is the screen where it is easiest to win on the primary metric and lose money overall. Three guardrails, declared before you launch:
| Guardrail | What it prevents | How to read it |
|---|---|---|
| Revenue per checkout session | Winning on completion while sinking average order value (typical of free shipping or discount tests) | If completion rises and revenue per session falls, the win is false |
| Payment error rate | A form change breaking validation on some payment method or browser | Any meaningful rise is a stop condition, not a discussion |
| Cancellation or refund within 30 days | A purchase rushed by artificial urgency coming back as a return | Compare the whole window, not just the purchase day |
The same care about early peeking applies here, with a twist: because checkout usually accumulates sample fast (high baseline rate), the temptation to stop on the first good day is stronger. The statistical cost of that is quantified in the guide to statistical significance in A/B testing: set the window before you launch, and honour it.
Mobile and desktop are different checkouts
A checkout test that runs in aggregate hides the fact that the two experiences are, in practice, different products: virtual keyboards, fields that require zooming, inconsistent autofill, native digital wallets. A variation can win on desktop and lose on mobile, with the aggregate result reporting a tie.
The answer is not to run two separate tests by default, which doubles the sample cost. It is to declare up front whether you expect a different effect by device. If you do, size the test for the segment that matters. If you do not, run it in aggregate and read the device breakdown as diagnostics, knowing that each slice has less sample and therefore less power, and that a difference appearing only in the breakdown is not a result, it is a hypothesis for the next test.
The mistakes that show up most in checkout testing
| Mistake | Warning sign | Fix |
|---|---|---|
| Changing several things at once | The whole checkout was redesigned in a single test | Isolate one variable; leave the restructure for after the isolable changes |
| Measuring completion only | The report has exactly one metric | Declare revenue per session, payment error and refund as guardrails |
| Measuring the checkout slice in a test that changed what comes before | “In checkout, variation B converted more” | Whoever reaches checkout is already a selected population; measure from the test entry point |
| Stopping on the first good day | A high base rate accumulates sample fast and tempts you | Fix the window before launching and see it through |
| Comparing different weeks | A ran one week, B the next | Run them simultaneously; ecommerce seasonality is strong |
| Assuming checkout is the bottleneck | Everything was invested there without looking at the funnel | Run the funnel first; the biggest gain may sit earlier |
| Copying a competitor’s free shipping threshold | “Everyone uses $50” | The right threshold is a testable variable and depends on your order value and margin |
A realistic testing sequence for the first 90 days
The playbook table above is ordered by leverage, not by calendar. Turning it into a schedule means accepting a constraint most articles skip: with a 48% baseline and 3,500 initiated checkouts per week, a test sized to detect 5% relative takes about four weeks, so a quarter holds roughly three well-powered tests, not twelve.
| Weeks | Focus | Why here | What has to be ready before |
|---|---|---|---|
| 0 | No test: instrumentation and bug sweep | Site errors are named by 17% of abandoners, and a broken payment path corrupts every result that follows | Event tracking per step, device breakdown, payment error logging |
| 1 to 4 | Total cost visible in the cart | Attacks the largest documented cause, and it is isolable | Shipping estimate available before checkout, revenue per session guardrail declared |
| 5 to 8 | Guest checkout | Second largest cause with the cheapest implementation | Confirmation screen able to offer account creation after the order |
| 9 to 12 | Field reduction, or trust signals at the card field | Whichever your own drop-off data points to; do not run both in one test | Field-level abandonment data from the previous quarter |
Two things about that schedule are deliberate. Week zero has no test in it, because running an experiment on top of a checkout that throws errors on one browser produces a result that measures the bug rather than the change. And each block holds exactly one test, because the alternative (two changes in one window) is how teams end up with a winner they cannot explain and cannot reuse.
If your volume is lower than 3,500 initiated checkouts per week, the sequence does not change, the arithmetic does: either accept a larger minimum detectable effect (a 10% relative target needs roughly 1,703 per variation instead of 6,811) or accept a longer window per test. Those are the only two honest levers. Shortening the window while keeping the same target effect does not buy speed, it buys a coin flip dressed as a decision.
Make this automatic with Donnu
Checkout optimization is the part of conversion work with the most accumulated evidence and, at the same time, the easiest to ruin with a hasty reading: a high baseline rate accumulates sample fast, which invites stopping early and celebrating a difference that is not yet a difference. Add the guardrails almost nobody declares up front (revenue per session, payment errors, refunds) and you have the recipe for a win that evaporates at month-end. Donnu handles exactly that part: you define the change and the metrics that must not get worse, Donnu sizes the sample from your real baseline rate, holds the verdict until the agreed window closes, and returns the entire confidence interval rather than a “significant” badge.
Start a 14 day free trial and run your next checkout test with that rigor.
References
- Baymard Institute. Cart Abandonment Rate Statistics. Average across 50 studies of cart abandonment, checkout abandonment reasons and the estimated conversion gain from better checkout design. baymard.com/lists/cart-abandonment-rate.
- Baymard Institute. Checkout Usability Research. Base of usability problems documented in large-scale checkout research. baymard.com/research/checkout-usability.
- Klaviyo. Abandoned Cart Benchmark Report: Rates & Statistics. Reference for cart abandonment email recovery rates. klaviyo.com/blog/abandoned-cart-benchmarks.
- Omnisend. Reduce Shopping Cart Abandonment: Reasons & Solutions. omnisend.com/blog/shopping-cart-abandonment.
Read next:
Frequently asked questions
- What is the average cart abandonment rate?
- The Baymard Institute documents an average of 70.22%, calculated across 50 different studies of ecommerce cart abandonment. In other words, roughly seven in ten people who put something in a cart do not complete the order. That is the aggregate market figure, and your own number can sit well above or below it, which only your analytics can answer.
- How much is there to gain from fixing checkout?
- According to the Baymard Institute, the average large ecommerce site can gain roughly a 35.26% increase in conversion rate by fixing already documented checkout usability problems. Applied to the combined US and EU ecommerce sales figure of 738 billion dollars, that works out to roughly 260 billion dollars in abandoned orders recoverable through better checkout flow and design alone. It is a research institute estimate, not a guarantee for any individual store.
- What is the leading reason people abandon during checkout?
- Extra costs that are too high (shipping, fees and taxes) leads with 40% of mentions among people who abandoned for a reason other than just browsing, according to the Baymard Institute. Next come delivery being too slow (20%), not trusting the site with card details (19%), being required to create an account (18%), a checkout that is too long or complicated (17%) and site errors or crashes (17%). Note that the number one cause is a price transparency issue, not a form design issue.
- Is checkout always the biggest bottleneck in my funnel?
- No, and it is worth checking before investing. In the worked funnel in this guide, the biggest bottleneck in recoverable final conversions sits in the step from product view to add to cart, not in checkout. What makes checkout uniquely valuable is something else: the people you recover there convert one for one, with no dilution from later steps, and the abandonment causes at that step are among the best documented in all of ecommerce.
- How many visits do I need to test a checkout change?
- It depends on the effect you want to detect. On a baseline checkout completion rate of 48%, at 95% confidence and 80% power, you need roughly 1,703 initiated checkouts per variation to detect a 10% relative improvement, 6,811 for 5% and 18,913 for 3%. The good news about checkout is that the baseline rate is high, so it needs far less volume than a site-wide conversion test running on a 2% to 3% base.
- Should I force customers to create an account at checkout?
- The market data argues against it, and it is one of the best effort to return ratios available: 18% of people who abandon checkout name the account requirement as a reason, according to the Baymard Institute. The alternative is not to give up on registration, it is to invert the order. Let the purchase happen as a guest and offer account creation on the confirmation screen, once the order is already secured.
- What guardrail metrics does a checkout test need?
- At least three, declared before you launch: revenue per checkout session (a variation can lift completion and sink average order value), payment error rate (a form change can break validation on some payment method) and cancellation or refund rate over the following days (a purchase rushed by artificial urgency comes back as a return). Without those three it is entirely possible to declare victory on one metric and lose money overall.
- Is it worth testing one-page checkout against multi-step checkout?
- It is worth testing, but it is the most expensive test in the playbook and it should not be your first. It changes several things at once (information per screen, sense of progress, the moment costs appear), so a positive result does not tell you which part worked. Start with the isolable changes (visible costs, guest checkout, fewer fields) and leave the full restructure for after those are settled.