Most vendors on a marketplace ship domestically, and their delivery is a couple of flat tiers you can read straight from their store. Then one vendor ships from another country on a weight- and dimension-based carrier tariff, and every neat assumption breaks. This is how we price a cross-border vendor honestly: by crawling the vendor's own checkout for real rates instead of guessing a formula, storing a per-SKU estimate, gating the products we can't ship out of the catalogue, and recalculating the exact charge live at checkout.
Why cross-border rates resist a formula
The tempting approach is to model shipping as a function of weight: fit cost = f(weight) from a few data points and interpolate. It fails for two reasons, and both are expensive.
First, the data usually isn't there. Product feeds rarely expose accurate shipping weight; a supplement's net grams are not its packaged weight, and gear often has no weight field at all. You would be fitting a curve to numbers you don't have.
Second, and worse, real tariffs are not smooth. Carrier pricing has bands, and crossing a weight or volume band steps the price up discontinuously — a large parcel becomes a freight or pallet shipment and the cost jumps. A smooth cost(weight) curve is most wrong at exactly those pallet jumps, which are the heavy, expensive orders you least want to under-price. Reverse-engineering the formula doesn't just add error; it concentrates the error on the orders that hurt.
People try heroic versions of the formula approach — dimensional-weight models, per-category weight averages, machine-learned rate predictors. They all founder on the same rock: the tariff is a step function the vendor's carrier defines and can change without telling you, so any model you fit is a lagging approximation of a number the vendor already computes exactly. Approximating a value you can simply look up is effort spent to be less accurate.
Crawl the vendor's own cart for the real rate
There is already a system that knows the vendor's exact rate, including every band and jump: the vendor's own checkout. So ask it. For a platform vendor you can drive the store's cart API the way a shopper's browser would — add a representative item, set a destination in the country you serve, and read back the shipping rates the store returns. That number is the real carrier price, tiers and jumps included, with no modelling on your part.
This is the same principle as reading domestic fees from a vendor's store in per-vendor shipping — treat the vendor's checkout as the source of truth — but for cross-border it is not a convenience, it is the only reliable option. There is no honest shortcut around the carrier's own tariff.
Store per-SKU estimates, and gate the un-priceable
Crawling live on every page view is slow and impolite to the vendor's store, so persist the result. Store a shipping estimate per SKU, captured from the crawl, so the product page and cart can show a delivery figure without a network round-trip each time.
The crawl also answers a question you must not ignore: some SKUs cannot be shipped to your market at all. The store returns no purchasable rate — too heavy, restricted, or the destination is refused. Those products have to be gated out of the search index. Listing something a shopper can add to the cart but never actually receive is worse than not listing it: the "add to cart" that dies at checkout burns trust and generates support. So the ingest pipeline drops un-priceable SKUs from the index, the same way it drops imageless or otherwise unlistable products during feed ingestion.
One vendor on our marketplace ships cross-border with weight-based rates. We crawl its own checkout for the real numbers, store a per-SKU estimate for the product and cart pages, gate the SKUs it won't price to our market out of the index, and recalculate the exact charge live at checkout. We do not fit a rate formula, precisely because the pallet jumps are where a fitted formula is most wrong — and most costly.
Live recalc at checkout
A stored per-SKU estimate is per item, but a real basket of several items from that vendor ships together, and the whole-basket rate is not the sum of the per-item rates — bands and jumps see to that. So the estimate is for display; the charge is computed fresh. At checkout, make one more live call to the vendor's cart with the actual basket to get the exact rate the vendor's own store would charge for that combination.
Because a live call can fail or time out, it needs a defined fallback. A safe one is the maximum of the stored per-item estimates for the basket — an over-estimate is recoverable, a systematic under-estimate is money you lose on every order. Whatever the fallback, the shopper sees a real number and the marketplace is never left guessing at the till.
Pitfalls to plan for
- VAT on shipping. Cross-border shipping carries its own VAT treatment; fold it into the order's tax accounting deliberately, as covered in marketplace VAT, rather than bolting it on at the end.
- Rate drift. Carriers change tariffs. A stored estimate is a snapshot; re-crawl on a schedule so the displayed figure doesn't quietly diverge from the live checkout charge.
- Crawl politeness. You are driving someone else's store — rate-limit, identify your requests, and only crawl for destinations you actually serve.
- Thresholds still apply. A cross-border vendor may run its own free-shipping threshold; honour it exactly as you would domestically, per free-shipping thresholds.
| Guess a rate formula | Mirror the vendor's cart | |
|---|---|---|
| Needs product weights | Yes — often missing | No |
| Handles pallet jumps | No — smooth curve misprices bands | Yes — real tiers included |
| Un-priceable SKUs | Silently mispriced | Detected and gated out |
| Whole-basket accuracy | Approximate | Exact via live recalc |
| Maintenance | Refit on every tariff change | Re-crawl on a schedule |
Key takeaways
- Don't fit a cost(weight) formula for cross-border shipping — the data is often missing and pallet jumps make a smooth curve wrong where it costs most.
- Crawl the vendor's own checkout for the real rate, bands and jumps included; the vendor's store is the source of truth.
- Store a per-SKU estimate for display, and gate SKUs the vendor won't price to your market out of the search index.
- Recalculate the exact charge live at checkout against the real basket, with a safe over-estimating fallback if the call fails.
- Plan for drift and VAT: re-crawl on a schedule, crawl politely, and fold cross-border shipping VAT into the order deliberately.
Frequently asked questions
Why can't I just calculate cross-border shipping from product weight?
How do you get a cross-border vendor's real shipping rate?
What happens to products the vendor won't ship to your market?
Why recalculate shipping again at checkout?
Cross-border shipping priced from the carrier's real tariff.
Our live marketplace crawls a cross-border vendor's own checkout, gates un-priceable SKUs, and recalculates the exact charge at checkout — no guessed formulas.
Request early access See the live marketplace →