The honest answer is: most NZ Shopify stores should start with standard rates — the shipping profiles where you type in prices, weight rules, and zones yourself. It’s boring. It’s manual. It’s also predictable, fast at checkout, and you’re not held hostage by someone else’s API having a bad Tuesday.
Carrier-calculated shipping is the other path: Shopify asks a carrier (or a middleware you’ve wired up) for live rates while the customer is on checkout. It can be brilliant when reality is genuinely messy. It can also be slow, fragile, and more expensive in plan fees and engineering time than most owners expect before they’ve even shipped their first oversized pool table.
Plain terms: what you’re actually choosing
Standard rates live in your Shopify admin. You define zones (NZ, Australia, “South Island rural”, whatever), then attach prices by weight, price, or flat fee. Checkout does maths locally. No outbound call to NZ Post, no CourierPost handshake, no app middleware — just Shopify doing arithmetic.
Carrier-calculated means Shopify hits a Carrier Service endpoint during checkout and displays whatever comes back. That might be NZ Post’s numbers, a blended rate from multiple couriers, or something custom sitting behind Laravel on a server I control — which is exactly what I built for Great Range Products when Canterbury stopped behaving like one blob on a map.
Why I push almost everyone to standard rates first
Here’s the thing. Shopify’s marketing loves the shiny version of shipping — apps, live rates, “accurate to the gram”. That story sells plans. It doesn’t magically match your business.
Most stores I look at sell a catalogue with a manageable spread of weights and regions. You can model that with zones and tiers. Yes, you’ll tweak it twice a year when couriers put prices up. That’s still cheaper than debugging why checkout just added four seconds for customers on mobile rural connections.
I run shop.jimny.co.nz for Jimny Rentals NZ. It’s not the world’s most complicated fulfilment story — and I still default to simple rate tables until there’s a clear reason not to. If you’re going to complicate shipping, I want a named problem: “rural South Island is bleeding us”, “this SKU breaks every table”, “we’re quoting three carriers and cherry-picking”. Not vibes.
When standard rates actually run out of road
Standard rates start to pinch when your business stops looking like a grid. Oversized items that don’t fit weight-based assumptions. Real regional variation inside a single island (Canterbury is my favourite example — Christchurch metro vs Mackenzie vs Banks Peninsula is not one flat rate). Multiple carriers with different service levels. Frequent rate changes where you’re editing CSVs weekly and nobody trusts the numbers anymore.
That’s the point where carrier-calculated — or a custom integration that behaves like carrier-calculated — starts to earn its keep.
The checkout reality nobody puts in the sales brochure
Carrier-calculated isn’t “set and forget”. It’s a live dependency. Your store’s checkout now includes a network hop you don’t control end-to-end. I’ve seen stores where the carrier’s sandbox credentials leaked to production, where timeouts weren’t handled, where JSON errors surfaced as “no shipping methods” — which is a brutal way to lose a sale.
If you’re going to do carrier-calculated, do it properly: timeouts, fallbacks, logging, and someone who actually reads the logs. Otherwise you’ve traded spreadsheet pain for outage pain.
NZ-specific wrinkles (NZ Post, CourierPost, and “rate apps”)
NZ couriers don’t all expose pricing to Shopify in the same tidy way. NZ Post’s ecosystem moves — what’s available in an official app vs what needs a direct integration changes over time. CourierPost sits in the mental map for a lot of Christchurch businesses because it’s the default language of parcels here, but the technical path is still: get reliable rate data, normalise it, return it to Shopify fast.
Most “NZ rate calculator” apps I’ve audited are… fine. They’re not magic. They’re someone else’s wrapper around similar APIs, plus a monthly fee in USD — which means your true cost is usually 10–15% north of what the little price badge shows once the card network has finished with the exchange rate. Sometimes that’s worth it. Sometimes you’re paying rent for a thin UI over data you could model in a table.
GST and Shopify Payments are part of the NZ picture too — not because they change the carrier-calculated vs standard decision directly, but because the same store that’s sloppy on shipping is often sloppy on tax display and payment methods. I’m happy to untangle all of it; just don’t let shipping be the only thing we fix while checkout still feels foreign to local buyers.
The middle ground: custom integration
Sometimes the answer is neither “edit Shopify’s shipping tables forever” nor “trust a generic app”. Sometimes you need your own Carrier Service — a small API you own — that encodes the weird truth of your business. That might mean sub-zones inside a region, product tags that flip dimensions, rules for oversized freight, or blending pickup and delivery.
That’s the kind of work I take on through fixes and custom Shopify development — where the off-the-shelf apps stop and you still need checkout to be correct. If you’re planning a migration, it’s also the right moment to fix shipping once instead of recreating a mess on a new theme.
What Great Range Products needed
Great Range Products sells serious, bulky gear — pool tables, BBQs, the sort of freight that laughs at a simple “per kg” band. Canterbury alone needed internal splits: Greater Christchurch vs North Canterbury vs Mid vs South vs Banks Peninsula vs inland Mackenzie. Oversized lines had to pick up truck-run logic automatically. NZ-wide still needed to behave for everything else.
That’s not “install an app and hope”. We built a custom carrier-calculated integration against Shopify’s Carrier Service API with Laravel in the middle, so rates reflect the business, not a generic template. I’m proud of that project — it’s on the fixes page case studies if you want the longer story.
Pick a lane: standard vs carrier-calculated vs custom
| Standard rates | Carrier-calculated | Custom integration | |
|---|---|---|---|
| When it shines | Predictable products, straightforward zones, you’re OK tuning a few times a year | Many SKUs, live carrier pricing, frequent changes, multi-carrier quoting | Complex regional rules, oversized logic, blended carriers, “the apps don’t understand us” |
| Checkout speed | Fast — local calculation | Depends on carrier API latency and your code path | Same as carrier-calculated — you own the budget for performance |
| Operational risk | Human error in tables — visible and fixable | API outages, auth expiry, silent failures | You still have APIs — but you also have logging and fallbacks if you build properly |
| Plan requirement | All plans | Shopify / Advanced / Plus for Carrier Service | Same as carrier-calculated if you use Carrier Service |
| Monthly cost | Your time | Often apps + higher plan | Build cost up front, usually lower ongoing than stacking apps |
Where this gets interesting is sequence. I don’t jump to custom because it’s fun — I jump when the spreadsheet model is clearly lying to customers, or when the margin bleed is measurable. Until then, standard rates are a feature.
A decision order that won’t waste your week
- Model your truth on paper — zones, outliers, oversized lines, rural pain.
- Try standard rates with tight product weights/dimensions. Re-test checkout like a customer in two rural addresses you actually ship to.
- If checkout is “correct but tedious to maintain”, look at process before APIs — bulk editing, templates, seasonal profiles.
- If checkout is wrong because reality is dynamic, move up to carrier-calculated — only on a plan that supports it — and measure checkout time before and after.
- If apps can’t encode your rules, talk to someone who builds Carrier Service integrations for a living — that’s the custom path.
I’ve seen this enough times to call the pattern: the stores that suffer most are the ones that pre-optimise. They buy complexity before they’ve felt the simpler pain. Don’t do that.
Speed at checkout ties into performance, too — a slow carrier endpoint shows up the same way a bloated theme does. If you want the other half of that story, read what actually moves the needle on a slow Shopify theme, and when you’re thinking about app spend alongside shipping apps, pair it with auditing your Shopify app stack.
Picking a carrier matters before you romanticise APIs — NZ Post vs CourierPost vs Aramex for Shopify is how I think about coverage vs cost. If rural surcharges are eating you alive, NZ rural post codes and surcharges at checkout is the companion piece to this one.