Pricing

How To Price A Bundle

TL;DR

A cart offer carries exactly one bundle discount rule, and there are two kinds. percent_threshold — "take any 3, save 15%" — pulls the number of items in an order up. fixed_bundle — "all five for $199" — turns the whole set into a single decision. They answer different questions and they cost you in different places. Here is how I'd choose.

Last week I wrote about selling several things on one page — what a cart offer is, how to build one, and the counting rule you have to get right. This post is the decision that comes after the build: which discount to put on it, and what that choice does to your money.

A cart holds 2 to 10 one-time products. The buyer ticks what they want and pays once. You may attach exactly one bundle discount rule, and there are two kinds of rule. They are not two settings for the same idea. They pull on different parts of your order.

The two rules are different shapes

percent_threshold is a gate on a count. min_items decides where the gate sits, percent_off_bps decides what is on the other side of it. The buyer's decision is marginal and repeated: is one more worth it? Every tick moves them closer to the gate, and once they are through, they are through — there is one percentage, not a ladder of them.

fixed_bundle is a swap. Instead of a run of separate yes-or-no decisions, there is bundle_price_cents — one number for the lot — and the buyer weighs it against what the pieces cost individually. One decision, taken once.

That difference in shape is the whole post. Everything below follows from it.

The two bundle rule kinds are two different shapes of buyer decision On the left, percent_threshold is drawn as a row of five tickable items with a dashed gate after the third, marked min_items equals 3; below it, under three ticks means full price and three or more means save fifteen percent. On the right, fixed_bundle is drawn as five small item boxes whose arrows all converge into one large box reading $199, one price for the set. Rule 1 · percent_threshold min_items = 3 Under 3 → full price 3 or more → save 15% One gate, crossed by adding Rule 2 · fixed_bundle five items $199 for the set One decision, taken once
Same cart, two different questions. The gate on the left is crossed by accumulating; the swap on the right is taken in one go. A buyer can approach the left rule gradually and can only accept or refuse the right one.

What each one does to your numbers

Two numbers move when you add a bundle rule, and they do not move together. The first is how many items an average order carries. The second is what an average order is worth.

percent_threshold is aimed at the first. It is broad and shallow: it touches a lot of orders, a little. A buyer holding two items has a live reason to look for a third, and the third is a smaller decision than the first two were because the discount is waiting on the other side of it.

fixed_bundle is aimed at the second, and only for the buyer who takes everything. It is narrow and deep. It does nothing at all for the person who wants two of your five products — they pay full price and never see the rule fire.

Take any 3, save 15% All five for $199
Rule kind percent_threshold fixed_bundle
The question Will they take one more? Will they take the lot?
What it moves Items per order The value of the orders it converts
Who it reaches Every order that meets the count Only the whole-set buyer
What it costs you The same discount handed to buyers who were always going to qualify The gap between your bundle price and the separate total
What the buyer weighs One more item against the saving The set against buying the pieces

Which one your orders are asking for

Look at the shape of what you already sell, then pick the rule aimed at the bigger population.

If almost every order is a single item, percent_threshold has somewhere to go — but set the gate one step above where your orders already sit, not four. A gate at three items when nearly nobody buys two is a gate nobody reaches, and an unreached gate is just a sentence on your page.

If you already have a cluster of buyers taking most of the set but not all of it, fixed_bundle is the rule that finishes the job. Those buyers have done the comparison in their heads already; you are giving them a price to compare against.

Now the honest part, which is the same problem seen from both ends. percent_threshold gives the discount to the buyer who was always going to take three. You cannot aim it only at the person it changes, so the real question is whether the extra items you buy are worth more than the margin you hand to the people you never needed to persuade. fixed_bundle has the mirror flaw: it is perfectly targeted at the whole-set buyer and completely absent for everyone else.

There is no rule that solves both. That is not a gap in the product, it is what pricing is.

The refusal that is doing you a favour

The server will not save a fixed_bundle whose price is not below what the items cost separately. Send one and it comes back rejected.

The first time that happens it feels like the software second-guessing you. It isn't. A bundle priced at or above the separate total is not a discount, it is a penalty for buying the convenient way — and nothing on the page would tell you. The maths still adds up. The checkout still looks right. The only person who notices is the buyer who does the sum, and what they conclude is either that you are careless or that you are trying it on. Neither of those is recoverable with a follow-up email.

That check runs when you save the rule. So the moment to think about it again is later, when you cut the price of one product for an unrelated reason. Do the sum yourself before the bundle quietly stops being one.

The same spirit covers the other refusal. The two rule kinds do not mix: min_items and percent_off_bps belong to percent_threshold, bundle_price_cents belongs to fixed_bundle, and passing the wrong field is an error rather than a silent ignore. A silently ignored discount field is the worst outcome available here — you would advertise a saving, the buyer would be charged full price, and you would find out from a complaint.

What the server checks when you save a bundle rule A downward flow. You save a bundle rule, one per cart. First check: do the fields match the rule kind? If not, it is rejected on save as an error, never a silent ignore. Second check, for fixed_bundle only: is the bundle price cheaper than the items separately? If not, it is rejected because it would not be a discount. Only after both checks pass is the rule saved. You save a bundle rule one per cart Fields match the kind? one kind's fields only No → rejected on save an error, never a silent ignore Cheaper than separate? fixed_bundle only No → rejected it would not be a discount Rule saved a real discount
Both refusals happen at save time, on the server, before a buyer ever sees the page. The second one compares your bundle price against the items added up — which is why a bundle that costs more than its parts cannot be saved at all.

The $0.50 floor

Nothing can take a charge below $0.50. That is Stripe's minimum, not a GoCushy opinion, and it sits underneath every rule on this page.

In practice it only bites at one end of the market, but it bites hard there: a bundle designed as a token-price tripwire has a floor it cannot go under. If your pricing idea depends on charging ten cents, it is not going to work here, and it is better to know that before you build the page than after.

One rule per cart, and why that is the right limit

A cart carries exactly one bundle discount rule. Not one of each kind, not two of one. One.

I have used systems that let you stack discount rules and I would not build one again. The moment two rules can both fire, the order they apply in becomes a thing you have to know, the total stops being predictable from the page, and the merchant ends up reverse-engineering their own pricing from a receipt. Every hour spent on that is an hour not spent selling.

With one rule the total is a short computation with no branches worth arguing about: your prices, then the rule, then the floor. You can say what a buyer will pay in one sentence — which happens to be the same sentence you put on the page. And it forces the decision. If you cannot choose between "any 3 for 15%" and "all five for $199", you have not yet decided what you want the buyer to do.

Where the price is actually worked out when a buyer ticks items The buyer's browser, on the left, sends only which items were ticked and no prices. A dashed line marks the boundary to the GoCushy server, where three steps run in order: look up your prices, apply the one rule, and never go below fifty cents. The result is the total charged. Browser Buyer ticks items 2–10 in a cart no prices GoCushy server 1 · Look up your prices 2 · Apply the one rule 3 · Never below $0.50 The total charged
Three steps, always in this order, always on the server. The browser sends which products were ticked and never what they cost — so the price your rule produces is the price that gets charged, and a buyer editing the page has nothing to edit.

Where neither rule is the answer

I would rather tell you this now than have you discover it while building.

A bundle rule is a count and a percentage, or a price for the set. That is the entire vocabulary. There are no dates in it, no redemption caps, no targeting by customer. If your discount needs to expire on Friday or stop after fifty people, a bundle rule is not where that lives.

The cart around it has limits worth pricing into your plan too. It holds 2 to 10 products, all of them one-time, so a subscription cannot go in one. It takes card and PayPal. It cannot carry an order bump — bumps belong to single offers, and a cart's own items already do that job.

And the largest one, which is not a software limit at all: if your products do not belong together, no rule fixes that. A discount on a set nobody wants is a cheaper version of something nobody wants. Bundle rules make an existing reason to buy more items easier to act on. They do not manufacture the reason.

How I would actually decide

Two questions, in this order.

First: do I want more items in the average order, or more value out of the buyers who already want everything? That picks the rule kind and there is no third answer.

Second: is the discount cheaper than the behaviour it buys? For percent_threshold, that means counting the buyers who qualify without changing anything. For fixed_bundle, it is the gap between your price and the separate total — and the server has already made sure that gap points the right way.

Then set one rule, write the sentence for the page, and leave it alone long enough to learn something from it.

See a cart checkout working →

Sam Bakker
Sam Bakker is the founder of GoCushy. He's spent a decade building funnel software for creators, and is based in New Zealand.