Add to Cart vs Buy Now: The Experiment We Ran on 12 Stores

We have built and optimised more than 250 Shopify storefronts at WitsCode, and the question that keeps coming back at the product detail page is almost always the same. Should the primary button be Add to Cart on its own, or should Add to Cart sit above a Buy Now button that pushes shoppers straight into Shop Pay, Apple Pay, Google Pay or PayPal. The common advice is to stack both and let the shopper choose. The common result, when you actually measure it, is more complicated than that.

Over the last three years we ran the same structural experiment on twelve stores across twelve different categories. The test was always the same in shape. Control was Add to Cart alone as the PDP primary button. Variant was Add to Cart as the primary button with Shopify's dynamic checkout button stacked directly below it. What changed between stores was the category, the average order value, the traffic mix, and the proportion of returning Shop Pay visitors. What we found was a clean pattern that explains why so many case studies on this exact test contradict each other, and a handful of implementation details that quietly decide the outcome before the copy or the colour is even looked at.

What the Buy Now button actually does on Shopify

Before talking about results it matters to be precise about what the Buy Now button is, because most of the conflicting advice online treats it as a single static element when it is not. Shopify's dynamic checkout button renders differently for every visitor. For a shopper with an active Shop Pay session it renders as a purple Shop Pay button that skips the cart and skips the checkout address step, going straight to a one tap confirmation with an OTP. For an iOS Safari visitor with Apple Pay configured it can render as a black Apple Pay sheet. For an Android Chrome visitor with Google Pay it can render as a Google Pay button. For PayPal Express enabled stores it may render as PayPal. The merchant configures which wallets to enable, but the label and the flow the shopper sees depends on the shopper, not on the theme.

This is the first source of test result noise. If you run a simple A B test without segmenting by wallet state, you are measuring four or five different experiences blended into one variant, against a clean single experience in the control. Any conclusion drawn from the top line number is almost certainly wrong.

The twelve-store pattern

When we segmented results by category and by returning versus new shoppers a clear shape emerged. In five of the twelve stores, Buy Now stacked under Add to Cart lifted the conversion rate by between four and eleven percent. Those five stores had something in common. They sold single SKU or near single SKU products with high impulse intent. Supplements, a single launch piece of jewellery, a beauty serum with a three step upsell flow, a branded drinkware drop, and a direct to consumer skincare product. In these cases, shoppers arrived from a paid social ad already primed on the product, and the fewer steps between the ad click and the purchase the better. Buy Now collapsed three steps into one.

In four other stores, Add to Cart alone outperformed the stacked version by between three and seven percent on conversion rate and by a larger margin on average order value. These were the cart builder stores. Apparel where shoppers bought outfits not items, home goods where free shipping thresholds drove bundle behaviour, a pet brand where the core loyal customer stocked up on food and toys together, and a food subscription where add-on boxes drove margin. In these businesses the cart page is a critical upsell surface. The shipping threshold progress bar, the related products module, the discount code field, the bundle logic, all of this fires on the cart page and none of it fires when a shopper taps Buy Now. Sending people to a one-tap wallet checkout actively removed revenue from these businesses, even when it lifted sessions to purchase, because the orders that did come through were smaller.

The remaining three stores showed flat results within test noise. Electronics accessories, outdoor gear, and a kids brand all sat inside the margin of error. In each of those cases the product mix was split between single item impulse buys and larger basket builds, and the two effects cancelled each other out.

The takeaway is not that Buy Now is good or bad. The takeaway is that Buy Now wins when the purchase is atomic and loses when the purchase is compositional. Before running this test, look at your cart page analytics and ask what proportion of orders contain more than one line item. If it is above roughly forty percent, your cart is doing work that Buy Now will bypass.

Returning shoppers are a different product

The second finding from the twelve store data was that blending returning and new shoppers into the same test result hides almost everything that matters. When we split by Shop Pay cookie presence, returning shoppers with a saved session converted on Buy Now at rates between two and four times higher than on Add to Cart. That is not a marginal lift. It is a complete behavioural shift. A returning shopper who has already saved their card, shipping address and phone number with Shop Pay treats the Buy Now button as a one-tap repurchase, and any friction added between the PDP and that confirmation is a direct tax on revenue.

New shoppers hitting Buy Now did the opposite. In every one of the twelve stores, new shoppers who tapped Buy Now and landed on the Shop Pay OTP screen abandoned more often than those who went through the standard checkout. The reason is that the OTP screen looks like an account creation gate. It asks for a phone number, it sends a code, it creates a saved profile. To a first time visitor who just wanted to buy a thirty dollar item, that feels like a trick. Rage back clicks on this screen were three to six times higher than rage backs on the normal checkout email field.

If you are going to stack Buy Now under Add to Cart, the least you can do is gate its rendering on returning visitors, or at minimum measure the two cohorts separately so you do not average a win and a loss into a wash.

The keyboard accessibility trap

This is the implementation nuance that shows up in almost no blog post on this topic and that we have watched quietly cost stores conversions on repeat. Shopify's product form wraps both the Add to Cart button and the dynamic checkout button inside a single form element. Both buttons are type submit. The browser treats the first type submit button inside a form as the default action when Enter is pressed from any focused field inside that form.

In many Shopify themes, when you stack the buttons in the order Buy Now above Add to Cart, the Buy Now button becomes the implicit default. A shopper on a keyboard who selects a variant, tabs to the quantity field, types a two, and presses Enter expects to add the item to cart. Instead they get flung into Shop Pay with whatever the default quantity was before they finished typing. We saw this specifically in sessions recorded on a B2B tools store where a large share of shoppers used keyboards and where the checkout abandonment at the OTP screen spiked in direct correlation with keyboard users. Fixing the button order and explicitly setting the dynamic checkout button to type button solved it and recovered most of the loss.

The rule here is that if you stack, Add to Cart must be the first submit button in DOM order, not the first one the eye sees. CSS can reorder the visual stack with flex order or grid placement without changing the form submission default. Screen reader users and keyboard users will read the DOM order, and the Enter key will fire the DOM order, regardless of what the eye sees. Get this wrong and you create a silent accessibility failure that also bleeds money.

The low-RAM Android problem

The third implementation trap is mobile performance and it is the one most desktop-first CRO teams never catch because it does not show up in their own testing. The Shop Pay button does not render instantly. It is hydrated by a remote script that detects wallet availability, checks Shop Pay session state, and only then paints the active button. On a modern iPhone this takes around two hundred milliseconds and is invisible. On a low-RAM Android device of the kind used by a large share of shoppers in India, Brazil, Indonesia and much of Southeast Asia, the hydration can take anywhere from one point two to nearly three seconds.

During that hydration window the Buy Now button is visually present but functionally inert or worse, wired to a fallback path that dumps the shopper into the checkout without any wallet context. Shoppers tap, see no response, tap again, and by the time the second tap registers the button has hydrated. The double tap fires twice, the checkout opens with a confused state, and session replays show people staring at a loading spinner wondering what happened.

Two fixes apply. First, render the Buy Now button with an initial disabled attribute and a subtle loading treatment, enabling it only when the hydration callback fires. Second, if the hydration does not complete within a budget of roughly one second, hide the Buy Now button entirely on that page load rather than leaving a broken control visible. Neither of these fixes is exotic. Both of them require a theme developer who has actually looked at the script and thought about what happens before it resolves.

The cart page is doing more than you think

One pattern we saw repeatedly when Add to Cart won outright was that the cart page in those stores was not a dumb list of items. It was a conversion surface in its own right. Free shipping progress bars nudged shoppers to add another twelve dollars of product. Related product carousels surfaced accessories the PDP could not. Discount code fields let loyal customers apply codes that never appeared on the PDP. Shipping calculators reduced uncertainty on international orders. Abandonment email triggers fired from the cart page but not from an aborted wallet checkout.

Every one of these is a feature that Buy Now bypasses. If your store has built real machinery into the cart page, stacking Buy Now on the PDP is quietly cannibalising it. The lift you measure on single-session conversion rate may be real, but it is paid for with a drop in basket size and a drop in the behavioural surface area where upsells happen. The right answer in these cases is often to leave Buy Now off the PDP entirely and instead enable the dynamic checkout button on the cart page, where it skips only the checkout address step for returning wallet users and leaves the full cart context intact.

How to actually run this test

The shape of the test that gives a usable answer on your own store is different from the one most teams run. Split by device, because mobile and desktop wallet detection behave differently. Segment by Shop Pay cookie presence, because returning and new shoppers are effectively different products. Measure average order value alongside conversion rate, because a lift in CVR that comes with a drop in AOV is not a win. Track checkout abandonment by step, because a Buy Now variant can move the abandonment from the address screen to the OTP screen and net out to nothing. Run the test for at least two full weekly cycles, because Shop Pay cookie refresh patterns and paid social spend shape both sides of the mix.

The button itself is almost never the interesting variable. The interesting variable is how the rest of your store, the cart page, the upsell modules, the shipping thresholds, the returning customer segment, responds to the absence of the extra step.

What to implement tomorrow

If your store sells single SKU impulse products and your cart page has no upsell machinery, enable the dynamic checkout button on the PDP stacked below Add to Cart, fix the DOM order so Add to Cart is the first submit inside the form, gate the Buy Now button on successful wallet hydration with a one second budget, and measure returning versus new shoppers separately. If your store sells composable baskets with a working cart page, turn the PDP Buy Now button off and move the wallet button to the cart page instead, where it accelerates checkout without removing the upsell surface. If you do not know which of those two shapes your store is, pull a thirty day report on the proportion of orders with more than one line item and let that answer the question before you touch the theme.

The twelve store test did not produce a single winner because there is no single winner. It produced a map. Knowing where your store sits on that map is worth more than any button redesign, and the map is built from numbers you already have.