Carrier integrations for a PrestaShop store

The label is created in the carrier's panel, and the number comes back to the store by copy and paste. At the busiest point of the day that's hours of warehouse work, plus one mistake away from a parcel going to the wrong address.

The order in the store still shows a status from before dispatch, so support checks the carrier's system by hand every time someone asks. It's the most common ticket in e-commerce, and the first thing that disappears after integration.

A locker, a courier, an oversized parcel and an international shipment each have a different economics. A store with a single delivery method is overpaying on some orders and has no idea which ones.

Setting up shipping and carrier accounts in PrestaShop

• ✓ Automatic shipping labels generated from the store or from base.
• ✓ Pickup points and lockers in the basket, with a map and postcode search
• ✓ Statuses from the carrier's API flowing back to the order and the customer
• ✓ Carrier account configuration and tests for dispatch, tracking and returns

We work on your own agreements and accounts with carriers, at your rates, so the integration changes nothing about them. A new carrier gets added alongside your current one, so you compare cost and delivery time on your own parcels, not on a promise. For a store that's still being built, carriers are part of that build and you don't pay for them twice.

• Support types tracking numbers into the carrier's panel by hand.
• Customers call asking where the parcel is, because they don't get statuses.
• You sell abroad and need a different carrier for each market.

• Shipping labels already go through base.: the store just needs pickup points and statuses.
• The problem is payment, not delivery: that's payment gateway integrations.
• The integration already works and it's about keeping it running: that's post-launch care, not building the integration.

A carrier integration is connecting the store to a courier's system in a way that closes the whole shipment loop: from choosing a delivery method in the basket, through the shipping label and pickup booking, to a status that reaches the customer on its own. Printing the label is the most visible part of this work, and the smallest.

PrestaShop stores: what our clients say

Connecting PrestaShop to carriers: four things we hear

All four come from experience with an off-the-shelf module that printed a label and stopped there.

„We already have a carrier module from the store's marketplace”

An off-the-shelf module prints a label. It doesn't know the store sells in three currencies, that some of the stock is oversized, or that a return needs to go to a different address than dispatch went from. Integration is the rules for choosing a carrier and handling returns, not just the printout.

„The customer still calls asking where the parcel is”

They call when they don't get a status. After integration, the status from the carrier's system flows back to the order and to the customer's email with no support involved, and the tracking number shows in their account. Those calls are the first thing to drop.

„We have base., why integrate the store too”

If shipping labels go through base., the store keeps pickup-point selection and status updates. We say that upfront, because duplicating that work makes no sense: some clients arrive with base. already set up and leave with a smaller scope than they'd planned.

„The carrier will change its API and the integration will break”

It will, sooner or later, and that's the most common cause of failures after go-live. That's why we keep status mapping in configuration, not in code: once a status name changes, you fix it from the store panel, no developer needed. A new API version on the carrier's side is developer work, covered by a post-launch care hours pool or quoted separately before it starts. A fault in our own build is fixed under the contract's warranty.

Carrier integrations: questions before you decide