Shopify pricing errors: how an 80%-off typo goes live

Three retailers made the same headline in 2026 for the same reason. In January, Corsair listed a 48GB DDR5 memory kit at $239.99, took orders during a worldwide RAM shortage, then cancelled every one of them and issued apology coupons. In February, Coupang listed 1,800 rolls of toilet paper for about $20; the error was corrected in roughly ten minutes and the orders were cancelled anyway. In August, Coles cut cases of alcohol from around A$130 to A$27, and the deal had been shared across social media before anyone at the company noticed.

None of those companies is small, and none of them was running a Shopify store. That is the point. Pricing errors are not a small-merchant problem caused by inexperience. They are a bulk-editing problem, and a Shopify store running a sale across a few hundred variants has exactly the same exposure with a much smaller legal team. This article is about how the slip actually happens in a Shopify sale, what to do in the hour after you notice, and which guardrails catch it before it goes live.

How a wrong price actually gets published

Nobody types a wrong price into a single product on purpose. The errors that make news come from operations that touch many prices at once, and in a Shopify store that means a bulk edit, a CSV import, or a discount app applying a rule. The failure modes are boring and repeatable:

• Percentage where an amount was meant, or the reverse. “20 off” means 20% on a $40 product and $20 on a $25 one. A rule set in the wrong unit produces prices that look fine on expensive items and go to near zero on cheap ones.
• The wrong selection. A rule meant for one collection is applied to all products, or a collection has grown to include things it did not contain when the sale was planned. The summary says “412 variants updated” and nobody reads the list.
• Discounting the discount. Prices that were already reduced by a previous sale, and never restored, get the new percentage applied on top. 30% off a price that was already 40% off is 58% off, and on the second run it is 71%.
• A decimal slip in a spreadsheet. A CSV column formatted as a number drops trailing zeros or shifts a decimal. Shopify’s import happily writes 12.9 where 129.00 was meant.
• Market conversions. A percentage applied to a base price that is then converted for another market can round below a floor you never intended for that currency.

What all five have in common is that the tool did what it was told, and the summary screen looked normal. The error was only visible at the level of an individual variant, and the individual variant was never shown.

The first hour after you notice

If a wrong price is live right now, the order of operations matters more than the tooling.

1. Stop the bleeding before fixing the cause. Set the affected products to draft or remove them from the Online Store channel. A product that cannot be bought cannot generate another order while you work out what happened. Fixing the price first means racing customers who already have the page open.
2. Find the extent. Filter Orders by the last few hours and sort by total. Coupang’s error was corrected within ten minutes; the damage was in the orders placed during those ten minutes. You need the count and the total before deciding anything.
3. Decide whether to honour. This is a legal and reputational question, not a Shopify one. Corsair’s cancellations became the story; Micro Center’s habit of letting customers keep mis-priced items became the comparison. If you cancel, Shopify’s documentation on cancelling orders and refunding orders covers the mechanics, including the warning that bulk cancelling orders that were already refunded can trigger duplicate refunds.
4. Restore the prices from a record, not from memory. If you have a pre-sale export, re-import it. If you do not, you are about to discover that “what was the price of the medium in blue before the sale” is not a question Shopify’s admin can answer for you. Shopify’s sale pricing documentation describes compare-at as a display field, not a backup of the original price.
5. Tell customers something before they tell each other. Every one of the three cases above went viral before the retailer spoke. A short email to affected customers on the same day is cheaper than the thread that forms without it.

Guardrails that would have caught each one

The interesting question is not “how do I fix it” but “what would have refused to publish it”. Every safeguard in SafeSale corresponds to one of the failure modes above, and none of them is clever. They are the checks a careful person would do by hand if they had time, made mandatory so they happen when there is no time.

A per-variant preview using the same code as the apply

Before anything is written, SafeSale shows every variant with its current price, the price it would become, and the resulting percentage off, with the deepest discount in the whole run shown as a single headline number above the list. A near-zero result from a unit mix-up shows up there as “Max 97% off” whether it sits on variant three or variant three hundred. The preview is produced by the same pure function that performs the apply, and the apply rejects a preview whose fingerprint no longer matches the current data. You cannot approve one set of numbers and have a different set written because a price changed in between.

A hard cap that blocks, and a threshold that asks

Every store has a percentage below which no legitimate sale goes. SafeSale lets you set it. Any variant whose planned change exceeds that cap is blocked outright and listed as blocked in the preview; the default is 90% off, and the setting accepts anything from 1% to 95%. A second, lower threshold (50% by default) does not block but flags the run as needing confirmation, and you have to type it out before the apply button does anything. A 20-off rule that turns out to be 20 dollars off a 25-dollar item trips both.

Discounts computed from a snapshot, never from the current price

When SafeSale rewrites prices it first stores the original price and compare-at of every variant it will touch. Every calculation, on every run, starts from that snapshot. If a variant is already discounted by a previous SafeSale sale, the new rule is applied to the original, not to the already-reduced number, so a second sale cannot stack on a first. Our article on snapshots goes into how this differs from apps that compute from the live price.

An automatic revert to the exact originals

A sale has an end, and at the end SafeSale writes the snapshot back: the same price, the same compare-at, per variant. This is the answer to step four above. It also means a sale that was applied by mistake can be ended immediately and every price returns to what it was, not to what someone remembers it being. If the app were uninstalled with a sale running, the snapshot CSV you can download from any sale is the fallback; the stuck prices after uninstall post covers that scenario.

A change log per variant

Each write is logged with the variant, the old value, the new value and the sale that caused it. When you are in the first hour and need to know which of your 3,000 variants were touched at 14:07, that log is the answer, and it is the same log that tells you the revert completed.

What this does not protect against

Honesty about scope: SafeSale only sees prices it changes. A wrong price typed directly into a product, or imported through Shopify’s CSV importer, is outside its snapshot and outside its cap. If a third-party app rewrites prices at the same time, the two will fight, and drift detection will flag that the live price no longer matches what SafeSale wrote, but it cannot know which one is right. And no software decides whether you honour the orders that slipped through; that stays with you and your local consumer law.

Next step

SafeSale is not yet publicly listed on the Shopify App Store. The landing page demo walks through a preview with blocked and confirmation-required variants, and the exact restore at the end of a sale. See how SafeSale previews and caps a bulk price change.