A Shopify quantity-break widget is ready for mobile traffic only when shoppers can understand the tiers, select the intended quantity and variants, and see the same product and price in the cart. Fitting the cards inside a narrow screen is not enough.
Treat a hidden total, ambiguous selected tier, covered Add to cart button, or incorrect cart handoff as a launch blocker. Smaller density and styling issues can be simplified after the transactional path is safe.
Kaching Bundles & Upsells is a practical implementation option because it provides multiple layouts, configurable styling, variant dropdowns or swatches, movable widget placement, and live savings feedback. Those controls help you fix mobile presentation; they do not replace a release checklist for your chosen configuration.
The mobile release rule
Do not average a wrong cart result together with minor visual issues. Some failures deserve more weight.
Hold the launch if:
- the widget loses required information or functionality at a narrow width;
- shoppers cannot tell which tier is selected;
- quantity, variants, price, or savings fail to update with the selection;
- a sticky bar or overlay blocks a required control;
- the cart or checkout receives the wrong product, variant, quantity, discount, or total.
These are hard gates because the shopper can make a different purchase from the one the interface appeared to promise.
A long subtitle, repeated savings label, decorative badge, or excessive spacing is different. It can make the choice slower and push the button lower, but it does not automatically invalidate the transaction. Those failures belong in the SIMPLIFY queue once the hard gates pass.
Shopify’s own store design checklist treats mobile review and checkout testing as separate tasks. Use the same separation here: first inspect the mobile presentation, then prove the purchase result.
Use the 18-test Mobile Quantity-Break Release Matrix
Record PASS, FAIL, or NOT APPLICABLE for each test. Keep the product, tier prices, theme, and other offers stable while you review the widget. Otherwise, you will not know which change created the failure.
A. Can the shopper understand the offer?
| Test | Pass condition | If it fails |
|---|---|---|
| 1. Reflow at 320 CSS pixels — HARD GATE | Every required label, price, selector, and action remains available without horizontal page scrolling | HOLD; change the layout or shorten nonessential content |
| 2. Selected tier — HARD GATE | The active tier is obvious through more than color alone, such as a border, check, label, or radio state | HOLD; strengthen the selected state |
| 3. Quantity and price relationship — HARD GATE | The shopper can identify the selected quantity, unit price when used, total commitment, and savings without doing arithmetic | HOLD; restore the missing price context |
| 4. Long-content resilience | Longer product names, currencies, translated labels, and tier copy wrap without collision or truncation | SIMPLIFY labels or increase the available text area |
WCAG 2.2 Reflow uses a width equivalent to 320 CSS pixels as its Level AA reference and requires no loss of information or functionality, subject to its stated exceptions. That makes 320 a useful hard check even if most of your shoppers use wider phones.
The selected tier also needs more than a green background or colored outline. WCAG’s Use of Color criterion says color should not be the only means of communicating state. A checkmark, “Selected” label, clear radio control, or thicker high-contrast boundary gives the shopper a second cue.
Price hierarchy needs similar discipline. A large per-unit figure can make comparison easy while hiding the amount that will actually be charged. Keep the total visible in the selected state, especially when a tier contains several units or different variants.
B. Can the shopper select the offer accurately?
| Test | Pass condition | If it fails |
|---|---|---|
| 5. Target size and spacing | Every tier, radio control, swatch, dropdown, and increment control meets the formal minimum or has sufficient spacing under the applicable exception | Enlarge or separate the controls |
| 6. Tap behavior | Tapping a card does not accidentally activate a nested link, tooltip, checkbox, or neighboring tier | Remove nested conflicts or narrow the clickable area deliberately |
| 7. Live state update — HARD GATE | Changing tiers immediately updates quantity, price, savings, badges, gifts, and any relevant purchase summary | HOLD; fix stale or contradictory state |
| 8. Variant persistence — HARD GATE when variants are required | Each item keeps the intended option and the selected tier remains valid after variant changes | HOLD; fix defaults, unavailable combinations, or lost selection |
WCAG 2.2 Target Size (Minimum) sets a Level AA minimum of 24 by 24 CSS pixels, with defined exceptions. Use that as the formal floor, not a claim that a 24-pixel control will feel comfortable for every shopper. Closely packed tiers, small swatches, and tiny information icons still deserve more breathing room when the page allows it.
Whole-card selection can reduce precision demands, but only when the card does one job. If the same card contains a variant dropdown, details link, gift checkbox, and tier selector, making the entire surface clickable can create competing actions. Tap the edges and the spaces between controls, not only their centers.
For a simple same-SKU offer, Test 8 may be one variant selector above all tiers. For a tier that lets shoppers choose a different flavor or color for each unit, expand every representative selector. The hardest state is usually the highest quantity with the longest option labels—not the default one-unit card.
C. Does the mobile purchase sequence remain usable?
| Test | Pass condition | If it fails |
|---|---|---|
| 9. Sticky and overlay obstruction — HARD GATE | Sticky Add to cart, chat, cookie banners, popups, and the mobile keyboard do not cover a required tier or variant control | REPOSITION or disable the conflicting element for that state |
| 10. Text resize and zoom | Increasing text size or zoom does not hide the selected state, total, or submit action | Reduce fixed heights and allow content to wrap |
| 11. Narrow and long-page orientation | The shopper can move from required variants to tiers to Add to cart without losing which choice the button will submit | REPOSITION or shorten the decision block |
Mobile turns a side-by-side desktop product page into one vertical sequence. A quantity-break widget can sit “next to” Add to cart on desktop and still be separated from it by a full screen of expanded selectors on a phone.
Do not use “above the fold” as the pass condition. Fold height varies, and first-screen visibility does not prove comprehension. The stronger test is whether the shopper reaches the quantity choice before the action it changes and can still identify the selected total when pressing Add to cart.
A sticky button can help on a long page, but it must not float above stale information. If the sticky bar displays one price while the selected tier displays another, or if it covers the last variant dropdown, it is creating a second purchase state rather than shortening the first one.
D. Does the transaction preserve the mobile selection?
| Test | Pass condition | If it fails |
|---|---|---|
| 12. Cart contents — HARD GATE | Cart contains the intended product, every selected variant, and the correct total quantity | HOLD; fix the product-form or variant handoff |
| 13. Cart and checkout price — HARD GATE | Discount, line prices, total, and stated savings reconcile from product page through checkout | HOLD; fix pricing or discount behavior |
| 14. Cart edits | Removing or reducing items removes any tier, gift, or savings state the cart no longer qualifies for | Fix stale qualification and retest |
| 15. Representative offer interaction | A common subscription, discount code, sale state, or cart condition produces the documented result or a clear limitation | Explain the conflict or redesign the combination |
Run these tests with the tier most likely to expose a problem, not only the default tier. Use the largest quantity, a mixed-variant selection when allowed, and one common offer interaction that exists in your actual store.
Test 15 is not permission to reopen every discount-stacking scenario. Its purpose is to prevent a mobile widget from making a promise that disappears without explanation in the merchant’s most common path. If the quantity break does not combine with a welcome code or subscription price, the page should not make shoppers discover that at payment.
A visitor theme-preview link is useful for reviewing layout, but Shopify notes that visitors using that type of preview cannot complete transactions. Use a transactional preview or the published storefront when proving Tests 12 and 13.
E. Does the widget protect accessibility and performance?
| Test | Pass condition | If it fails |
|---|---|---|
| 16. Core Web Vitals comparison | The candidate does not create an unexplained material regression in LCP, INP, or CLS; field data is reviewed when available | Diagnose loading, interaction, or shift before blaming or removing one component |
| 17. Text and control contrast | Normal text, selected-state boundaries, radio controls, and swatches remain distinguishable against adjacent colors | Change colors, borders, or state cues |
| 18. Status feedback | Tier, price, savings, validation, and cart changes are visible and, where applicable, available to assistive technology | Add or correct status communication |
Shopify’s web-performance guidance lists Good thresholds of:
- LCP at 2.5 seconds or less;
- INP below 200 milliseconds;
- CLS below 0.1.
Shopify also explains that its performance reports use the 75th percentile of real page loads. Do not treat one synthetic run as proof that the field threshold passes or fails. Run a stable before-and-after diagnostic check, then use real-user reporting when the store has enough traffic.
The same page lists apps, third-party libraries, analytics, theme code, and media among the factors that can affect performance. If CLS worsens after adding the widget, confirm whether the widget reserves its space while loading. If INP worsens, inspect tier, dropdown, and Add to cart interactions. Do not uninstall an app because one score fluctuated while several other page elements changed.
For contrast, WCAG 2.2 sets a 4.5:1 minimum for normal text and 3:1 for large text under its Level AA contrast criterion. Its non-text contrast criterion uses 3:1 for relevant interface components and states. A pale selected border against a nearly identical card background can fail even when the tier label itself is readable.
Turn the results into SHIP, SIMPLIFY, REPOSITION, or HOLD
Do not calculate a percentage score that lets a cart mismatch disappear inside 17 passes. Route the result by severity.
| Decision | Use it when | Next action |
|---|---|---|
| HOLD | Any transactional hard gate fails, a required action is unusable, or required information disappears | Fix the implementation and rerun the failed path before sending traffic |
| REPOSITION | The widget and cart state work, but the page sequence, sticky control, or overlay separates the selection from the purchase action | Move the app block or resolve the overlapping element, then rerun Tests 9–13 |
| SIMPLIFY | All hard gates pass, but three or more density, clarity, control, or feedback tests fail | Remove repeated content and reduce interaction load without hiding the total or qualifying rule |
| SHIP | Every hard gate passes and no more than two nonblocking issues remain with an owner and follow-up date | Publish, monitor by device, and revisit the open items |
These cutoffs are a release heuristic, not a conversion model or accessibility certification.
Consider a three-tier skincare offer:
- The cards fit at 390 pixels.
- The selected tier is clear.
- Selecting Buy 3 opens three flavor dropdowns.
- A sticky Add to cart bar covers the third dropdown.
- The cart is correct when the shopper manages to complete all three selections.
That is REPOSITION, not SHIP and not a pricing failure. The transaction logic works, but the mobile sequence blocks a required choice.
Now consider the same page with all controls available, but the cart receives three copies of the default flavor instead of the selected mix. That is HOLD. Making the cards shorter does not repair the broken handoff.
What to simplify first
When the widget is too tall, preserve the information needed to make and verify the purchase:
- quantity;
- selected state;
- unit price when it helps comparison;
- total price;
- exact qualifying rule;
- required variant controls;
- Add to cart relationship.
Compress or remove these first:
- a subtitle that repeats the tier title;
- multiple badges saying “Popular,” “Best Value,” and “Most Savings” on one card;
- repeated savings in the badge, subtitle, unit price, and footer;
- decorative icons without a decision role;
- long benefit lists repeated across every tier;
- tooltips explaining rules that could be stated once above the choices.
The aim is not minimalism. It is one clear job per element.
If the total price disappears when you remove copy, you simplified the wrong thing. If a shopper cannot tell why the third tier qualifies, the compact version is not clearer—it is merely shorter.
Handle variants without turning every tier into a separate form
Variant controls are where a clean three-card design can become a long mobile form.
Kaching documents that merchants can use dropdowns or customized variant swatches, including colors, uploaded images, or product images, and adjust swatch size and shape.
Use swatches when the option is genuinely visual and a shopper can distinguish the values. Use a dropdown when:
- labels are long;
- options are not visual;
- there are many values;
- similar colors need explicit names;
- several selectors must fit inside one tier.
Do not hide the label because the swatch image seems obvious. “Vanilla,” “Unscented,” and “Coconut” are not reliably communicated by three pale circles. Keep an accessible and visible name for each choice.
For multi-item selection, show enough progress to answer two questions: which item am I choosing now, and which items are already complete? If changing the tier resets prior choices, make that reset visible before Add to cart.
Keep sticky Add to cart from covering the deal
Start with the product-form sequence:
Required product variants → quantity-break tier → tier-level variants → Add to cart
A sticky control can mirror the final action, but it should not cover a selector or introduce a conflicting price. Check the state with the browser keyboard open, a cookie notice visible, and chat minimized and expanded.
If overlap is the only failure, move or restyle the conflicting element. Kaching documents that its widget can be repositioned with an app block or placed through its snippet. The app-block route is the safer no-code starting point because custom placement must preserve the correct product, form, and submit-button context.
Do not move the visible widget into an unrelated section while leaving the functional purchase form behind and assume the connection will survive. After repositioning, rerun the selected-tier, variant, cart, and price hard gates.
Read Core Web Vitals without blaming one widget
Use two views:
Diagnostic view
Compare a stable page before and after the quantity-break implementation under the same test conditions. Look for:
- a widget that appears late and pushes the button down;
- tier interactions that take noticeably longer to respond;
- heavy images loaded for every swatch or tier;
- repeated initialization after variant changes;
- a sticky control that shifts when the widget height changes.
This view helps locate a regression. It does not prove the real-user percentile.
Field view
Use Shopify’s web-performance reports once sufficient real-user data exists. Review the most relevant product page and device segment over a stable period. A field regression deserves investigation, but isolate other changes made during the same window: theme edits, review apps, media, analytics, or campaign scripts.
Do not chase a perfect score by removing information shoppers need to understand the purchase. Shopify’s guidance explicitly frames performance as a balance between useful storefront features and their cost.
Where Kaching fits
Kaching already supplies controls that can resolve many of the failures in this checklist.
| Failure found | Relevant Kaching control | Boundary |
|---|---|---|
| Cards are too dense | Multiple layouts, text and styling customization, custom CSS/HTML | The merchant still decides which information can be removed safely |
| Variant controls are unclear | Dropdowns or swatches with adjustable size, shape, colors, or images | Visual controls still need labels, contrast, and correct state |
| Savings require arithmetic | Live savings summary that updates with tier and upsell selection | Another summary row can add height or contradict weak tier copy |
| Widget conflicts with page sequence | App-block or documented snippet placement | Custom placement must preserve the product-form context |
| Merchant needs deeper interaction tracking | Documented deal and variant events | Instrumentation normally requires analytics or developer work |
| Merchant wants to compare layouts | Built-in A/B variants can change layouts and other bundle details | Current documentation does not describe mobile-only traffic targeting |
The Kaching App Store listing documents multiple layouts, extensive customization, custom CSS/HTML, quantity breaks, and A/B testing. Kaching also documents live tier, variant, and savings behavior relevant to a mobile buying flow.
ShopSideK has not independently benchmarked Kaching across every theme and device. The recommendation is based on the current feature fit: Kaching gives you the controls to implement the fix, while the 18-test matrix tells you what the selected configuration must preserve.
Kaching is not the right fix when the problem is an unprofitable discount, a fundamentally confusing offer, or a true inventory-managed bundle that needs another product architecture. In those cases, repair the economics or choose the correct bundle model before optimizing the widget.
If Kaching’s control set matches the failures you found, claim 20% OFF Kaching for your first 3 months. Use the ShopSideK form on that page to receive the code.
If you prefer to inspect the listing first, you can also view Kaching on the Shopify App Store.
Final launch sequence
- Confirm that the offer economics and tier quantities are already approved.
- Use Shopify’s mobile theme preview for the first visual pass.
- Run all 18 tests against the most demanding relevant tier and variant state.
- Refuse to average away any transactional hard failure.
- Assign SHIP, SIMPLIFY, REPOSITION, or HOLD.
- Apply one class of fix and rerun the affected hard gates plus cart/checkout.
- After launch, review mobile behavior and field performance separately from desktop.
The decision is simple even when the page is not: ship only when the selected quantity-break state remains clear and correct through the purchase.
Frequently asked questions
How many quantity-break tiers should show on mobile?
There is no universal number. Use only the tiers that represent distinct and profitable purchase choices, then run the reflow, selected-state, variant-height, and purchase-sequence tests. Three short tiers can be easier than two tiers with several selectors and repeated benefit lists.
Should Shopify quantity breaks use cards or a table on mobile?
Cards are usually easier when each tier is selectable and needs a visible state. A compact table can work for straightforward price comparison, but it should not require horizontal scrolling or separate the chosen row from Add to cart. The better format is the one that passes the complete selection and cart path.
What is the minimum mobile tap-target size?
WCAG 2.2’s Level AA Target Size (Minimum) criterion specifies 24 by 24 CSS pixels, with defined exceptions. Treat that as the formal minimum, not a universal comfort target. Increase size or spacing when closely packed controls still invite misclicks.
Should the total price stay visible in a quantity-break widget?
Yes. Per-unit pricing can help compare tiers, but shoppers should still be able to identify the total amount attached to the selected quantity before adding it to the cart.
Can Kaching A/B test mobile layouts?
Kaching documents A/B testing for layouts, deal setups, prices, images, and button text. It splits bundle traffic according to the configured allocation. Its current documentation does not describe targeting an experiment only to mobile visitors, so do not treat it as a documented device-only test.
Does passing this checklist prove the widget will increase conversion?
No. It shows that the implementation cleared the stated mobile release checks. Conversion, AOV, and contribution outcomes still depend on the product, offer economics, traffic, message, and store-specific behavior.
