How to Set Up a BOGO Offer on Shopify (2026)

Most articles about setting up BOGO on Shopify begin by recommending an app. That is usually premature. Shopify's native discount system handles a genuine buy X get Y, and a substantial share of merchants install and pay for an app to do something the platform already does.

This walks through what native covers, where it actually stops, and what the supported route is when you cross that line.

Setting up a native Buy X Get Y discount

In the Shopify admin, discounts live under Discounts, and the type you want is Buy X Get Y. The configuration asks for four things, and each has a trap worth knowing about.

What the customer buys. Specific products, specific collections, or a minimum quantity or amount. The trap here is variants: if a product has several variants and you set a minimum quantity, confirm whether the platform is counting across variants or within one. Merchants frequently intend "any two shirts" and configure something that requires two of the same size.

What the customer gets. The product or collection given free or discounted, and how many. Setting the discounted quantity higher than one is where offers become expensive quickly, so check the arithmetic on a large basket before saving.

How many times it can be used per order. This is the setting that most often produces a surprise. Left uncapped, a shopper adding ten qualifying items receives five free ones. That may be exactly what you want; it frequently is not.

Combinations. Whether this discount may combine with product, order or shipping discounts. Configure this deliberately. The default is not always what you would choose, and this is the most common cause of both unintended stacking and offers silently not applying.

Where native genuinely stops

Four limits, in rough order of how often they force a merchant to reach for something else.

Automatic gift insertion. Native discounts reduce the price of something already in the cart. They do not put a product there. If your offer is "spend ₹3,000 and receive a free tote", native requires the shopper to find and add the tote themselves — which most will not do, and the offer underperforms for reasons that look like disinterest but are actually friction.

Storefront messaging. Native discounts are silent until the cart. There is no product-page badge, no collection flag, no progress indicator counting a shopper toward a threshold. For threshold offers this is the difference between the offer working and not, because "you are ₹400 away from a free gift" does work that a static banner does not.

Conditional logic beyond the built-in fields. Offers conditioned on customer tag, order history, market, or a combination of cart properties are outside what the discount form expresses.

Complex tiering. Multi-rung ladders, where the reward changes at several thresholds, are awkward to express as several separate discounts that must be prevented from interfering with each other.

Crossing the line: Functions, not Scripts

When you do need custom logic, there is now one supported answer. Shopify Functions is the platform mechanism for custom discount behaviour: it runs server-side, applies at checkout, and holds through accelerated checkouts.

The alternative you may still find referenced is Shopify Scripts, the older Plus-only mechanism. It stopped running on 30 June 2026 (Shopify updates coverage, Fudge, retrieved 2026-09-02). Any guide recommending Scripts is out of date, and any store still relying on them has already had the problem.

The distinction that matters when evaluating an app, or a developer, is whether the discount is applied through Functions or by manipulating the cart. Cart manipulation — adding line items, rewriting the cart through the storefront, routing through draft orders — produces the failure mode where a discount is visible in the cart and absent at checkout, or is bypassed entirely by Shop Pay.

The honest reading of that table is that native and Functions together cover almost everything, and what apps genuinely sell is the storefront messaging layer plus not having to commission development.

Communicating the offer so it actually converts

A correctly configured discount that nobody notices performs like no discount at all, and this is where native's silence costs real money.

The surfaces that matter, and what to do about each without an app:

Product page. The highest-value placement, because it is where the add-to-cart decision happens. Native gives you nothing here, but a theme edit can render a badge or line of copy on qualifying products — driven off a collection or a metafield rather than hardcoded, so it disappears when the offer ends without anyone remembering to remove it.

Collection grid. Offer flags while browsing create discovery. Same approach: a badge conditioned on collection membership.

Cart. Native does show the discount here once it applies, which is necessary but late. What it does not show is distance to the threshold, and for any spend-based offer that indicator is the mechanic. If you build one thing beyond native, build this.

Post-purchase. Confirming the discount was applied, itemised, reduces support contacts noticeably. Shoppers who are unsure whether an offer applied will ask, and each of those is a support cost the offer caused.

The mistake that costs the most

It is not the discount configuration. It is failing to test what happens when a shopper qualifies for two things at once.

Offers are usually built one at a time, weeks apart, by someone thinking about that offer in isolation. They then meet each other in a real cart, along with the code you emailed subscribers in September and forgot about. The outcomes are a total discount nobody approved, or a shopper who qualifies for two offers, receives one, and abandons because the number does not match the landing page.

Before any offer goes live, list every other discount that could be active — including codes already in circulation — and walk the customer path for each combination. Anything you cannot make behave correctly should be made explicitly non-combinable rather than left to resolve itself at checkout.

After it is live

Two things worth doing that most merchants skip.

Check it is actually applying, in production, on a real order. Place one. The discount that worked in configuration and fails on the live theme is common enough to be worth the price of one order.

Watch inventory on the given item. A buy-X-get-Y offer consumes stock of the Y product at a rate nobody forecast, because it is driven by demand for X rather than demand for Y. Merchants routinely run out of the free item midway through a campaign and discover it when the discount silently stops applying. Set a stock alert on the given product before launch, and decide in advance what the offer becomes when that item runs out.

Measure the offer, not the app. Whether the mechanic made money is a question about incremental margin against a control period, not about whether the discount applied correctly. These get conflated constantly, and a merchant concludes an offer "did not work" when what they measured was that it worked exactly as configured on people who would have bought anyway.

For the strategic question of which mechanic to run and what it does to margin, see promotions and offers. App selection is covered in Shopify apps, and BFCM-specific offer structure in the BFCM 2026 series.