In August 2026 I built shipping-label integrations for two very different marketplaces in the same month. One sells spirits in the UK. One sells antiques in Denmark. Same feature on paper: seller clicks a button, a carrier label comes out.
Almost none of the actual work was about logistics. It was about money - specifically, about a question I've never seen a marketplace guide ask directly:
Whose account gets billed when a seller prints a shipping label?
Sit with that one for a second, because the answer defaults to "yours", and most founders find out three months late.
On a normal store, shipping is one relationship
If you run a regular ecommerce shop, shipping is simple in a way you stop noticing. You charge the buyer for shipping, you print the label from your own carrier account, the difference between the two is your problem and nobody else's. One party, one carrier relationship, one bill.
A marketplace quietly splits that into three flows that don't line up:
The buyer pays whatever shipping price the platform configured at checkout. That number is a pricing decision, not a cost. It has no necessary relationship to what any label costs.
The seller is the one standing next to the parcel. They need to produce a label. But your sellers are hobbyists, side-hustlers, small shops - they are not going to individually negotiate carrier contracts and maintain API keys. If label printing exists at all, it exists because the platform provides it.
Which means the platform owner holds the carrier relationship. And here is the part that gets skipped in every feature announcement (including, honestly, my own): when a seller clicks "Create label", the carrier bills the account holder. That's you.
Buyer pays the platform. Platform pays the seller. And now there's a third stream running backwards: carrier costs flowing from your sellers' shipments onto your account. Shipping isn't a feature. It's a fourth money flow in your marketplace, and it's the only one that's negative by default.
The trap has a shape
Here's how it plays out in practice. A founder connects their carrier account to be helpful. Sellers love it - of course they do, someone else is buying their postage. Volume grows. The founder is billing sellers a subscription, taking a commission, everything looks healthy. Meanwhile the carrier account quietly accumulates label costs that nobody is re-billing to anyone.
If your sellers pay you monthly, you can catch this within a billing cycle. The nasty version is yearly seller plans: I hit this myself this month. Label fees were designed to ride the seller's next subscription invoice - which is fine on monthly billing and a disaster on yearly billing, because "next invoice" is eleven months away. The seller accumulates a year of postage, the platform fronts it the whole time, and then the seller gets one shock bill big enough to make them churn. I ended up building a monthly sweep that collects accumulated label fees on the 1st of every month regardless of the seller's plan cadence.
The lesson generalizes: the question isn't just "who pays for the label", it's "who pays, and when". Cost recovery needs its own clock, not your subscription's clock.
Four things I'd decide before connecting any carrier account
This is the checklist I wish someone had handed me. All four are money decisions dressed up as settings.
Who pays for the label? Options: the platform eats it (fine if your commission covers it - do that math), or it's re-billed to the seller automatically. "We'll sort it out manually" is not an option at any real volume.
When do they pay? Per label, monthly, or on their next subscription invoice. See above: if any of your sellers are on annual billing, "next invoice" means you're their bank.
What's the cap? The spirits marketplace taught me this one. A label from the platform's account is fine for a £60 bottle. For a £2,000 bottle, the carrier's standard compensation won't cover a loss, and the platform is the one holding the liability. We set a maximum order value: above it, the label button disappears and the seller ships via their own insured courier with manual tracking. Decide your number before your first four-figure order, not after your first four-figure loss.
Whose carrier contract is it? Aggregator wallet rates are convenient, but they come with the aggregator's terms - and those terms exclude entire categories. Alcohol, for instance, is prohibited on the built-in rates we looked at, so the spirits marketplace has to run labels through its own carrier contract, connected inside the aggregator. What a carrier will carry, and what it will compensate, is set by the contract - and the contract belongs to whoever's name is on the account. That's you again.
Two production gotchas, free of charge
Two things that only showed up once real labels were involved:
Some label APIs have no sandbox. Every "test" label is a real purchase billed to a real account. You test read-only against the live account, and you void unused labels to claw the cost back. Budget for the fact that testing shipping costs actual money.
Default parcel weight is a pricing input, not a formality. The Danish marketplace had labels booking in the smallest weight class while actual parcels were heavier. Carriers reconcile at pickup, so the costs surface later, as surcharges, where nobody's looking. If your platform has a default weight field, that field is quietly pricing every label in the marketplace.
One distinction that saves you a rebuild
Shipping integrations come in two species, and founders conflate them constantly:
A rates provider quotes live carrier prices at checkout. The buyer pays actual cost.
A label provider produces the label after the sale. The buyer pays whatever price you configured; the label cost is a separate, backwards flow.
They feel similar and they are architecturally different products. Live rates couple your checkout to a carrier API. Label printing couples your cost recovery to your billing system. Know which one you're asking for before you build or buy, because "add shipping" can mean either, and the wrong one is a rebuild.
Full disclosure, as always: I run Prometora, a marketplace platform, and the label-billing, caps, and cost-recovery mechanics above are the corner of this problem it covers (via ShipStation and Shipmondo, as of August 2026). The pattern is the point, though - it applies the same on Sharetribe, on a custom build, on anything.
The takeaway
Shipping looks like a logistics feature, so founders evaluate it like one: which carriers, which countries, how fast. Evaluate it like a money flow instead. Buyer to platform, platform to seller, carrier to you. The first two flows you designed on day one. The third one gets designed by default - and the default is that you pay.
Decide who pays for the label, when they pay, what the cap is, and whose contract it rides on. Write those four answers down before you connect the account. It's twenty minutes of thinking that's much cheaper than discovering the answers one invoice at a time.
- Rasmus