Selling plans are Shopify's primitive for purchases that aren't a simple one-off: subscriptions, pre-orders, try-before-you-buy, and bundle sales all run on the same underlying model. Merchants introducing these patterns for the first time often ask which Liquid objects to reach for. Getting the naming right matters because selling plans touch product display, cart, checkout, and post-order fulfillment.
The selling-plan hierarchy
Three Liquid objects model the selling-plan space:
-
selling_plan_group- a collection of related selling plans (e.g., "Subscription" or "Try Before You Buy"). A group is what the merchant configures in admin; customers see it as a choice on the product page. -
selling_plan- a specific purchasing option within a group (e.g., "Deliver every 30 days at 10% off" or "Try for 7 days then charge"). Each plan has its own billing frequency, discount, and delivery policy. -
selling_plan_allocation- the relationship between a selling plan and a specific product variant, including the allocated price for that variant under that plan.
These three objects are what Liquid templates render, what customers pick between on the product page, and what carries through to checkout.
Try before you buy: which objects to use
A skincare brand wants to sell bundles under a "try before you buy" model. Customer receives the bundle, decides within a trial window whether to keep or return, payment captured only on keep.
Architecture:
- Selling plan group: "Try Before You Buy"
- Selling plan: "7-day trial, charge on day 8"
- Product variants: the bundle products, each configured as a selling-plan allocation under this group
In Liquid, rendering the selling plan choice on the product page:
{% for group in product.selling_plan_groups %}
<fieldset>
<legend>{{ group.name }}</legend>
{% for plan in group.selling_plans %}
<label>
<input type="radio" name="selling_plan" value="{{ plan.id }}" />
{{ plan.name }}
</label>
{% endfor %}
</fieldset>
{% endfor %}
The submitted form carries the selling plan ID into the cart; the cart line item reflects the selected plan and its allocated price.
Bundles inside selling plans
The skincare brand wants the try-before-you-buy experience to cover a bundle of 3 products, not just one. Two patterns:
Pattern 1: Bundle app + selling plan. A bundles app packages the 3 products into a virtual bundle product, and a selling plan attaches to the bundle product. Customer sees one "bundle" on the product page, picks the try-plan.
Pattern 2: Product with multiple variants reflecting bundle choices. For fixed bundles (same 3 products every time), create a product with one variant representing the bundle. For configurable bundles (customer picks 2 of 5 options), a bundles app is cleaner than trying to model every combination as a variant.
The merchant usually wants pattern 2 for simple, fixed bundles and pattern 1 when customers can customize.
Pre-order and try-before-you-buy side by side
A high-end clothing brand wants both:
- "Try Before You Buy" for stocked items
- "Pre-order" for items shipping in 6 weeks
Two selling plan groups cover this:
Group 1: "Try Before You Buy"
- Selling plan: "14-day trial, charge on day 15"
- Allocated to in-stock items
Group 2: "Pre-order"
- Selling plan: "Charge on order, ship on release date"
- Allocated to pre-order items
A single product can belong to multiple groups if both options apply. The product page shows both options side by side; the customer picks.
Rendering on the PDP:
{% if product.selling_plan_groups.size > 0 %}
{% for group in product.selling_plan_groups %}
<section class="selling-plan-group">
<h3>{{ group.name }}</h3>
{% for plan in group.selling_plans %}
<label>
<input type="radio" name="selling_plan" value="{{ plan.id }}" />
{{ plan.name }}
<span class="price">{{ plan.allocations[0].price | money }}</span>
</label>
{% endfor %}
</section>
{% endfor %}
{% else %}
<button type="submit">Add to cart</button>
{% endif %}
Customers who don't want either plan can add to cart as a one-off purchase (if standard purchasing is also enabled on the variant).
Shopify Functions for custom behavior
Standard selling-plan behaviors (fixed recurrence, fixed discount) are configured in admin. Custom rules require Shopify Functions:
- Custom discount logic - discounts that depend on cart composition, customer tier, time of day
- Custom delivery logic - shipping rules specific to a selling plan (pre-orders ship via different carrier)
- Custom cart transforms - a bundle selling plan that splits into individual line items on checkout for tax calculation purposes
Shopify Functions on the CLI ship as Rust or TypeScript, deploy as app extensions, and plug into the specific lifecycle points where custom logic applies.
Subscription apps
For full subscription products (recurring delivery and billing), merchants typically use a subscription app (Recharge, Shopify Subscriptions native app, Bold Subscriptions). The app handles:
- Subscription lifecycle (pause, skip, swap, cancel)
- Renewal billing
- Customer portal for self-management
The app configures selling plans automatically; the theme renders them via the same Liquid objects.
Customer portal considerations
For try-before-you-buy and pre-order, customers want:
- Visibility into the trial window / expected ship date
- Ability to adjust (extend trial, modify pre-order)
- Clear payment timing expectations
Customer account extensions (via Customer Account UI Extensions) surface this in the logged-in account section. The merchant extends the account with a page showing trial status and pre-order timeline.
What ships with selling-plan implementations
A production selling-plan rollout has:
- Selling plan groups configured to match merchant's product offerings
- Product-to-plan allocations correctly set for eligible variants
- Theme rendering selling plan choices on PDP with clear pricing
- Cart carrying the selected plan through to checkout
- Order lifecycle respecting the plan (no auto-charge for try, correct charge date for pre-order)
- Customer account pages showing the status of active selling-plan orders
- Fulfillment coordinated with the plan (delay ship, trigger on trial end)
Selling plans are foundational - they touch every stage from PDP to post-order. Setting them up carefully at the start is cheaper than retrofitting later.
