Updated
The goal is the cheapest service that still arrives when the customer was told it would. For a lot of domestic volume, that is no longer an express service, and the reason is worth understanding rather than assuming.
Ecommerce volume grew, Amazon standardised two-day delivery and then built its own carrier network, and the incumbents responded by getting faster. The effect on ground services was substantial: for many domestic lanes the gap between something like UPS Ground and UPS 2nd Day Air closed to nothing, and both now arrive in the same window.
Where that is true, buying the express service buys a delivery date you were going to get anyway.
Transit time is a function of distance, which carriers express as zones. The lower the zone, the shorter the ground transit, and the more likely ground already meets the promise you made at checkout.
In ShipStation you can check the estimated delivery time for each carrier service against the destination before you buy. Do that across a sample of your actual orders — a few addresses in each zone you ship to — and you will find the zones where ground and express arrive on the same day. Those are the lanes where the express service is pure cost.
The zones where they diverge are real, and on those you should keep paying for speed.
You no longer have to map this by hand. Build a Rate Shopper rule around a service collection that holds both the ground and the express services you would accept, set a transit time threshold, and it picks the cheapest service estimated to arrive inside it. On the lanes where ground already meets the promise, ground wins on its own, per order, and you never had to work out which lanes those were.
A delivery estimate is not a delivery guarantee, and this does not split along the line people expect. It is not ground versus express. It is per service, and two services in the same tier can differ.
Every rate comes back with an estimated delivery date. Only some come back guaranteed. Requesting rates on the same shipment, USPS Ground Advantage and UPS Ground both estimated the same delivery date, and only one of them committed to it:
| USPS Ground Advantage | UPS Ground | |
|---|---|---|
| Guaranteed | no | yes |
| Estimated delivery | 11 Aug | 11 Aug, by 11:00 PM |
Same date, same tier of service, different commitment. Pick on price and you may have swapped a guarantee for an estimate without anything telling you so.
Rate Shopper’s transit filter is defined on the estimate: it “restricts eligible services to those that have a carrier delivery estimate within the specified time”. The word guarantee does not appear anywhere in that documentation, and there is no setting that lets you tell Rate Shopper to prefer or require a guaranteed service. Whether it weighs the flag internally is not something you can determine from outside. What you can say is that nothing published suggests it does, and that on the comparison above both services clear a three-day window on the estimate alone.
The carrier does return the distinction. There is a guaranteed flag on each rate in the API response, so the information exists at the moment the comparison runs. Whether Rate Shopper reads it, nobody outside ShipStation can say, and I have not found it surfaced anywhere in the interface. Treat that as the risk rather than as a settled fact: plan on the assumption that the comparison ignores it, and if the guarantee is load-bearing for you, check a few of your own shipments against what the rate actually returned.
Worth knowing too that the guarantee is a property of that rate request, not a fixed property of the service, so it can differ by origin and destination. The answer for one lane is not the answer for all of them. And where the guarantee exists it is not unconditional — FedEx’s Money Back Guarantee through ShipStation is US accounts only, with services excluded from it.
ShipStation is at least conservative about the estimate itself. Where a carrier returns a range of dates it uses the later one, and a service that returns no estimate drops out of the pool rather than defaulting into it. But conservative about an estimate is still an estimate.
That is the right behaviour for most volume and the wrong behaviour for orders sold on a date. Those want their own Rate Shopper configuration, built only from services the carrier publishes as guaranteed, applied by an automation rule keyed on what the customer selected at checkout. You still get a price comparison, it just happens inside a pool you trust rather than across everything.
This is the workaround worth building, and it is what I set up. Two edges to know about.
The pool is built on the carrier’s general claim, not on the rate. You are selecting services the carrier publishes as guaranteed, and the flag on the rate is about that specific shipment. A service in your pool can come back without a guarantee on a particular lane, so what you have is a collection of services that are usually guaranteed rather than a set of guaranteed shipments.
Nothing tells you which one you got. The distinction is on the rate and it is not surfaced, so an order that fell through the gap looks exactly like one that did not.
For most operations that is a good trade: you have removed the case where a cheaper unguaranteed service wins on price, which is the one that actually costs you. If the guarantee is contractual rather than a customer expectation, the residual gap is worth knowing about before you rely on it.
For a free-shipping order with a five-day promise, none of this matters and the cheapest estimate is the right answer.
The decision is per order, because it depends on the zone, the service, the cutoff and what the customer was promised. Static automation rules approximate it badly because they cannot read live transit estimates. Rate Shopper can, which is why it is the right tool for most of this and worth configuring before anything else.
What it cannot see is which of your orders were sold on a guarantee. That lives in your checkout, not in the rate, and it is the one part of this you still have to express yourself.
If you want to see what service selection is costing you on your own order mix, the self assessment works it out from two standard ShipStation exports and never leaves your browser.
Knowing how a carrier prices a package is useful. The harder problem is making the right packing and rate decision on every order, when the correct answer changes with the contents, the destination and the rate card.
String builds and maintains that logic inside existing ShipStation accounts, for operations shipping roughly 6,000 orders a month or more. Below that, ShipStation's native automation and accurate product dimensions will get you most of the way there.
Eight patterns that show up when an operation needs custom shipping logic
