ShipperHQ and Freight Rate Management: When Native Shipping Rules Stop Working
ShipperHQ does not publish a price. Shopify puts live carrier rates behind a plan gate. Here is what freight rate management actually means, what breaks first, and the cheaper fixes most stores skip.

Every shipping problem I've seen in fifteen years of ecommerce starts the same way. Somebody adds one product that doesn't fit the boxes you already ship in, and your flat-rate table quietly starts losing money on it. Nobody notices, because the orders still go out.
Then the carrier invoice arrives with a line item you've never seen before, and the maths stops working.
This piece is about that gap: what native shipping rules actually do, where they stop, and whether a rate engine like ShipperHQ is the right thing to buy when they do. Two things up front. ShipperHQ doesn't publish a price, and I'll show you exactly how far its own pricing page goes[1]. And Shopify gates live carrier rates behind a plan tier, which means the cheapest fix for a lot of stores isn't an app at all[2].
What your platform's native shipping actually does
Strip away the vocabulary and every commerce platform ships the same three primitives.
Zones
A zone is a bucket of countries, states or postcodes that share a rate table. Shopify calls them shipping zones inside shipping profiles[3]. WooCommerce calls them shipping zones and matches them top-down, first match wins[4]. Adobe and BigCommerce use the same idea with different words[5].
Rates
Inside a zone you get flat rates, weight bands, price bands, and free above a threshold. That's it, natively, almost everywhere.
Live carrier rates
The platform calls the carrier's API at checkout and shows what the carrier says it will cost. This is the one that's gated, and it's the one that matters.
Here's the thing nobody says out loud. Those three primitives cover somewhere north of 90% of stores completely. If you sell t-shirts in one country from one warehouse, you will never need a rate engine, and anyone selling you one is selling you a solution to a problem you don't have. I've built the over-engineered version of this. It cost a client four months and they turned most of it off.
Does this actually impact you? Five questions
Answer these honestly before you look at a single pricing page.
- Do you ship from more than one location? If yes, does the rate depend on which one ships?
- Do any of your products need different handling? Fragile, hazardous, refrigerated, oversized, lithium batteries.
- Does a single order ever split across carriers or origins?
- Do you sell anything that goes by pallet or LTL freight rather than parcel?
- Are you eating more than about 3% of revenue in shipping variance, meaning the gap between what you charged and what the carrier billed?
Shipping cost is also a checkout problem before it's a logistics one, so it's worth reading alongside the checkout fixes piece.
Zero or one yes: your native rules are fine, and the fix is a spreadsheet afternoon. Two or three: you have a rules problem, and it may still be solvable natively. Four or five: you have a rate engine problem, and this is the article for you.
Question five is the one people skip, and it's the only one with a number in it. Pull ninety days of orders. Sum the shipping you charged. Sum what the carriers actually invoiced. The difference is your business case, and if you can't produce those two numbers, that's the finding.
The stakes: shipping is the top reason people abandon
Baymard Institute's abandonment list aggregates 50 separate studies and puts the average documented cart abandonment rate at 70.22%[6]. Most of that is unavoidable. 42% of US shoppers say they were just browsing.
Of the reasons you can actually do something about, the top two are both shipping:
| Reason given | Share of US shoppers |
|---|---|
| Extra costs too high (shipping, tax, fees) | 40% |
| Delivery was too slow | 20% |
| Didn't trust the site with card details | 19% |
| Forced account creation | 18% |
| Checkout too long or complicated | 17% |
Source: Baymard Institute, updated 22 September 2025[6]
Baymard is a research firm that sells research, not shipping software, which makes it one of the few sources in this topic with no reason to inflate the number.
Read that table the way an operator would. The 40% is not an argument for cheaper shipping. It's an argument for shipping that doesn't surprise anyone. A rate that appears late, jumps at the last step, or arrives as a flat £12 on a £15 order is what gets abandoned. A rate that's high but visible from the product page mostly doesn't.
The 20% on delivery speed is the one rate engines can genuinely help with, because showing a real transit time next to a real price is exactly what a carrier API call gives you.
What we found: nobody in this category publishes a price
We read the public pricing pages for ShipperHQ and its usual alternatives on 22 July 2026, using only what the vendors themselves publish.
ShipperHQ publishes tiers, not prices
The ShipperHQ pricing page lists plan names and feature ceilings and no monetary figures at all. For Shopify and BigCommerce it shows Essentials at 2 carriers and 5 shipping rules; Starter at 4 carriers and 30 rules; Standard at 4 carriers, 20 rules, 4 origins, 3 advanced features and 1,000 orders a month; Advanced at 6 carriers, 50 rules, 8 origins, 4 advanced features and 2,000 orders a month; then Enterprise on custom terms[1]. The Adobe Commerce ladder is similar and adds a website count[1]. The page routes you to a free trial or "speak to an expert" instead of a number, and the FAQ says pricing varies by platform[1].
Three things follow from that, and only one of them is a criticism.
The honest reading first. Rate engines genuinely price by platform, because the integration surface on Adobe Commerce is a different piece of software from the one on Shopify. Charging one price for both would be arbitrary.
The less honest reading second. Feature ceilings expressed in carriers, rules and origins are a metering model, and metering models grow. Four carriers sounds generous until you count UPS, FedEx, USPS and a regional LTL carrier and realise you've used all four before you've added a returns carrier. Read those limits as the real price list, because that's what they are.
The third: an order-count ceiling of 1,000 or 2,000 a month means the plan you sign is not the plan you'll be on in a year if the business works[1]. Model the tier above.
The alternatives split into two different products
People compare ShipperHQ to Shippo and EasyPost as though they're the same category. They aren't, and this trips up a lot of buying decisions.
| Tool | Actually does | Pricing published? |
|---|---|---|
| ShipperHQ | Decides what rate to show at checkout | No, tiers only[1] |
| Shippo | Buys and prints the label after the order | Yes[7] |
| EasyPost | Multi-carrier API for developers, label side | Yes[8] |
| Platform native | Zones, bands, and live rates if your plan allows[3] | Yes, it's your plan fee |
Rating is a pre-purchase problem. Labels are a post-purchase problem. Buying a label tool to fix a checkout rate is the single most common mis-purchase in this category, and I have made it myself, on a Magento build in about 2016, and then spent a fortnight explaining why the checkout still showed the wrong price.
What "freight rate management" actually means
The phrase gets used for four separate problems. Knowing which one you have decides everything.
Dimensional weight
Carriers bill on whichever is greater, actual weight or volumetric weight, calculated from the parcel's dimensions divided by a carrier-specific divisor[9]. A big light box costs the same as a small heavy one. If you sell anything bulky and low-density, and your rate table is weight-only, you're losing money on every order and it doesn't show up as a shipping problem. It shows up as thin margin.
Accessorials
Residential delivery, address correction, additional handling, oversize, remote area, fuel. These are the invoice lines that appear after the order shipped, and they're the reason your charged-versus-billed variance exists. A rate engine can front-load them. A flat table can't.
LTL and pallet freight
Less-than-truckload is a different pricing world: freight class, NMFC codes, liftgate, appointment delivery, inside delivery. Native platform shipping has no concept of any of it. If you sell anything that ships on a pallet, this is the honest case for a rate engine, and it's roughly the only one I'd defend without argument.
Multi-origin and split shipments
One basket, two warehouses, two rates, one number to show the customer. Adobe handles the inventory side natively with its sources-and-stocks model[10]. What it doesn't do out of the box is decide how to present a combined rate, which is the bit rate engines sell.
If you are on Shopify
The plan gate is the real decision
Third-party carrier-calculated shipping is available on Advanced and Plus[25]. Shopify's own documentation states that Grow stores can add it for an additional monthly fee or by switching to annual billing[2].
That sentence is worth more to most readers than the rest of this article. If you're on Grow monthly and you want live carrier rates, switching to annual billing turns them on, and annual billing is cheaper per month anyway[11]. Some stores are paying for a third-party rate app to work around a gate they could open by changing a billing cycle.
Check that before you check anything else.
The Carrier Service API
Everything that shows a custom rate at Shopify checkout, including ShipperHQ, does it through the Carrier Service API. Your app registers a callback URL, Shopify posts the cart to it at checkout, and your endpoint returns rates[12].
Two consequences. It's a synchronous call in the checkout path, so if the endpoint is slow or down, the customer sees fewer options or none. And it's a versioned API, so anything custom you build against it needs somebody to look at it at least once a year, because Shopify ships a new API version quarterly with 12 months of support[13]. Nobody budgets that. See the ERP and CRM piece for the same trap on the back-office side.
What to try natively first
Shipping profiles let you set different rates per product group, which covers a surprising amount of the "one product doesn't fit" problem without any app at all[3]. Put the oversized item in its own profile with its own rates. Ten minutes.
Not on Shopify? The other platforms
WooCommerce
Zones are matched in order and the first match wins, which is the single most common source of "why is it showing the wrong rate" on Woo[4]. Reorder your zones from most specific to least. Shipping classes let you attach different costs to product groups and are the free version of what people buy apps for[14].
The paid step up is Table Rate Shipping, an official WooCommerce extension that adds rules by weight, item count, price and shipping class[15]. It publishes its price, which is more than the rate-engine category manages.
Woo's specific risk isn't the shipping layer, it's plugin interaction. Two shipping plugins that both filter the rates array produce results nobody can explain. Run one, or read the code.
Magento and Adobe Commerce
This is where rate engines earn their keep, and where ShipperHQ has the deepest integration. Adobe supports carrier accounts, per-website shipping configuration and a full set of delivery settings out of the box[16][17], and the multi-source inventory model gives you real origins to rate from[10].
Mid-market B2B on Adobe with pallet freight and customer-specific rates is the profile where I'd expect a rate engine to be genuinely load-bearing rather than nice to have.
BigCommerce
Zones and methods are configured natively and the platform exposes a shipping API for custom rate providers[18][19]. Fewer third-party options than Shopify or Adobe, and the ones that exist tend to be maintained. Watch the GMV thresholds that auto-upgrade your plan when you model total cost[20].
Headless and custom
You already own a rating service, whether you meant to or not. The question is whether it's a documented service with tests or a function in your checkout controller that one person understands. Note also that headless stores are undercounted in every platform statistic you'll read, because the usual detection fingerprints are gone[21].
The shipping matrix, as a table you can actually use
This is the artefact. Fill one row per product group before you talk to any vendor.
| Column | What goes in it | Why it matters |
|---|---|---|
| Product group | SKU family or shipping class | Rates are set per group, never per SKU |
| Packed dimensions | L x W x H of the actual box | Drives dimensional weight |
| Packed weight | Including packaging | The number you're probably already using |
| Origin | Which location ships it | Multi-origin is the main native gap |
| Handling flags | Fragile, hazmat, battery, oversize | Each one is an accessorial waiting to happen |
| Parcel or freight | Parcel, LTL, pallet | The single biggest fork in the decision |
| Charged rate | What the customer paid, last 90 days | Half of your variance calculation |
| Billed cost | What the carrier invoiced, last 90 days | The other half |
| Variance | Billed minus charged, as % of revenue | Your entire business case |
If the variance column comes out under about 1% of revenue, close the spreadsheet and go and do something else. You do not have a shipping problem. You have a shipping anxiety.
What AI agents change about shipping rates
This is newer than the rest of the article and I'd hold it more loosely.
Agentic checkout protocols expect a merchant to answer a structured question about what an order costs to deliver and when it arrives, as machine-readable data rather than a rendered checkout page. Google's Universal Commerce Protocol work and the Agentic Commerce Protocol spec maintained by OpenAI and Stripe both treat fulfilment options as first-class structured fields[22][23].
A shipping rule that lives as a hand-maintained table in your admin, with three exceptions somebody remembers, doesn't survive that translation. A rating service with an API does.
So the agentic argument for a rate engine isn't about AI. It's that the delivery promise stopped being a line on a checkout page and became data other software reads. Same conclusion as inventory accuracy. The internal metric became customer-facing.
What I would not do is buy a rate engine because of this in 2026. Agent-driven order volume is still small. Build the data discipline, and the tooling follows the volume.
The returns side that nobody prices
If you sell into the EU, return shipping is a legal question before it's a logistics one, and the right of withdrawal sets out who pays what and when. We covered the mechanics in the piece on the EU right of withdrawal, and the short version for a shipping matrix is that you need a rate for the journey back, not only the journey out.
Most rate tables model outbound only. Then returns get handled by whoever is standing nearest the printer. The returns piece covers how to cost that properly, and if you sell across borders, the international piece covers duties and delivered-duty-paid, which changes the number you should be showing at checkout.
What to do this week
- Run the variance calculation. Ninety days of charged shipping against ninety days of carrier invoices. One number.
- If you're on Shopify Grow monthly, price annual billing. It may switch on carrier rates for free[2].
- Put your worst-fitting product in its own shipping profile or class. Ten minutes, no app[3][14].
- Measure your three biggest boxes. Compare volumetric weight to actual weight. If volumetric wins, your rate table is wrong[9].
- Count your carriers and origins before you look at any tier that meters them[1].
- On Woo, check your zone order. First match wins, and the most common misconfiguration is a broad zone sitting above a narrow one[4].
- Ask any rate vendor for a written price including the tier above the one they're quoting. If they won't, that tells you the renewal conversation in advance.
The takeaway
Native shipping covers most stores completely, and the platforms are honest about their limits[3][4]. Where they genuinely stop is pallet freight, multi-origin splits and handling rules that change the carrier, not the price. That's a narrow set of businesses, and if you're in it, ShipperHQ is a reasonable answer[24] with an unreasonable pricing page[1].
Shipping is also the top addressable reason people abandon carts, at 40% on cost and 20% on speed[6]. Both of those are fixed by showing an accurate number early, which is a data problem more often than a software one.
I spent years assuming shipping variance was a cost of doing business. It was a spreadsheet I hadn't built.
Do you know what your carriers billed you last month, against what you charged? Actual numbers, not a feeling.
Sources
- ShipperHQ, "Pricing". Accessed 22 July 2026. Vendor page. Plan tiers and feature ceilings published; no monetary figures.
- Shopify, "Third-party carrier-calculated shipping". Shopify Help Center. Accessed 22 July 2026.
- Shopify, "Setting up shipping zones and rates". Shopify Help Center. Accessed 22 July 2026.
- WooCommerce, "Setting up shipping zones". WooCommerce documentation. Accessed 22 July 2026.
- BigCommerce, "Shipping zones". BigCommerce support. Accessed 22 July 2026.
- Baymard Institute, "49 Cart Abandonment Rate Statistics". Aggregate of 50 studies; 70.22% average. Updated 22 September 2025. Independent research firm.
- Shippo, "Pricing". Accessed 22 July 2026. Vendor page.
- EasyPost, "Pricing". Accessed 22 July 2026. Vendor page.
- FedEx, "Current rates". Accessed 22 July 2026. Carrier primary source for dimensional weight and surcharges.
- Adobe, "Inventory Management introduction". Adobe Commerce documentation. Accessed 22 July 2026.
- Shopify, "Pricing". Accessed 22 July 2026.
- Shopify, "CarrierService resource". Shopify developer documentation. Accessed 22 July 2026.
- Shopify, "API versioning". Shopify developer documentation. Accessed 22 July 2026.
- WooCommerce, "Product shipping classes". Accessed 22 July 2026.
- WooCommerce, "Table Rate Shipping". Official extension, price published. Accessed 22 July 2026.
- Adobe, "Shipping settings". Adobe Commerce documentation. Accessed 22 July 2026.
- Adobe, "Shipping carriers". Adobe Commerce documentation. Accessed 22 July 2026.
- BigCommerce, "Shipping methods". Accessed 22 July 2026.
- BigCommerce, "Shipping API v2". Accessed 22 July 2026.
- BigCommerce, "Pricing". Accessed 22 July 2026.
- HTTP Archive, "Web Almanac 2025: Ecommerce". Accessed 22 July 2026.
- Google, "Under the Hood: Universal Commerce Protocol (UCP)". Google Developers Blog.
- Agentic Commerce Protocol, specification repository. Maintained by OpenAI and Stripe. Accessed 22 July 2026.
- ShipperHQ, Shopify App Store listing. Accessed 22 July 2026.
- Shopify, "Shopify Plus". Accessed 22 July 2026.