My flat-rate shipping shows the wrong price right at the cutoff, why?
If your shipping rate flips to the wrong tier right at the dollar or weight cutoff, the usual cause is overlapping rate conditions, not a Shopify bug.
What's going on
A merchant sets up two shipping rates, say a flat $5 rate for orders "up to $50" and a $10 rate for orders "$50 and over", expecting a clean split. A test order placed at exactly $50.00 comes back showing the wrong rate, or sometimes both rates appear as options at checkout. Nudge the cart to $49.99 or $50.01 and it behaves correctly; only the exact boundary value misbehaves.
This is usually a range-overlap problem rather than a platform glitch. Price-based and weight-based shipping rate conditions are defined by a minimum and maximum per rate, and if you type "$0-$50" for one tier and "$50-$100" for the next, both ranges technically include the value $50 itself. When a cart's subtotal or weight lands exactly on that shared number, which rate applies can depend on internal matching order rather than merchant intent, which is why it looks inconsistent from the storefront.
The same symptom can also come from which number is actually being compared. Price-based conditions look at the cart subtotal, and depending on store configuration that can mean before or after certain discounts, and in a specific currency if you sell internationally. A converted total that rounds to just under or just over a threshold in one currency can cross a cutoff that looked fixed when you only tested in your store's default currency.
Because the failure only shows up at one specific value, it's easy to miss in normal QA, which tends to test a cheap cart and an expensive cart but not the exact cutoff, and easy to reproduce once you know to test the boundary on purpose.
Why it happens
Shipping rate conditions are entered as a minimum and maximum for price or weight, per rate, per zone. If adjoining tiers are written with "up to" and "and over" style boundaries without a gap between them, the two ranges mathematically share the exact boundary number, so a cart landing on that precise value can satisfy both conditions at once.
Stores running multiple shipping profiles, a default profile plus custom profiles scoped to specific products, each have independent rate tables. A cart containing products from two different profiles can end up combining rates in ways that don't match either profile's rules on its own, which compounds boundary issues and makes them harder to reproduce consistently.
Multi-currency and multi-market stores add a rounding variable: the number being compared against the threshold is a converted, rounded figure, and that conversion can shift a subtotal by a small amount relative to what a merchant sees when testing in their store's primary currency.
5 ways to fix it
Rebuild your rate tiers so the boundaries don't touch
In your shipping settings, open each shipping profile and edit the price-based or weight-based conditions for every rate. Instead of writing tiers as "$0-$50" and "$50-$100", which both cover the value $50, split them so no number is shared: "$0.01-$49.99" and "$50.00 and up" (or the weight equivalent, say 0-4.99 lb and 5 lb+). Then test it deliberately: build a cart that totals $49.99, exactly $50.00, and $50.01, and check out in an incognito window each time to confirm which rate actually gets quoted.
Check how many shipping profiles you're running
Every shipping profile you have, the default one plus any custom profiles scoped to specific products, keeps its own independent rates and conditions. If a product sits in a custom profile with a price break at $50 while your default profile also breaks at $50, carts mixing products from both profiles can produce inconsistent results that look like a random glitch. Auditing which products live in which profile, or merging back down to a single profile where possible, removes a common source of "it worked in my test but not this customer's order" reports.
Confirm what value is actually being compared, and watch currency conversion
A price-based condition compares against the cart subtotal, and depending on your settings that can be a pre-discount or post-discount figure. If you sell in more than one currency, a converted total can round to a fraction of a cent on either side of your cutoff even though the original amount is unchanged. If a meaningful share of your orders come from other currencies, a weight-based condition is generally more predictable than a price-based one, since weight doesn't move with exchange rates.
Consider a free-shipping discount instead of a zero-cost rate tier
If what you actually want is "free shipping over $X" rather than a genuine multi-tier rate table, Shopify's built-in free-shipping discount (set up under Discounts, with a minimum purchase amount) is a cleaner way to get there than pairing a $0 rate condition next to a paid one. It's evaluated as a single discount rule rather than as competing shipping rates, so it isn't exposed to the same boundary-overlap issue.
Only bring in an app or a Shopify Function if native rates genuinely can't do it
If your real requirement combines conditions Shopify's native price and weight rules can't express cleanly, such as different rates by price and weight and product tag all at once, a shipping rate customization built with a Shopify Function, or a third-party shipping rates app, is a legitimate next step. But for a straightforward boundary mismatch like the one described here, this is a configuration fix, not something that needs an app.
Bottom line
This is almost always a settings problem, not a missing feature or a platform bug: two rate conditions whose numbers technically overlap at the exact cutoff, or a subtotal being evaluated in a different currency or discount state than you tested with. Redefine your tiers so the ranges never touch, retest at the exact boundary value in an incognito window, and check how many shipping profiles are in play. Reach for a shipping-rates app or a Shopify Function only if you need logic, such as combined price, weight, and tag conditions, that native rate rules genuinely can't express; for a boundary-value mismatch, no app is needed.
Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.