The Online Store Made Us Sell Backwards
Here's how a bag of pretzels gets sold at a farmers market.
Someone walks up. They try a sample of the Garlic Parmesan and reach for their wallet. You say, "Two bags are fifteen." They look at the table again, pick a Maple Bourbon to go with it, and hand you a twenty.
They picked the flavor first. The deal came second, and the deal is what turned one bag into two.
Now put that same sale online. On most store platforms, the customer hits the pricing rule before they ever touch a flavor: choose your bundle size, then pick what goes in it. Same products, same prices, same discount — and the sale runs in reverse.
That's the problem we ran into building the storefront for Back 40 BBQ, a double-smoked pretzel company in Holland, Michigan. It's worth explaining, because almost every small business that sells on a volume ladder eventually hits it.
The pricing that causes the trouble
Back 40 sells the way a booth sells. One 4oz bag is $8, two are $15, three are $22, four are $28. There's a separate ladder for 8oz bags.
Two details make this hard to put online:
The discount pools across flavors. One Garlic Parmesan and one Maple Bourbon isn't two separate $8 purchases. It's two 4oz bags — $15.
Both ladders can run at once. A cart with three 4oz bags and two 8oz bags should get the three-bag 4oz price and the two-bag 8oz price, simultaneously, in one order.
That is completely ordinary at a table. It is not ordinary in a shopping cart.
What the platforms actually do
I want to be fair here, because "no platform can do this" is an easy thing to say and not quite true.
Shopify has volume-discount apps, and someone comfortable writing a discount Function can build tiered pricing that spans variants. Wix Stores has quantity discounts. Square has category-level discount rules. None of these platforms are incapable in some absolute sense.
But the native, no-code, follow-the-documentation path in all of them runs per-product or per-cart-total. Pooling a tier across several different products, by size, with two independent ladders resolving at the same time, isn't the shape their discount engines are built around. You get there by adding an app, hiring someone to write custom discount logic, or accepting the workaround.
Most small businesses accept the workaround. It's free and it's right there.
The workaround, and what it costs
The workaround is to turn the bundle into a product. Instead of pricing rules, you create a "3-Pack" and let the customer choose three flavors inside it.
This works on every platform. It's also where the trouble starts.
You can't mix sizes. A 3-Pack is three 4oz bags. A customer who wants two 4oz and two 8oz has to buy two separate bundles, and neither one lands on the right tier.
Adding a bag is destructive. Someone with a 3-Pack in their cart who decides they want a fourth can't just add one. They delete the 3-Pack and rebuild it as a 4-Pack.
Inventory drifts. Square tracks the 3-Pack, not the Maple Bourbon bags inside it. Your stock counts stop matching the shelf.
And it inverts the sale. The customer has to commit to a number before they know what they want. The moment that makes the booth sale work — pick a flavor, then find out two is fifteen — never happens.
That last one isn't a technical complaint. A pricing ladder is a sales tool. It works by rewarding a decision the customer is already leaning toward. Front-load it, and it stops being a reward and turns into a form field.
What we built instead
We built the pricing engine rather than working around it. Three parts matter.
A cart that resolves live, in any order. Add any bag, any flavor, any size, whenever. The cart re-prices itself immediately and shows what tier the order is currently hitting. Nobody chooses a bundle size. They fill a bag the way they'd fill a bag at a table, and the price follows them.
Pooling and simultaneous ladders, handled properly. Different flavors of the same size combine into one tier. Mixed 4oz and 8oz orders get both tier prices at once. The ladders are configured to Back 40's actual numbers, not hardcoded into checkout, so they can change without a rebuild.
Pricing calculated on the server. This is the part customers never see and the part that matters most. The browser never submits a price. Totals are recomputed server-side at checkout, so a manipulated cart can't produce a discounted charge. The discount is then written back to Square as a named, itemized line on the real order record — so what the customer paid is visible inside Square's own reporting, not just ours.
A live-updating cart on its own is a nice interface over a number you can't trust. The server recompute is what makes it a payment system.
Every pricing scenario the client specified is covered by automated tests — 125 of them across pricing, shipping, coupons, and checkout — so a future price change can't quietly break an existing tier.
When this is worth doing, and when it isn't
Custom pricing logic is not the right answer for most stores. If you sell single items at single prices, use Shopify or Square Online and spend the money on photography instead.
It's worth building when the pricing is the sales strategy. Signs you're in that situation:
- Your discount structure is something you say out loud to customers, not something you list on a page
- You've been told by a platform, an app, or a developer to "just make it a bundle product"
- Your stock counts don't match your shelf because of how bundles are configured
- You're manually fixing orders after the fact because the site charged the wrong total
At that point you're not buying a feature. You're removing a tax you've been paying on every online order.
Frequently Asked Questions
Can Shopify or Square do buy-more-save-more pricing across different products?
Not through their standard built-in discount rules, which generally apply per-product or to a cart total. Cross-product tiered pricing is usually possible through a third-party app or custom discount code, but it isn't the default no-code path on any major platform.
What's wrong with just selling a "3-pack" bundle product?
Bundle products work, but they force the customer to choose a quantity before choosing what's in it, can't handle orders that mix product sizes, make it awkward to add one more item, and decouple your inventory counts from the individual products actually being shipped.
Why does pricing need to be calculated on the server?
Anything calculated in the browser can be altered in the browser. If the customer's device submits the price, a manipulated cart can charge less than it should. Recomputing the total on the server before payment means the displayed price is a preview and the charged price is authoritative.
Can a custom store still use Square for payments and reporting?
Yes. Back 40's storefront is custom-built but runs card payments through Square's Web Payments SDK, syncs with the Square catalog, and writes discounts onto Square order records — so the business keeps using the Square dashboard and reporting it already knows.
How much of a store has to be custom to get custom pricing?
Less than people expect. The pricing engine and checkout are the custom parts. Payments, inventory, and fulfillment can still run on existing services rather than being rebuilt.
The Bottom Line
Software has opinions about how you should sell, and most of the time you absorb them without noticing. A discount that has to be chosen up front instead of discovered along the way is a small change on a screen and a real change to the sale.
If your pricing is something you explain to customers in a sentence and your website can't do it, the website is the thing that should change.
See how the Back 40 BBQ storefront came together, or get in touch if your pricing is fighting your store.