Why Standard Shopify Discounts Fail Fashion Retailers

For many online stores, a discount is a temporary campaign. For fashion retailers, promotions can be part of daily operations. New collections arrive every week, exclusions change from one campaign to the next, and the same price must be correct in the online store, at the till, in apps and in advertising feeds.

At that point, calculating 20% off is not the hard part. The real question is: which system owns the price, when does it change it, and which other systems write to the same field?

We encountered this at a Dutch fashion retailer on Shopify Plus. Roughly 3,900 active variants were published to eight sales channels while promotions ran almost continuously. The standard tools worked as designed in isolation. Together, they created a pricing process the retailer could no longer manage reliably.

One promotion, eight places where the price must match

The same catalogue served the Shopify store, the physical point of sale, a headless storefront, a mobile app, Facebook and Instagram, TikTok, and Google and YouTube.

All of these channels need a clear product price. A discount applied only in the cart or theme therefore solves just one part of the problem. Google Merchant Center compares the feed price with the landing-page price and may disapprove a product when they differ. The underlying product data must be right, not just the number shown in the storefront.

For retailers with physical stores, the till adds another dependency. Separate rules for every channel may look flexible, but they make it harder to identify the one price customers should actually pay.

Where the standard approach started to break

Shopify Launchpad is designed for scheduled events such as sales, product drops and inventory releases. It can change product prices at the beginning and end of an event. That is a sensible model for a short campaign and a stable catalogue.

This retailer worked differently: near-permanent discounts, weekly new stock and campaign exclusions that kept changing. Three assumptions behind the event model collided with daily operations.

New products missed an active promotion

Products added during a campaign did not automatically receive the same discount. Every delivery required another event and another catalogue-wide update. Between 8 and 22 July, six events were needed, sometimes only seven minutes apart. Campaign planning had turned into catalogue maintenance.

Manual price changes were reversed

When an employee changed a price during an active event, the saved starting state could later overwrite that change. A dress deliberately priced at €12.99 was back at €7.99 the next morning.

Without a useful price-change log, we had to reconstruct the sequence through order lines. That is not a workable process for a store handling new products and markdowns every day.

Promotion exclusions collided with navigation

Campaigns relied on tags and collections. In this setup, removing an item from the promotion could also remove it from the store navigation.

The business request was simple: exclude winter coats from the 20% promotion while keeping them visible in the collection. The existing setup tied merchandising and promotion logic too closely together.

Adding another discount app made it worse

A second tool sounds like the obvious answer when the first lacks flexibility. But when both tools edit the same price field, a more fundamental problem appears: two writers that know nothing about each other.

An additional discount app calculated from prices already changed by Launchpad. Nineteen products ended up with a 36% discount instead of 20%. When the app was removed, it restored only 18 of 3,382 variants.

That is not a missing checkbox. The pricing model no longer has a clear owner.

Cart discounts and theme code have a similar limitation. They may correct the storefront or checkout, but they do not automatically update the source price used by the POS, mobile app and product feeds. The website can look right while another channel still shows the wrong amount.

Reverse the pricing model

The custom solution did not start with another discount tool. It started with one rule:

People manage the regular selling price. Software calculates the promotional price.

Shopify’s two price fields received distinct responsibilities:

• compare_at_price stores the regular selling price and is the field employees manage;
• price stores the current promotional price and is calculated by the automation.

Because the result is written to Shopify’s actual product price, the webshop, POS, apps and feeds all use the same amount. There is no separate promotion engine per channel.

The promotion rules live in Shopify admin. Store employees can select the discount type, percentage or fixed amount, included tags and excluded tags. Rules are phrased as “the whole catalogue except these exclusions”, so new products join automatically. If two promotions overlap, the lowest price wins.

A PRIJS-VAST tag acts as an emergency brake for products that must remain manually priced. At migration, 170 products used this exception.

Small architecture, large operational effect

Technically, the automation uses a Shopify webhook, a queue and a small AWS function. When a product changes, the function recalculates the price and writes only when the result actually differs.

There is no database, scheduled catalogue scan or permanently running server. At approximately 1,500 webhooks per day, infrastructure costs remain below €1 per month.

The low cost is useful, but the real value is a pricing model employees can understand and trust:

• manual changes remain intact;
• new products automatically join the correct promotion;
• exclusions stay visible in their collections;
• every channel receives the same current price;
• the retailer can enable or disable campaigns without developer support.

From 22 minutes to 5 minutes and 12 seconds

Migration was the risky part. Ending the old Launchpad event temporarily returned the catalogue to full price and removed compare-at prices. Every minute was visible to customers.

We measured instead of guessing. Reading the catalogue took 4.2 seconds and updates ran at more than twenty products per second. A rollback was tested by deliberately corrupting and restoring one product. The complete flow was then proven on five unpublished draft products. All five behaved as predicted, and a second run made zero changes, confirming the automation would not trigger itself indefinitely.

On 3 August 2026, the live migration started at 14:48:22. By 14:53:34 the catalogue was correct again. The visible window without discounts lasted 5 minutes and 12 seconds.

The final validation showed:

• 3,933 of 3,933 variants correct;
• zero discrepancies;
• zero variants without a compare-at price;
• versus 22 minutes without discounts during the previous manual conversion.

The code was small. Discovering what to build, understanding how the existing tools interacted and proving a safe migration path was the real work.

When should a fashion retailer reconsider its price model?

Not every fashion store needs custom development. A standard discount function is usually enough for a temporary sale, a stable catalogue and one main sales channel.

Reconsider the model when several of these conditions apply:

• promotions run almost continuously;
• new products arrive while promotions are active;
• exclusions change by collection or week;
• employees also adjust prices manually;
• products sell through a webshop, POS, apps and feeds;
• several apps or scripts edit the same price field;
• nobody can confidently identify which system determines the final price.

Do not start by comparing feature lists in the app store. Start with three ownership questions:

1. Which system owns the regular price?
2. Which system may calculate and write the promotional price?
3. How does every channel receive the same outcome without overwriting another system?

Only then can you make a sound choice between a standard app, automation and custom development.

European price rules require a separate layer

For European retailers, announced price reductions generally require the prior price to reflect the lowest price charged during the preceding 30 days. That requires reliable price history, not merely a populated compare-at field.

The automation in this project keeps current prices consistent across channels. It does not retain a complete 30-day history and is therefore not, by itself, a guarantee of compliance with European pricing law. Historical registration and legal assessment remain separate requirements.

Technically consistent prices and legally correct reference prices are related, but they are not the same problem.

Standard where it fits, custom where it stops fitting

Launchpad and discount apps are not bad products because they did not solve this situation. They were designed around different assumptions: temporary campaigns, a stable product set and one clear discount layer.

Fashion retailers with continuous promotions, rapid collection changes and multiple sales channels can outgrow those assumptions. Adding one more app rarely restores ownership. First map how prices move through the operation; then build only the missing part.

That is where Duxly steps in. Standard integrations already exist. When standard is no longer enough, we design the custom layer that makes the whole system reliable.

Explore our guides to Shopify POS for fashion retail and the best Shopify apps for fashion e-commerce, or see our broader Shopify expertise.

Are multiple apps, channels and exceptions competing for control of your prices? Book a technical discovery call. We will identify which system should own each price before adding another tool.

Sources

• Shopify Help Center: Launchpad
• Google Merchant Center: mismatched product price
• European Commission: genuine price reduction claims