How To Price A Bundle
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.
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.
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 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.