The Invisible Shopify Sticky ATC I Almost Missed

Open one of your product pages on a real phone, not the theme editor preview. Scroll past the buy button. Does a sticky add-to-cart bar appear at the bottom of the screen? If it does, tap it. Does the cart drawer open? Does the variant you selected up the page actually land in the cart?

If you hesitated on any of those three, your Shopify sticky ATC may be present and broken at the same time. That is the state I keep finding in store audits this year, and it costs more than merchants think.

A Shopify sticky ATC can be present on the page and still be broken in ways that never show up in the admin - usually because the button is technically there and effectively invisible.

What I checked first

A merchant on Dawn 15 messaged me about a slow drift downward in mobile conversion. Their Shop Pay accelerated buttons were on. Apps and tracking pixels looked normal. I checked the carrier rates, the variant inventory, the discount codes, the consent banner. Nothing obvious in any of those places.

So I opened the store on my own phone instead of the desktop emulator. I scrolled down the longest product page they had - a four-image PDP with a 600-word description, three reviews, and an FAQ accordion. The buy button rolled off the screen at the second product image. I waited for the sticky bar.

Nothing happened.

That part was actually fine, technically. Dawn 15 does not ship a native sticky ATC, and it never has. The Shopify Community thread asking for one in Dawn goes back to July 2022, and the answer was the same then as it is now: install an app, write custom code, or follow a YouTube tutorial that will break the next time Dawn ships an update. The merchant had never installed one. So the sticky ATC was not missing - it had never been there.

That is the first place I tend to go wrong on this kind of investigation. I assume an element is broken when it was never built.

The button was there, and effectively invisible

A few weeks later, a different merchant - same Dawn theme, different conversion problem - asked me to look at their store. The mobile conversion rate was sitting near 0.25%, which is the kind of number that reads as a platform issue, not a CRO problem.

I had read a Reddit thread earlier in the spring from a consultant (TFDangerzone2017) about a footwear brand at almost exactly that conversion rate. The issue turned out to be a sticky ATC anchored to the bottom of the screen in a color that disappeared into the page background. Customers would scroll right past it. The consultant said the restyle was roughly twenty minutes of CSS work and the add-to-cart rate jumped about 17% within a week. Combined with moving a chat widget that was sitting on the buy button on iOS only, conversion went from 0.25% to 1.8% in three weeks.

I checked. There was a sticky bar. It was a faint cream tone on a cream background. I had to angle the phone in direct light to see the outline. The merchant had told me earlier "we have a sticky ATC" and they were technically correct. They had paid an app developer for it months earlier and assumed it was working because the app admin showed the feature as active.

That state is the worst one to be in. The button exists. The element loads. The admin shows the feature as enabled. CRO tooling reports the element as present. It contributes nothing to the funnel because nobody can see it.

Then the variant was not actually getting selected

On a third store - a small jewelry brand on Horizon 3.2 - the sticky ATC was visible, tapped fine, and opened the cart drawer cleanly. The cart got an item. The merchant's complaint was returns: customers were ordering the wrong ring sizes and emailing them to swap.

This one took me longer than it should have. I tested it: scrolled past the buy button, picked size 7 in the main product form, scrolled back down, tapped the sticky bar. The drawer opened with size 6 in the cart. The default. Not the size I had picked.

It turns out that is a confirmed Horizon limitation, not a one-off. A different jewelry merchant (ChrisBradley, running a store called Luna Rae) filed it as a feature request in the Shopify Developer Community in December 2025: the native Horizon sticky ATC does not include a variant selector and always adds the first or default variant, regardless of what the customer chose in the main form above it. Daniel_Ramos added a confirmation a couple of months later. As of June 2026 the request is still open and unshipped.

For a single-variant product line that does not matter. For anything with sizes or colors or any meaningful variant axis, the Horizon sticky ATC is a wrong-variant generator. What looked like a return problem was a Shopify sticky ATC problem producing returns downstream.

The Dawn-vs-Horizon CSS trail I went down for an hour

At this point I should have known better, but I spent maybe an hour trying to restyle a custom sticky ATC on a Horizon merchant who had built their own. The element would not accept anything I added through the theme editor or in custom CSS.

Horizon's CSS class names change between versions and between stores. The threads in the Shopify Community now caveat their own snippets with lines like "every website may have unique class names depending on the specific version of the Horizon theme or installed apps." That is a polite way of saying you cannot give someone a single CSS snippet for a Horizon sticky ATC and expect it to keep working past the next theme update.

The wrong move I made: I assumed the class name in the merchant's theme inspector was the same class name their copy of Horizon was actually using. It was not. The element I was looking at had a block-scoped class generated at compile time. My CSS targeted the class as written; Horizon's runtime was using a derivative. Nothing applied.

If you have worked through Horizon's CSS overrides before, you know the trap. I wrote about a similar version of it in the Horizon mega menu postmortem - same pattern, different element. Horizon's block variables defeat element selectors in a way that Dawn never did. The fix is to target the block-scoped variant, not the descriptive name, and to expect that override to break on the next theme update anyway.

The app conflict I missed for two days

A fourth merchant had installed a name-brand sticky ATC app on a Prestige theme. The button worked - it added the right variant, looked clean, opened a cart drawer. Customers using the store's product personalization feature (engraving text on a wedding band) were getting unengraved items in their cart.

The personalization data lives in the main product form. The sticky ATC app, like most standard sticky ATC apps, creates its own parallel form and submits to the cart endpoint directly. Whatever the customer typed into the engraving field went into the main form, not the sticky one. Tapping the sticky button bypassed the engraving entirely.

This is the architecture problem most sticky ATC apps do not document. There are two implementation paths. The parallel-form approach has the app submit its own form to the cart - easier to build, and what most apps ship. The trigger approach has the sticky button fire a click event on the original ATC button. The trigger version is the only one that respects product options apps, quantity break apps, bundling apps, or any other tool that hooks into the main form.

The merchant in this case had to swap the sticky ATC app for a custom-coded trigger button. The community thread that names the requirement cleanly (March 2025, merchant madebyme1 on Prestige) is the only one I have found that frames it that way. If you are running anything that customizes products beyond the standard variant selector, the architecture choice is the difference between a feature and a footgun.

The clue I almost missed: desktop-only failure

One more pattern, less common, more confusing. A merchant in late 2025 (Furro, on the Shopify Community in August) had a sticky ATC working correctly on mobile and breaking on desktop. Most of my checks were mobile-first because that is where these issues usually surface. I missed the desktop-only version of the same problem on a store of my own, briefly, last winter. CSS targeting what looked like the right class names did not apply; one fix attempt removed the button entirely. That thread is still unresolved.

If you only test on a phone, you will miss this one. I add a quick desktop pass now after I finish the mobile check.

What it actually was, in each case

Across the stores above, the Shopify sticky ATC investigation came down to one of four patterns, roughly in this order of frequency:

1. The button is there but invisible. Background-matched color, low contrast, or a z-index conflict putting another fixed element on top. Look on a real phone in direct light. The consultant case saw a 17% lift in ATC rate within a week of the restyle alone.

2. The button is present but adds the wrong variant. Native Horizon's sticky ATC, and many code-based snippets that skip the variant-sync event listener. The fix is JavaScript that updates the sticky button's hidden ID field every time the main form's variant input changes. Without that listener, the bar adds the default variant no matter what the customer selected above.

3. The code is in the wrong file or wrong place. The button renders but does not add to cart. A community thread from November 2024 traced this to the snippet being placed below the {% render 'product-media-modal' %} render tag in main-product.liquid; moved above the tag, the same code worked. The submission path matters too: a naive form.submit() posts to the wrong endpoint. The code that actually works uses fetch(window.Shopify.routes.root + 'cart/add.js', config) with the variant ID synced from the main form.

4. App conflict with a customization tool. The sticky ATC app submits its own form and bypasses your product options, quantity break, or bundling logic. Switch to a trigger-style implementation, or remove the parallel sticky button entirely. This usually needs a developer; it is not exposed in any standard app's settings panel.

None of these is a five-minute fix the first time you see it. They are twenty-minute fixes once you know which one you are looking at. If you have a Shopify sticky ATC complaint, you have tested on a real phone, and you still cannot tell which of these four is the one, the first 15 minutes with a help1 expert is free and that is usually plenty - we open DevTools on your store with you, look at the element, and tell you which pattern it is.

What I do now when a sticky ATC complaint comes in

The order of operations I follow has gotten shorter over the last six months. It is roughly:

1. Open the live store on a real phone, in real light. Scroll past the buy button on the longest PDP. Note whether a sticky bar appears, whether it is visible against the background, and whether the variant currently selected up the page is the one that lands in the cart when I tap.

2. If a button appears and is invisible, restyle the CSS. If the merchant is on Horizon, expect the class name to be block-scoped; target it via the parent block container and budget a follow-up after the next theme update.

3. If the button works and adds the wrong variant, identify whether the implementation is the native Horizon sticky bar (variant gap is by design, as of now) or a custom snippet missing the sync listener. Either way the actual fix is a small change event listener on the main form's variant input.

4. If the button does nothing at all, check main-product.liquid placement. Almost always it is below the product-media-modal render tag.

5. If the button works but the customizations are missing, the app is using a parallel form. Switch to a trigger implementation.

The pattern that keeps catching me is the first one. It is the easiest to overlook and the easiest to fix. A Shopify sticky ATC the merchant cannot see is the one they paid for and have been ignoring for six months because the admin says it is enabled.

A Shopify sticky ATC is the kind of feature where "we have it" and "it works" are two different sentences, and the dashboard rarely tells you which one is true.