You can assign a different subscription plan to each Shopify quantity tier by using a product variant as the link between the tier and its selling plan. In Kaching, that means creating the recurring plans in Kaching Subscriptions, then choosing the corresponding default variant for each quantity break in Kaching Bundles.
But do not start by creating “monthly,” “quarterly,” and “yearly” plans. First ask what each quantity actually represents. Three packs may last one customer for three months—or a three-person household for one month. Only the first case supports a longer delivery interval.
⚡ ShopSideK Verdict
Use Kaching Bundles & Upsells with Kaching Subscriptions when each approved quantity tier should select its own recurring plan through a dedicated variant.
Best for: Consumables or replenishable products where pack size produces a reasonably predictable days-of-supply range.
Decision path: Estimate supply duration → choose SAME CADENCE, TIER-SPECIFIC CADENCE, or DO NOT MAP → build the variant-to-plan mapping → validate the first order and subscription contract.
Important boundary: This setup requires both Kaching apps. The ShopSideK discount below applies to Kaching Bundles, not Kaching Subscriptions.
First decide whether quantity should change the delivery cadence
A larger tier does not automatically deserve a longer interval. The right interval depends on how quickly the customer is likely to use the shipment.
There are three common patterns.
The same customer receives more days of supply
Suppose one package contains 30 servings and the typical customer uses one serving per day:
- one package supplies about 30 days;
- three packages supply about 90 days;
- six packages supply about 180 days.
Monthly, every-three-months, and every-six-months plans are plausible candidates. They are not approved yet; shelf life, delivery buffer, customer variation, price, and fulfillment economics still need to pass.
More people consume the larger tier
Now suppose three people share the three-pack and each uses one serving per day. Those 90 servings still supply only about 30 household-days.
Moving this tier to an every-three-months plan would create a long gap between deliveries. The larger tier may need the same monthly cadence as the one-pack option.
Use is too variable to support a reliable mapping
Some products are purchased for events, gifts, seasonal needs, irregular projects, or changing household demand. A fixed tier-to-frequency mapping can create more confusion than convenience.
In that case, keep the quantity offer and subscription frequency as separate choices—or avoid the combined architecture. A clean “Do not map” decision is better than a plan that looks tidy in the app but produces stockouts, excess supply, or cancellations.
Use the Tier-to-Subscription Cadence Mapper
Build one row for every proposed quantity tier. You can use a spreadsheet, but the model is simple enough to start on paper.
Record:
- tier quantity;
- usable units or servings per package;
- low and high daily use across all users;
- number of users;
- shelf-life or practical storage limit;
- desired delivery buffer;
- candidate delivery interval;
- plan-anchor variant;
- first-order and recurring price;
- recurring contribution floor.
Estimate the supply range with ordinary arithmetic:
Estimated days of supply = tier quantity × usable units per package ÷ daily use across all users
Use at least two consumption estimates. The lower-use estimate produces the longer supply duration; the higher-use estimate produces the shorter duration.
For example, three 30-serving packages provide:
- 112.5 days at 0.8 serving per day;
- 90 days at 1 serving per day;
- 75 days at 1.2 servings per day.
An every-three-months plan sits near the center of that range. That does not make it correct for every customer, but it is more defensible than choosing “quarterly” because the tier contains three packages.
Route each tier to one of three decisions
| Decision | Use it when | What to do next |
|---|---|---|
| SAME CADENCE | Quantity increases because there are more users or higher use, so days of supply stays broadly similar | Keep the same delivery frequency; differentiate the tier by quantity and price |
| TIER-SPECIFIC CADENCE | The same user group receives materially more days of supply and the proposed interval fits the supply range after a buffer | Create a dedicated variant and selling plan for the tier |
| DO NOT MAP | Use is too variable, storage or shelf life conflicts with the interval, variants must remain freely selectable, or economics fail | Keep quantity and cadence separate, simplify the offer, or do not launch it |
The buffer matters because customers do not consume products with machine-like consistency. If the shortest realistic supply estimate is 75 days, scheduling delivery exactly every 75 days leaves no room for faster use, damaged units, delayed fulfillment, or changing routines.
The mapper is a planning tool, not a prediction of individual consumption. Give customers clear plan terms and an appropriate way to manage their subscription. Kaching’s subscription overview documents customer actions such as skipping, pausing, resuming, or canceling, but flexible controls do not excuse an unreasonable default cadence.
Approve recurring economics separately
Days of supply tells you whether the cadence is operationally plausible. It does not tell you whether the tier is profitable.
Calculate the expected contribution from each recurring shipment:
Recurring contribution per shipment = recurring revenue − product cost − revenue-linked fees − pick and pack − packaging − shipping subsidy − expected returns or replacement allowance
Use the actual quantity and recurring price for that plan. Do not approve the largest tier by applying the one-pack margin percentage to a bigger subtotal. Shipping steps, heavier packaging, free-shipping thresholds, payment fees, and replacement exposure can change with quantity.
Also separate the first charge from later renewals:
- What does the customer pay today?
- What will each later shipment cost?
- Is the first-order incentive repeated or introductory?
- Do the plan name and terms make that difference obvious?
Shopify’s subscription UX guidance says the product page should make plan selection, pricing, and plan details clear, and that product-page, cart, and checkout information should remain consistent. If the initial price differs from future payments, communicate both rather than letting the first charge dominate the decision.
Do not add a longer prepaid commitment merely to protect first-order economics. A prepaid plan changes the customer’s commitment and cash flow, not just the delivery label. Kaching Subscriptions supports both pay-per-delivery and prepaid structures, so name and test the actual structure you create.
How the Shopify and Kaching architecture works
The method works because Shopify can associate subscription selling plans with products and variants.
Shopify describes subscriptions as selling plan groups and selling plans. A selling plan contains policies for billing, delivery, and pricing. A selling plan group organizes the related choices and can be associated with specific product variants.
For this Kaching setup, the variant becomes the bridge:
Quantity tier → default product variant → selling plan group → subscription plan
Imagine a product with these internal variants:
- Single — Monthly
- Three-pack — Every 3 months
- Six-pack — Every 6 months
Each variant is associated with the corresponding selling plan group in Kaching Subscriptions. Each quantity tier in Kaching Bundles then uses the matching variant as its default.
The shopper sees a quantity-and-subscription offer. Behind the scenes, the selected variant determines which selling plan is available.
This is why the setup requires both apps:
- Kaching Bundles provides the visible quantity breaks and maps each break to a default variant.
- Kaching Subscriptions provides the selling plan groups, billing and delivery schedules, and recurring subscription behavior.
The architecture also explains why variant state deserves careful testing. If a theme selector, per-item variant choice, or stale selection changes the anchor variant, the visible tier and subscription plan can fall out of sync.
How to set a different subscription plan for each quantity tier
The steps below follow Kaching’s current tier-specific subscription tutorial, with decision and QA gates added.
1. Create one plan-anchor variant for each approved mapping
Create a distinct product variant for every tier that needs its own selling plan. Use operationally clear titles so your team can identify the mapping in the admin, cart, order, and contract.
For example:
- 1 pack — Monthly
- 3 packs — Every 3 months
- 6 packs — Every 6 months
The customer-facing plan name should describe the real delivery frequency. Shopify’s UX guidance recommends treating selling plan names as plan information, not as a marketing field. If a plan is prepaid, include the prepaid period where needed.
Do not create variants for cadences that failed the mapper. More variants make the setup harder to audit; they do not improve the offer.
2. Create the selling plan groups in Kaching Subscriptions
In Kaching Subscriptions, create a selling plan group for each approved variant and configure:
- billing interval;
- delivery interval;
- pay-per-delivery or prepaid structure;
- initial and recurring pricing or discount;
- customer-facing plan name and terms.
Then assign each group to its corresponding product variant. Do not associate every plan with every anchor variant, because the purpose of the architecture is to make the relevant plan follow the tier.
3. Create the quantity breaks in Kaching Bundles
Select the same product in Kaching Bundles and enable the Subscriptions bar. Add the approved quantity breaks and their pricing.
Keep the tier labels consistent with the plan:
- “1 pack — delivered monthly”
- “3 packs — delivered every 3 months”
- “6 packs — delivered every 6 months”
Avoid copy that says only “best value” or “most popular.” Those labels do not tell the customer what will arrive or when the next charge occurs.
4. Assign the matching default variant to each break
For each quantity break, choose the plan-anchor variant that belongs to it:
- quantity 1 → Single — Monthly;
- quantity 3 → Three-pack — Every 3 months;
- quantity 6 → Six-pack — Every 6 months.
This is the critical mapping step. Review every tier rather than assuming the order of variants matches the order of quantity breaks.
5. Remove conflicting variant choices
For this documented implementation, Kaching instructs merchants to:
- hide the theme’s product variant picker;
- disable “Let customers choose different variants for each item.”
Those settings prevent a customer-facing variant choice from overriding the tier’s plan-anchor variant.
This limitation matters. If your product genuinely requires shoppers to choose different sizes, colors, flavors, or other variants for each item in a tier, a hidden and fixed anchor variant may not fit the buying experience. Do not remove a necessary product choice just to preserve the mapping. Redesign the product/variant structure or keep subscription frequency separate.
6. Save, publish, and run a real test path
An app preview is not the release gate. It does not prove that the correct selling plan reaches cart, checkout, and the created subscription contract.
Save the configuration, then run every live tier through the 12-check matrix below. Use a test order where your store and payment configuration permit it, and inspect the resulting subscription record.
Run the 12-check First Order and Renewal QA Matrix
Test each tier independently. A monthly one-pack passing does not prove the quarterly three-pack or six-month six-pack is correct.
| Check | What to inspect | Pass condition |
|---|---|---|
| 1 | Variant anchors | Every approved tier has one uniquely named anchor variant |
| 2 | Selling plan associations | Each plan group is assigned only to the intended variant |
| 3 | Kaching default variants | Every quantity break selects the correct anchor variant |
| 4 | Theme variant picker | The conflicting picker is hidden for this implementation |
| 5 | Per-item variant choice | “Let customers choose different variants for each item” is disabled |
| 6 | Initial product-page state | Quantity, cadence, first price, recurring price, and selected tier agree |
| 7 | Tier switching | Changing tiers updates the variant, available plan, price, and visible selected state |
| 8 | Cart | Product, variant, quantity, selling plan name, and first charge match the selection |
| 9 | Checkout | Delivery wording, first charge, and recurring subtotal match the intended plan |
| 10 | Created contract | The test order creates the correct subscription contract |
| 11 | Renewal state | Recurring quantity, price, interval, and next charge or delivery date are correct |
| 12 | Change policy | The team knows what happens to existing contracts before editing or retiring a plan |
Use three outcomes:
- LAUNCH: All 12 checks pass for every tier you will publish.
- FIX AND RETEST: The underlying mapping is correct, but labels, visible pricing, or selected-state communication are not.
- HOLD: Any variant, plan, quantity, charge, interval, contract, or next-date mismatch remains.
Do not average the results. One broken tier is not offset by two working tiers. Remove or repair the failed tier before sending traffic.
Watch for a recurring-subtotal mismatch
Kaching documents a specific case where a combined bundle and subscription can show the correct first charge but a misleading recurring subtotal before the discount.
That does not mean every setup has the problem. It means the recurring subtotal deserves its own QA row.
Kaching’s documented workaround uses final prices in the plan-anchor variants, maps those variants to the corresponding bundle options, hides the theme variant picker, and disables different variants per item. If you use that route, rerun the complete matrix. Fixing the displayed subtotal must not introduce a different variant, contribution, or contract error.
Understand what happens when a selling plan changes
A selling plan and a subscription contract are related, but they are not the same object.
Kaching’s plans-versus-contracts guidance explains the distinction:
- the selling plan is what a new customer selects at checkout;
- the subscription contract is the ongoing Shopify record created after the first order;
- later recurring orders are generated from that contract.
Editing or deleting a selling plan generally changes what future customers can select. Do not assume that existing subscription contracts inherit the new price, quantity, or cadence.
Before changing a live tier:
- identify the affected anchor variant and selling plan;
- decide whether the change is for new subscribers only;
- count and review existing contracts tied to the old configuration;
- define how customers will be informed if a contract change is necessary;
- use the appropriate Kaching/Shopify contract process rather than silently relying on the plan edit;
- test one controlled result before applying a broader change.
This policy is especially important when you retire a tier. Removing the storefront option does not by itself prove that current subscribers have moved to another contract.
Measure the tiers after launch
Passing QA proves that the implementation does what you configured. It does not prove that the cadence is good for customer behavior or contribution profit.
Track each mapping by its anchor variant where your reporting permits. At minimum, compare:
- new subscription starts;
- first-to-second renewal rate;
- skip and pause behavior;
- cancellation or expiration;
- support contacts related to excess supply or early depletion;
- recurring contribution per shipment;
- refunds, replacements, and shipping exceptions;
- plan changes between tiers or cadences.
Kaching’s retention analysis can help merchants compare subscription cohorts and states such as active, paused, canceled, or expired. Its documentation does not establish a universal “good” retention number or an automatic tier-specific causal result.
Compare like with like. A six-pack plan may attract a different customer from the one-pack plan. Better retention in one tier does not prove the cadence caused it; price, commitment, product affinity, acquisition source, and household size may differ.
Use the results to revise the mapping:
- repeated early skips can indicate excess supply or an interval that is too short;
- cancellations after the first shipment can indicate an introductory-price or commitment problem;
- support requests about running out can indicate an interval that is too long;
- healthy renewals with weak contribution can indicate a pricing or fulfillment problem, not a cadence problem.
Where Kaching fits—and where it does not
| Need | Kaching fit |
|---|---|
| Display quantity tiers on the product page | Kaching Bundles is a direct fit |
| Give each approved tier a dedicated default variant | Documented in Kaching’s setup |
| Associate each anchor variant with a recurring plan | Kaching Subscriptions provides the selling plan groups |
| Decide whether three packs represent one or three months | Not an app decision; use consumption and household data |
| Choose a profitable first and recurring discount | Not an app decision; approve contribution separately |
| Keep freely mixed variants inside every tier | Potential non-fit for this fixed anchor-variant method |
| Update existing subscribers by editing the storefront plan | Non-fit; existing contracts require a deliberate policy |
| Guarantee checkout and renewal accuracy without testing | Non-fit; run the complete QA matrix |
Kaching is a strong implementation candidate when the product has a predictable replenishment pattern, each approved tier can use a dedicated anchor variant, and both apps fit your operating model.
It is a weaker fit when customers must freely mix variants within the tier, consumption varies too widely for a sensible default, or your team cannot maintain the plan-to-contract boundary.
If the quantity-tier layer fits, you can claim 20% OFF Kaching for your first 3 months. That offer is for Kaching Bundles. If you prefer to inspect the listing first, the linked app name in the Verdict Card opens Kaching’s Shopify App Store page.
Final launch sequence
- Estimate a days-of-supply range for every proposed tier.
- Classify each tier as SAME CADENCE, TIER-SPECIFIC CADENCE, or DO NOT MAP.
- Approve the first-order and recurring contribution separately.
- Create only the anchor variants and plans that passed.
- Map each Kaching quantity break to the corresponding variant.
- Remove conflicting variant controls only if shoppers do not need them.
- Run all 12 QA checks for every live tier.
- Document how future plan edits will affect new buyers and existing contracts.
- Monitor renewal behavior and contribution by anchor variant.
The goal is not to make the largest tier renew as slowly as possible. It is to make each tier’s quantity, supply period, price, delivery schedule, and ongoing contract tell the same story.
Frequently asked questions
Can Shopify use a different subscription plan for each quantity tier?
Yes. Shopify selling plans can be associated with product variants. Kaching documents a method that creates a variant for each tier-plan combination, associates the corresponding selling plan group, and assigns that variant as the default for the matching Kaching quantity break.
Do I need both Kaching Bundles and Kaching Subscriptions?
Yes, for the method documented in this guide. Kaching Bundles creates and displays the quantity tiers. Kaching Subscriptions creates the selling plan groups and recurring schedules. The ShopSideK 20% offer applies to Kaching Bundles, not Kaching Subscriptions.
Does a larger quantity tier need a longer delivery interval?
Not always. Estimate days of supply using total units, daily use, and number of users. A three-pack may last one person three months or three people one month. Use a longer interval only when the quantity genuinely extends supply for the same user group.
Will editing a selling plan update existing subscribers?
Generally, no. The selling plan controls what new customers select, while an existing subscriber is governed by a subscription contract created after checkout. Audit and update existing contracts deliberately instead of assuming a selling-plan edit changed them.
Why can the recurring subtotal differ from the first charge?
Bundle pricing, variant prices, and subscription discounts can create a case where the first charge is correct but the recurring subtotal displayed at checkout is misleading. Kaching documents a variant-price mapping workaround. Treat this as a setup-specific issue, fix it using current documentation, and retest the product page, checkout, and contract.
Can customers choose different variants for each item?
Not with Kaching’s documented fixed anchor-variant implementation. The setup instructs merchants to disable different variants per item and hide the theme variant picker so the tier remains mapped to the intended plan. If mixed variants are essential, redesign the architecture or keep quantity and subscription frequency as separate choices.
How this guide was researched
ShopSideK reviewed current Kaching and Shopify documentation on July 27, 2026. The Tier-to-Subscription Cadence Mapper and 12-check QA Matrix are ShopSideK editorial models. All consumption, pricing, and cadence numbers are hypothetical; they are not presented as store results or universal recommendations.


