PrestaShop shipping: configuration, costs and carrier services

What we would do

We would first map the delivery offer your existing shop can fulfil: dispatch origins, contracted services, customer markets and the staff who pack and hand over parcels. Review the installed modules, theme and checkout, stock or ERP integrations, catalogue weights and dimensions, and any custom order exports before choosing a replacement. Keep a working configuration where it meets the requirement; identify whether the gap is pricing, eligibility, pickup selection or warehouse work.

Make the agreed change on a staging copy with the same checkout and integrations, isolated from customer emails and live fulfilment exports. Use the provider's test environment where supported. Take matched file/database backups: a database-only restore does not undo module files or shipments created with the provider. Rehearse the acceptance checklist below, then schedule a planned switch with a named operator and the previous configuration ready to restore.

For an already selected courier module, the PrestaShop Module Installation & Configuration Service covers installation, agreed configuration and verification of the relevant journey; licences, additional modules and development are separate.

Configure zones, carriers and ranges

Start in International > Locations. Enable the destination countries and assign them to suitable zones. Core prices native delivery by zone. A country has one zone; states can have their own zone assignments. Split a broad zone when your tariffs differ, for example Domestic, Neighbouring EU, Other EU and Non-EU Europe.

1. Open Shipping > Carriers. Add a carrier or review the service created by your integration. PrestaShop 1.7.8 uses a carrier wizard. In PrestaShop 9, the carrier form can differ with the release and enabled carrier feature.
2. Set a clear customer-facing name, logo and translated delivery-time text. The speed grade is used when sorting by speed. A carrier's delay is multilingual text, not a separate transit value for each zone. Use separate service carriers when the messages must differ.
3. For a native paid carrier, choose either price-based or weight-based billing: each carrier uses one native billing basis at a time. To keep weight-based tariffs while granting free standard delivery above an order value, use the carrier-restricted cart rule below. Free carriers and external modules can work without native ranges.
4. Enable served zones and enter a tariff for each range and zone. Check customer-group access, shop associations and product carrier restrictions.
5. Select the carrier's tax rule. Set the global handling charge under Shipping > Preferences, then choose whether this carrier adds it. Check each product's additional shipping charge and do not count packaging twice if your tariff already includes it.
6. Set size and weight restrictions from the service contract. Core checks product dimensions and relevant weight limits. It does not pack multiple items into a box or calculate dimensional weight for you.

Illustrative tariffs only, in your shop's weight unit and currency:

The lower bound is inclusive and the upper bound exclusive. A 2 kg cart belongs in the second row. Ranges of 0 to 2 and 3 to 5 leave a gap. With Disable carrier, an unmatched cart can lose that option. With Apply the cost of the highest defined range, core can use the highest range even for an internal gap. Check the selected setting; do not assume a universal default. Do not use the highest tariff to bypass a courier's real acceptance limit.

Enter accurate product and combination weights. A zero-weight cart can still match a positive first tariff. Missing weights can undercharge, choose the wrong bracket or cause API rejection.

When an option is missing, trace country/state zone, carrier activation, group and shop access, product restrictions, ranges and limits. Then inspect the module's availability response. Use the destination and basket cases in the acceptance checklist below to reproduce the failure.

Choose free, flat or calculated shipping

A flat 4.99 charge may suit similar parcels, but needs checking for both a small accessory and a 20 kg order. Native brackets are calculated tariffs, not live courier quotes. Live quotes require an integration that actually supplies rating. Label printing alone does not provide it. No model guarantees higher conversion or profit.

Show your policy in the header, product information and cart. Mark early costs as estimates when the address or carrier is unknown. Recalculate after changes to destination, tax context, service or basket. A single-page checkout can present updated totals clearly, but cannot guarantee that a provisional cart amount stays identical.

Calculate and restrict free shipping

Use revenue and costs on the same tax basis. Include merchandise cost, carrier charges, packaging, picking and packing, labels, collection trips, insurance and expected loss or damage costs. Separate shipping paid by the customer from shipping paid by your business.

• At 60 revenue and a 40% gross margin, merchandise gross profit is 24. Absorbing 5 shipping leaves 19 before other costs.
• With 20% gross margin on a 100 sale, 10 shipping halves the 20 gross profit. A 20% markup is different: cost is 100 / 1.20 = 83.33, gross profit is 16.67, and 10 shipping leaves 6.67, a 60% reduction.
• If a 60 basket grows to 75, the extra 15 at 40% margin contributes 6 before any extra fulfilment cost. That can cover a 6 shipping subsidy in this example, provided the added products do not increase packaging or delivery cost. Recalculate when the extra item changes the parcel size, parcel count or available service. It does not prove customers will add items.

Review average order value, median, basket distribution, product margins and shipping costs by destination. An average does not show where most orders lie. High-value lightweight items, VIP groups and selected domestic services may support a subsidy. Heavy, thin-margin or distant orders need their own calculation. A high carrier bill alone does not prove the order loses money.

Choose the correct free-shipping control

Shipping > Preferences has global price and weight thresholds, stored as PS_SHIPPING_FREE_PRICE and PS_SHIPPING_FREE_WEIGHT. These normally make the native calculation zero. Core still calls external carrier pricing, which can return another amount. Verify every module-backed service. Test the price threshold around tax, currency and discount boundaries rather than deriving it from the customer group's display setting.

For domestic standard delivery on orders of at least 50, while express stays paid:

1. Disable both applicable global price and weight thresholds.
2. Open Catalog > Discounts, select Cart Rules and create a rule.
3. Under Conditions, set the minimum amount and its tax/shipping basis, the destination countries and the selected standard carrier. Add customer/group or product conditions when needed.
4. Under Actions, enable Free shipping.
5. Leave the code empty for automatic use, or provide a voucher code. Set dates, quantity and combination rules, then test qualifying and excluded carts.

This also supports an example such as free DPD on orders of at least 80 with UPS paid. Native carrier restrictions come first. A zero tariff on a carrier is only a zero base charge: handling, product surcharges or module pricing can still add a charge. The carrier's actual Free shipping setting is a different control.

Display a matching progress message, such as “Add 12 for free standard delivery”, including exclusions. Alternatives include subsidised delivery, a predictable flat rate or group-restricted benefits. For a first-order-only offer, add an explicit customer-order check through an appropriate workflow or extension.

Work through a mixed basket before publishing the offer

Suppose your policy is free domestic standard delivery above the chosen threshold, paid express and lockers for parcels that fit. A lightweight accessory can qualify for a locker. Adding a bulky product takes the basket over the free-shipping threshold but makes the packed parcel unsuitable for that locker. The higher order value changes the subsidy decision; it does not make an unsuitable service eligible.

1. Test the accessory alone and record the offered services and price.
2. Add the bulky product. Confirm the locker option is excluded by the agreed eligibility logic and that an eligible standard service receives the intended subsidy. Express should retain its agreed charge.
3. Remove the bulky item and check that eligibility and the free-shipping message recalculate. A selection retained from the previous basket must be validated again.
4. Repeat with an item sourced from another origin. Establish whether the order needs separate parcels and check the combined customer charge against the cost of fulfilling both.

Keep the basket contents, packed dimensions, destination, customer group and expected result as a reusable test case. If your integration cannot model the required split or packing, settle that fulfilment design before advertising the offer.

Build and measure a small-store delivery offer

Start with the services your customers need and your team can fulfil. A possible offer is standard delivery, a paid faster service and pickup delivery. These are examples, not a required number of carriers or universal transit promises. Keep names, price differences and delivery conditions clear.

Compare contracts using the actual origin, destination, parcel, insurance, fuel and remote-area charges. A country may need different payment methods, language and currency as well as delivery options. Check customs documents, duties, tax treatment and who pays import charges for each cross-border route. Do not infer tax or customs treatment from a zone name.

Record conversion, average and median order values, contribution after fulfilment, actual dispatch time, delivery performance and support contacts before changing policy. Identify campaign orders separately and allocate their actual carrier costs. Aggregate shop revenue and recorded costs alone do not establish campaign profitability. Choose a comparison duration and sample from your traffic, baseline variation and the effect you need to detect. There is no universal profitable shipping percentage or fixed order count.

Reconcile checkout charges with carrier invoices and review tariffs when contracts or surcharges change. Test the same awkward carts again after updates.

Evaluate a carrier integration

A carrier module can provide pricing, service availability, pickup selection, labels, manifests, tracking or returns. Verify each capability in the exact release. The underlying CarrierModule contract does not require every feature.

1. Confirm support for your exact PrestaShop release, PHP version, theme, checkout, multistore context and carrier account.
2. Use the isolated staging copy and matched restore point described above for installation and configuration.
3. Obtain the account entitlements, credentials and environment required by the provider. Keep private API secrets server-side.
4. Review each generated carrier's services, zones, groups, shops, pricing and product restrictions. Avoid duplicating carriers managed by the module.
5. Verify sender/return addresses, packaging and supported label formats. Check whether status automation, bulk labels, manifests and returns exist.
6. Run the complete acceptance checklist below, including checkout, pickup persistence, payment, label creation, tracking and notifications. Control any production tests that incur charges.

Do not assume an API failure falls back to the native grid. A module may return false, making its carrier unavailable. Use a fallback only if implemented and tested, or configure a separate eligible fallback carrier. Measure response time, request counts, retries and cache behaviour before diagnosing slow checkout.

Developer contract

Both paths can call a courier API. The external method is not a tax-exclusive counterpart to the range-aware method. Checkout display hooks such as displayCarrierExtraContent supply extra UI, such as a pickup selector, rather than calculating the shipping price. Establish the returned amount's currency and tax basis against core's conversion and subsequent tax processing. For package-aware quoting, use the actual product subset and packing logic rather than treating the whole cart as one parcel.

When creating a carrier, set required multilingual fields using numeric installed language IDs, including the default language. For example:

foreach (Language::getLanguages(false) as $language) {
    $carrier->delay[(int) $language['id_lang']] = 'See delivery conditions';
}

Editing a carrier can replace its row with a new id_carrier while preserving id_reference. Integrations must follow the reference and handle actionCarrierUpdate rather than keeping a stale row ID. Native tracking templates use @ for the tracking number when the integration relies on core tracking.

Updating a nonempty tracking number in the back office can send an in-transit email independently of an order-status email. Modules may send another notification. Test all paths for missing or duplicate messages. Label creation does not by itself establish that an order is dispatched.

Locate the failing pickup-point step

Trace the selected point from the search request to checkout storage, the order and the label request. Keep a redacted request or log entry at the first failing step. A visible marker on a map does not prove that the order has a usable destination.

Investigate script, widget and map-provider failures using the carrier-specific checks below. Avoid changing checkout templates until you know whether the failure is rendering, saving, validation or the fulfilment handover.

Check DHL, DPD and UPS services

Choose by contracted service and dispatch origin, not logo. DHL Paket, DHL Express and DHL eCommerce are distinct offerings. The German DHL integration supports shipments originating in its supported market, including DHL Paket International and Warenpost International; it is not limited to domestic destinations. See DHL's integration feature list.

For DPD, verify the national account, service endpoints and module's supported origins. Shipping abroad from one origin is different from shipping from accounts in several countries. Do not assume one web service or a third-party module unifies every branch. For UPS, verify the current authentication method, account entitlements, negotiated rates and supported services in the chosen integration. Do not infer “all services” from the availability of a rating API.

Check actual and dimensional weight under the particular tariff. A lightweight 40 × 40 × 20 cm parcel may be billed dimensionally under an applicable service, but not every ground or domestic product follows the same rule. Compare quotations including all surcharges. Avoid universal cheapest-carrier or worldwide transit rankings.

Test the provider-approved tracking link with real identifiers from each service and origin. A plausible URL template is not proof of cross-service tracking support. Core tracking configuration also has integration-specific exceptions, including the official Mondial Relay flow below.

Plan InPost locker delivery

Locker delivery needs a selected point ID, a parcel that fits the contracted service and a working label destination. For Polish domestic ShipX, obtain the assigned organisation ID and generate a dedicated access token. The GeoWidget token is separate. Do not generate an organisation ID yourself or expose the shipping token in the browser.

For Polish Paczkomaty parcels, InPost lists A at 8 × 38 × 64 cm, B at 19 × 38 × 64 cm and C at 41 × 38 × 64 cm, each with a maximum weight of 25 kg. Its separately listed XS option is limited to the InPost Mobile app and is not a generic extra shop service. Confirm the applicable contract and packaging rules before configuring limits. A single item's fit does not prove the whole basket fits. Define packaging, oversize exclusions, insurance and the behaviour of mixed carts.

Test the picker on your real checkout and mobile devices. Check the correct widget version, token, permitted domains, CSP, script and tile requests, and initialisation after address changes. Persist and validate the selected point server-side; verify it survives checkout refreshes and appears in the label request. Do not assume every failed picker is a jQuery conflict.

Polish domestic ShipX is not a universal international integration. The Global GeoWidget documentation requires Global APIs. Verify supported routes, account and module rather than merely enabling another country's zone.

Check label formats and bulk processing. Confirm whether tracking and status updates arrive by webhook, scheduled job or another supported mechanism, configure it and test that a carrier update reaches the order. Confirm the actual collection deadline in the selected service. Prepare a process for non-collection, return and re-shipment. Locker networks consolidate delivery stops; they still have a last mile and are not automatically cheaper under every contract.

Model GLS with multiple dispatch origins

Create an origin/service matrix before setup: shipping country, account/customer and consignor identifiers, API platform, endpoint, test access, enabled services, limits and return route. National differences do not prove every GLS subsidiary uses a separate API; ShipIT supports multiple shipping countries. Ask GLS which platform and entitlements apply to each account.

Share a customer-facing carrier such as Standard, ParcelShop or Express only when the module supports origin selection and correct availability and pricing before checkout. Otherwise scope carriers or shops appropriately. Native zone tariffs do not automatically price by warehouse origin. Verify shop-scoped credential storage instead of assuming multistore provides it.

For ParcelShop delivery, require searchable, accessible point selection and a validated ParcelShop ID passed to fulfilment. A map can help, but a usable list is also valid. Verify opening hours and point availability. Match the tracking link to tested identifiers from every origin. Record limits and return procedures by country, product and contract; do not infer a lower weight ceiling merely because a ParcelShop accepts the parcel.

Do not plan a current multi-origin setup around the legacy warehouse-based Advanced Stock Management feature. Use an appropriate stock/ERP integration for sourcing from multiple origins. PrestaShop 9.1's experimental improved-shipment feature also requires separate validation; it does not automatically supply warehouse sourcing.

For example, a shop fulfils French orders from stock in Germany or Italy. Test the same destination with each origin and keep the selected account, service, quote and label sender together. If sourcing changes after checkout, recalculate the fulfilment cost and confirm that the purchased service and pickup destination remain achievable before requesting a label. A customer-facing Standard option is usable only when that routing is supported throughout the journey.

Check Colissimo home, pickup and overseas delivery

Distinguish home delivery with or without signature, pickup delivery, international and overseas products. Confirm the handover rules for without-signature delivery, including mailbox delivery and the alternative procedure. Promise unattended doorstep delivery only when the contracted service permits it.

The official module requires an eligible Colissimo contract and service rights. Its published features include pickup-point displays, label generation, customs documents, tracking/status updates and return labels with customer access or email delivery. Check the exact release before paying for purported missing features or assuming current PrestaShop compatibility from an older feature page.

Overseas territories need destination-specific services, tariffs, documents and tax treatment. They are not interchangeable with mainland France. Use the current service estimate rather than one overseas delivery promise: La Poste lists indicative standard OM transport of 5 to 11 days excluding customs. For the listed Eco OM routes, it gives 18 days to Martinique, Guadeloupe, Réunion and Mayotte, and 22 days to French Guiana, also excluding customs. These are route-specific indications, not one universal overseas promise. Confirm the route in La Poste's overseas guidance.

Test pickup point selection, destination persistence and the generated label. Do not assume selecting a pickup point overwrites PrestaShop's delivery-address record. Check service saturation or diversion procedures, dispatch status and customer tracking. Compare pre-issued and on-demand return labels using your contract's billing rules. No order-volume threshold universally justifies a paid module.

Check Mondial Relay pickup delivery

Match the exact module and API generation. Classic integrations distinguish Enseigne Webservice, Code Marque for the widget and the private web-service key. Keep the private key server-side. A SOAP integration needs the appropriate PHP SOAP extension; confirm it in the PHP runtime used by the shop, not only the command-line runtime.

Check weight units. Converting catalogue kilograms to an API field in grams uses a factor of 1000. Confirm what the module's coefficient actually means before entering it. Use only contract-supported service codes. The official tutorial distinguishes relay shops and lockers, including modes such as 24R/MED and 24R/APM.

Enable supported destinations rather than excluding Germany by assumption. The official tutorial includes Germany and Austria. The cited tutorial lists relay parcels up to 30 kg, with length up to 120 cm and length + width + height up to 150 cm; lockers are listed up to 25 kg and 64 × 41 × 38 cm. Confirm route/service restrictions rather than imposing an invented general 20 kg ceiling.

The widget v4.1 documentation uses Leaflet/OpenStreetMap by default, with Google Maps optional. Investigate the actual provider, dependency order, CSP, initialisation, postcode and network responses before looking for a Google key. Validate point persistence after address changes and checkout refreshes.

For the module described in the official carrier tutorial, the tracking URL field stays blank because the module supplies the front-office order-history link. Follow your installed integration's documented tracking flow. Check its sender settings and API sender fields before changing the merchant contract. Verify single/batch labels, printer formats, portal exports, dispatch automation and return-label support in the exact version.

Show the selected point's name, address, opening hours and collection conditions at checkout and in the order confirmation. Where supported, base a collection reminder on the parcel's actual deadline and update the point details if the carrier diverts it. Pickup can reduce missed-doorstep attempts, but closed points, diversion, unavailable lockers and non-collection still need handling.

Offer same-day or next-day delivery responsibly

Separate processing time from transit time. Audit stock availability, picking, packing, daily handover, cutoff, weekends and closures. Next-day feasibility depends on the route and service, not the store platform. Same-day delivery needs a proven service area, stock proximity and staffing.

A possible design is standard delivery, a paid next-day service where available and local same-day delivery. Country/state zones only work for local delivery when they exactly match the area. Otherwise enforce postcode or city eligibility before offering the carrier. Weight and price brackets add no geographic precision. Native carrier text does not enforce a clock cutoff.

Use conditional language that remains true after cutoff. Rehearse the same stocked basket before and after your actual cutoff, across a closed day and with a back-order item added. Check the shop clock and working calendar: offer a revised achievable estimate or remove the fast option according to the agreed policy, while retaining an eligible standard route where available. Review both uptake and the percentage of promises met. Low uptake can reflect demand, pricing, messaging or eligibility. Measure rather than assigning a cause.

For estimates on product pages, in the cart and at checkout using product or combination data, stock, processing time, cutoff, weekends, configured closed dates, destination and the available carrier's transit calendar, see the Estimated Delivery Date help page. Verify the installed release and checkout integration, including the accepted estimate saved on the customer and staff order records.

Run an end-to-end acceptance checklist

Write the expected price and eligible services before testing, then keep the cart or order reference and actual result. Cover each intended destination, customer group and shop context, plus each dispatch origin when routing differs. Use the installed theme and checkout, including guest and signed-in journeys.

Record checkout response times during the API tests and compare the quoted shipping with the provider's shipment charge and eventual invoice, including surcharges. Keep the tested basket definitions so a module, theme, checkout or tariff change can trigger the relevant checks again.

Plan the switch and developer handover

Roll out the tested module and settings through the rehearsed procedure while preserving new live orders and customer data. Do not replace the current live database with the older staging database. Record the carrier references, restrictions, tariff basis and module release being changed, with a clear trigger for reverting the configuration.

After the switch, reconcile the first relevant orders through checkout charge, label, tracking and notification, and assign someone to watch failed quotes and label requests. Reversal must account for orders already accepted and shipments already created: restoring settings is separate from resolving those transactions.

What to ask your developer or agency

• Which baskets, origins, destinations and shop contexts passed, and where is the evidence for the failure cases?
• How is the dispatch account chosen before quoting, and how does that choice reach label generation and any ERP export?
• Which component validates and stores the pickup point, and what happens when the customer changes the address or returns from payment?
• Who owns failed shipments and status synchronisation after handover, and what can staff safely retry or reverse?

Questions owners ask

The customer paid, but the pickup point is missing. Can we choose the nearest one?

Hold label creation and contact the customer for an agreed valid point. Store it through the integration's supported correction route, then confirm the label destination. Choosing a point without agreement can send the parcel somewhere the customer cannot collect it.

Can we change the address after a label has been created?

Check the courier's supported correction or cancellation process and the parcel's handover state. Updating the PrestaShop address does not by itself redirect the shipment behind an existing barcode. Keep the corrected order record and the actual carrier destination aligned.

A label request timed out. Should we click again?

Check the provider account and module logs for a shipment already created before retrying. Use the integration's supported recovery or reprint process; an unanswered request may still have bought a label, and an unchecked retry can create another shipment or charge.

Does cancelling the order refund the carrier charge?

Treat the customer refund, label cancellation and any carrier credit as separate operations. Check your contract and the provider's recorded outcome, then reconcile each charge. An order marked cancelled is not evidence that the courier has voided its label.