An ecommerce fulfillment service stores your inventory and picks, packs, and ships each order as it comes in. Choosing one is usually framed as a logistics decision, and half of it is: the other half is an integration contract between their warehouse system and your store, and that half is what breaks.
Every guide to fulfillment covers pick and pack, storage rates, and shipping discounts. Almost none covers what happens technically when an order is placed — which system tells which, what happens when that message fails, and who is right when the two disagree about how many units are left. That is the part that produces oversells and angry customers.
Table of contents
- How 3PL pricing is actually structured
- The integration is an API contract
- Inventory sync is a consistency problem
- What the storefront has to survive
- Returns, which are half the operation
- When to outsource, and when not to
- How this fits the rest of the stack
- FAQ
How 3PL pricing is actually structured
Third-party logistics pricing has three components regardless of provider, and comparing quotes means separating them.
- Receiving. A one-off charge when your inventory arrives at the warehouse, usually per pallet or per carton, sometimes per unit for anything needing individual handling.
- Storage. Ongoing, charged per pallet, per shelf, or per cubic foot per month. Slow-moving stock is where this quietly accumulates.
- Pick and pack. Per order, often with a base rate covering the first item and a smaller charge per additional item.
- Shipping. Passed through at the 3PL’s negotiated carrier rate, which is usually better than yours and is the main saving for smaller sellers.
- Extras. Kitting, custom packaging, inserts, returns processing, and disposal all have their own line.
The comparison trap is that providers weight these differently. One has low storage and high pick fees; another the reverse. Which is cheaper depends entirely on your ratio of orders to inventory. A high-turnover, low-SKU business and a slow-moving, wide-catalogue business will get opposite answers from the same two quotes.
Model it with your own numbers before signing. Take last quarter’s actual order count, average items per order, and average stock on hand, and run both quotes against it. The headline rates will tell you nothing useful on their own.
Also check the terms rather than the rates: minimums, setup fees, contract length, notice period, and what happens to your inventory if you leave. A provider with no minimums and no lock-in is worth a slightly higher per-order rate for a business still finding its volume.
The integration is an API contract
When a customer checks out, several things must happen across two systems that do not share a database.
- Your store tells the 3PL there is an order to ship, usually by API call or by the 3PL polling your platform.
- The 3PL confirms it, ships it, and sends back a tracking number.
- Your store marks the order shipped and emails the customer.
- Inventory counts update on both sides.
Each of those is a network call that can fail. The order webhook can time out. The tracking callback can arrive while your site is deploying. The inventory sync can run while an order is mid-checkout.
What separates a smooth operation from a chaotic one is how those failures are handled. Specifically: are the calls idempotent, so a retried order webhook does not ship twice? Is there a queue, so a failed call is retried rather than lost? Is there a reconciliation job that compares both systems daily and reports differences?
If the answer to any of those is no, you will eventually ship a duplicate or miss an order entirely, and you will find out from the customer.
Most platforms with an official 3PL app handle this reasonably. It becomes your problem the moment you have a custom storefront, a headless setup, or a 3PL whose integration is a nightly CSV — which is more common than the marketing pages suggest.
Inventory sync is a consistency problem
Two systems hold a number for how many units exist. They will disagree. The question is by how much and for how long.
Real reasons the numbers drift: a warehouse count finds damaged stock, a return is received but not yet processed, an order is placed while a sync is mid-flight, or a batch job runs on a schedule so the store shows yesterday’s count all morning.
The oversell that follows is expensive. You take money for something you cannot ship, and refunding it costs you the customer and often a marketplace metric.
The usual mitigations, in increasing order of effort:
- Sync more frequently, or move from polling to webhooks so changes push rather than wait.
- Hold a buffer — show zero when actual stock hits three — which trades a little revenue for far fewer oversells.
- Treat the 3PL as the authority for physical stock and your store as a cache of it, so there is one answer to who is right.
- Reserve stock at add-to-cart rather than at checkout for genuinely scarce items.
- Reconcile nightly and alert on any SKU where the two systems differ by more than a threshold.
The buffer is the highest-value change for the least work, and it is the one most stores skip because it looks like leaving money on the table. It is cheaper than the refunds.
What the storefront has to survive
The fulfillment provider is sized for your peak. The question nobody asks in the same conversation is whether the store is.
The failure mode is specific and seasonal. You plan a promotion, the 3PL staffs up, traffic arrives, and the site slows to the point where checkout times out. The warehouse is ready and the storefront is the bottleneck. No amount of logistics capacity helps.
Three things to check before a known peak:
- Whether the platform scales under load, and whether that is automatic or something you have to trigger while the promotion is running.
- Whether the database is the constraint. Ecommerce checkout is write-heavy and a database sized for browsing traffic behaves very differently under a burst of orders.
- Whether the webhook endpoint receiving 3PL callbacks stays responsive while the front end is busy, because if it does not, tracking numbers stop flowing and your support inbox fills up.
Autoscaling between a floor and a ceiling plan is the straightforward answer to the first, and it is worth configuring before the peak rather than during it — scaling up at a CPU threshold and back down afterwards means you are not paying for headroom in February.
The second is worth testing rather than assuming. Place a hundred orders against a staging copy and watch what the database does.
Returns, which are half the operation
Returns get a paragraph in most fulfillment comparisons and represent a large share of the actual work in several categories.
Questions worth answering before signing: who generates the return label, how long inspection takes, what happens to items that arrive damaged, whether restocking is automatic or manual, and how quickly a returned unit becomes sellable stock again.
That last one has a direct revenue effect. A unit sitting in a returns queue for two weeks is inventory you paid to ship twice and cannot sell. In categories with high return rates, the speed of the returns loop matters more than the pick fee.
On your side, the returns flow needs the same integration discipline as the outbound one: a status the customer can see, a refund triggered by a real event rather than a manual check, and a reconciliation that catches returns received at the warehouse but never reflected in your system.
When to outsource, and when not to
Fulfilling in-house is cheaper per order at low volume and stops being cheaper somewhere between a few hundred and a few thousand orders a month, depending on how you value your own time.
Reasons to stay in-house longer than the arithmetic suggests: heavily customised packaging that is part of the product, fragile or regulated items, very high SKU counts with low turnover, or a business where the packing step is genuinely part of the brand.
Reasons to outsource earlier: shipping cost is a large share of your price and the 3PL’s carrier rates are much better than yours, you are shipping internationally, or the founder is spending evenings packing boxes instead of doing anything that grows the business.
A middle option that suits many businesses is outsourcing the high-volume core products and keeping the awkward long tail in-house. It complicates the inventory picture, which brings us back to reconciliation, but it is often the right economic answer.
How this fits the rest of the stack
The logistics half of this decision gets all the attention and the integration half causes all the incidents. Idempotent order handling, a queue that retries, a stock buffer, and a nightly reconciliation are what stand between a working operation and a season of oversells. All of that runs on your side of the line, which means the storefront and the endpoint receiving warehouse callbacks need to stay up during exactly the busiest week of the year. The RunxBuild hosting calculator puts the web service, the database, and the bandwidth side by side, and autoscaling between a floor and a ceiling plan is the part worth configuring before the peak.
Useful related references:
- Ecommerce Websites: The Parts You Pay For Every Month
- PaaS Services: What You Are Actually Buying
- WordPress Maintenance Services: What You Are Actually Paying For
- Services on RunxBuild
FAQ
How much do ecommerce fulfillment services cost?
Pricing has three parts: receiving when stock arrives, monthly storage, and a per-order pick-and-pack fee, with shipping passed through at the provider’s carrier rate. Providers weight these differently, so run both quotes against your actual order count and average stock rather than comparing headline rates.
What is the difference between 3PL and FBA?
FBA is a marketplace’s own fulfillment programme, optimised for orders placed on that marketplace. A 3PL is independent and fulfils orders from any channel, including your own store. Many sellers use both — the marketplace programme for marketplace orders and a 3PL for direct sales, which keeps the direct customer relationship.
Why does my inventory count keep going out of sync with my 3PL?
Because two systems hold the number and updates are not instantaneous. Batch syncs, in-flight orders, unprocessed returns, and warehouse recounts all cause drift. Treat the 3PL as the authority for physical stock, hold a small buffer so you show zero before you truly hit zero, and reconcile nightly with alerts on large differences.
When should I outsource fulfillment?
Somewhere between a few hundred and a few thousand orders a month, depending on how you value your own time and how much better the 3PL’s shipping rates are than yours. Outsource earlier if you ship internationally or if shipping is a large share of your price. Stay in-house longer for fragile, regulated, or heavily customised items.
Can my store handle the traffic if fulfillment scales up?
That is the question the logistics conversation skips. A warehouse staffed for a promotion does nothing if checkout times out. Check that the platform scales automatically, that the database can take a burst of writes rather than just browsing traffic, and that your webhook endpoint stays responsive while the front end is busy.