PrestaShop delivery estimates: dates, cutoffs and customer messages

What we would do

Start with your existing delivery labels and dispatch records, then add calculated dates where the inputs are dependable. The right setup depends on your stock source, fulfilment integrations, modules, theme, checkout, destination markets and the team maintaining the rules. Establish which system owns each input before adding another estimate.

For a module or theme change, use a private staging copy with the shop's actual configuration, isolated from real carrier bookings, fulfilment exports and customer emails. Rehearse representative orders, agree the live switch and keep the previous settings and integration ready to restore. Preserve promises already accepted by customers when changing the calculation.

If you want the setup handled, the PrestaShop Module Installation & Configuration Service can configure an agreed module and verify the scoped journey; additional development needs a separate scope.

Separate dispatch from delivery

A delivery estimate answers when the parcel should reach your customer. A dispatch estimate answers when you expect to hand it to the carrier. Label the two clearly. A dated range such as "Estimated delivery: Tuesday 27 to Thursday 29 October" removes the need for your customer to count business days.

Keep preparation and transit separate. A product that needs three days of assembly does not have the same dispatch date as a stocked item, even when both use the same courier. A pre-order availability date is an input to your policy, rather than a complete handling-time calculation.

Decide whether processing starts at order placement, payment confirmation or another fulfilment milestone. Apply that rule consistently to bank transfers, delayed payment callbacks and orders awaiting approval.

Use native delivery labels correctly

PrestaShop supports carrier Transit time text and product delivery-time labels. The carrier field is customer-facing text, such as "2 to 3 business days", shown with shipping options. It is not a structured numeric range that a date calculator can reliably parse.

Products can use default delivery labels or product-specific in-stock and out-of-stock labels. Check the selected delivery-time mode and your theme's rendering. These labels describe timing; they do not calculate a calendar date from a cutoff, processing rule and holiday calendar.

Find the carrier wording under Shipping > Carriers. On the product's Stock tab, review Availability date and the when out of stock behaviour alongside the delivery labels. Menu layout varies by release; record which value your stock integration actually updates.

Keep product availability, permission to order out-of-stock items and supplier lead time consistent. Do not show "ships today" for a backorder unless your fulfilment process supports that promise. For carrier and rate configuration, use the PrestaShop shipping guide.

Prepare the inputs before changing settings

1. Follow a real order: compare its payment confirmation, stock allocation, packing completion, carrier handover and delivery. A printed label is not evidence of collection.
2. Separate product groups: identify stocked, assembled, supplier-dispatched and pre-order items. Record combination and quantity exceptions rather than assuming the product's default applies to every purchase.
3. Map each service: record origin, destination coverage, collection schedule and transit range. Check remote postcodes and services offered by checkout modules.
4. Agree the calendars: write down timezone, cutoff, warehouse closures and carrier delivery days. Name the person who maintains each source.
5. Write expected results: use the worked examples below and a real exception from your shop. Compare the chosen module's output with those results before publishing a promise.

Work back from the last collection to set your cutoff: allow enough time for payment clearance, picking and packing. Copying the collection time itself leaves no preparation margin.

Calculate working days and cutoffs

First define what a day means for each stage. A carrier may deliver on Saturday while your warehouse is closed. Use the service's actual calendar, rather than assuming every service follows Monday to Friday.

1. Convert the order time to the warehouse timezone.
2. Compare it with the cutoff, including minutes if your policy needs them. In the example below, an order exactly at 14:00 is after the cutoff.
3. Move an after-cutoff order to the following date.
4. Normalise that date to the next working day, even when processing is zero.
5. Add processing days, then transit days, using the calendar for each stage.

The following PHP example defines zero processing days as dispatch on the normalised starting date. One processing day means the next working date after that start. Positive transit days are counted after dispatch without first moving dispatch to a carrier working day. Two transit days after Monday means Wednesday; two after a Saturday dispatch with a Monday-to-Friday carrier means Tuesday. Zero transit days use the first carrier working date on or after dispatch. The calendars are explicit inputs.

function isWorkingDay(DateTimeImmutable $date, array $weekdays, array $closed): bool
{
    return in_array((int) $date->format('N'), $weekdays, true)
        && !in_array($date->format('Y-m-d'), $closed, true);
}

function addWorkingDays(DateTimeImmutable $date, int $days,
    array $weekdays, array $closed, bool $normalizeStart = true): DateTimeImmutable
{
    if ($days < 0 || !$weekdays) {
        throw new InvalidArgumentException('Invalid day count or working week.');
    }
    foreach ($weekdays as $weekday) {
        if (!is_int($weekday) || $weekday < 1 || $weekday > 7) {
            throw new InvalidArgumentException('Weekdays must be integers from 1 to 7.');
        }
    }
    $date = $date->setTime(0, 0);
    if ($normalizeStart || $days === 0) {
        while (!isWorkingDay($date, $weekdays, $closed)) {
            $date = $date->modify('+1 day');
        }
    }
    while ($days > 0) {
        $date = $date->modify('+1 day');
        if (isWorkingDay($date, $weekdays, $closed)) {
            --$days;
        }
    }
    return $date;
}

$zone = new DateTimeZone('Europe/Warsaw');
$placed = new DateTimeImmutable('2026-10-23 14:01:00', $zone);
$cutoff = $placed->setTime(14, 0);
$start = $placed >= $cutoff ? $placed->modify('+1 day') : $placed;
$warehouseWeek = [1, 2, 3, 4, 5];
$carrierWeek = [1, 2, 3, 4, 5];
$warehouseClosed = [];
$carrierClosed = [];
$dispatch = addWorkingDays($start, 0, $warehouseWeek, $warehouseClosed);
$arrival = addWorkingDays($dispatch, 2, $carrierWeek, $carrierClosed, false);
// Dispatch: 2026-10-26. Arrival: 2026-10-28.

Validate holiday input as real dates in the same timezone. Maintain warehouse and carrier closures separately when they differ. The example uses no holidays; adding a warehouse closure on Monday 26 October moves dispatch to Tuesday and arrival to Thursday. It assumes the carrier can collect on the calculated dispatch date. If collection is unavailable, move handover to the next collection slot before adding transit days; warehouse working days and carrier collection and delivery days can differ.

Simply adding two calendar days to Friday gives Sunday 25 October. The after-cutoff example instead gives Wednesday 28 October, three calendar days later. Neither the order day nor closed days should be counted accidentally.

Handle mixed baskets, routes and uncertainty

Base your processing allowance on measured fulfilment times. If same-day dispatch is unreliable during an ordinary busy day, give yourself more time or move the cutoff earlier. Check the effect on both missed delivery promises and completed purchases.

• Mixed baskets: if everything ships together, use the latest ready date among the items. If you split shipments, show the separate parcels and dates.
• Several origins: use the warehouse that will actually fulfil the line. An origin that has not yet been allocated makes the estimate provisional.
• Several services: combine the correct carrier range with each service's collection and delivery days.
• International orders: consider destination holidays and customs only on routes where they apply. Do not assume a fixed customs-delay allowance.
• Uncertain transit: show an earliest and latest date supported by your service data. Keep the word "estimated" visible.

For a worked basket, suppose a stocked accessory is ready on Monday and a made-to-order item on Thursday. Shipping together means Thursday is the earliest dispatch, even if the accessory alone could dispatch on Monday. Express can shorten transit after Thursday; it cannot shorten manufacturing. If the supplier has not confirmed readiness, do not turn its provisional date into a firm arrival promise.

For example, compare "Express: EUR 8.90, estimated Wednesday" with "Standard: free, estimated next Monday". Only show these choices after calculating the dates for the actual basket and address. The example illustrates a choice, not a carrier price or service guarantee.

Keep the promise visible through checkout

Put the estimate near the buying decision. Explain whether it covers dispatch or arrival, which service it assumes and whether an address is still needed.

1. Product page: show the provisional estimate near the price and add-to-cart control. Recalculate when a combination or quantity changes if these affect preparation.
2. Cart: calculate for the whole basket and the split-shipment policy. Modern default themes use checkout/cart.tpl and partials; shopping-cart.tpl belongs to legacy themes.
3. Delivery step: update for the chosen carrier and destination. Place speed and price together.
4. Confirmation and email: save and repeat the accepted estimate. Do not silently replace the original promise with today's recalculation.

In modern themes, displayProductAdditionalInfo is a possible product-page placement. Its exact position depends on the theme. Cart, checkout and the order_conf email each need their own integration and data flow.

The module help covers its product-page implementation: shop processing time, cutoff, weekend exclusion, explicit closed dates, carrier transit ranges and product processing rules, using the shop's default carrier without destination input, localised date text, and an estimated dispatch label when no transit range is configured.

Estimated Delivery Date supports cart and checkout estimates, destination rules and saved order estimates; the help summary above describes a product-page calculation using the default carrier. Check which features your installed release supplies, then test the required placements, address and carrier changes, and retrieval of the saved promise. Once dispatched, provide tracking details and explain where customers can check progress.

Adjust for closures and peak periods

Review carrier service notices and your packing backlog before Black Friday, Christmas, Easter and other busy periods. Adjust processing or transit when those inputs change. Use a dated range when a single date suggests more certainty than you have.

A message such as "Order by 18 December for estimated delivery before Christmas" needs a defined year, service, destination, cutoff and exception policy. Remove it when the deadline passes. A countdown must roll over at the correct local cutoff and refresh after midnight, including on cached pages.

Test daylight-saving transitions, Friday after cutoff, weekends, public holidays, zero processing days, backorders and changes of carrier. If you cannot calculate a dependable arrival range, explain dispatch timing and provide a way to ask about urgent orders.

Find faults before the live switch

What to ask your developer or agency

Ask for the source of every input, the precedence of product and carrier rules, the events that trigger recalculation and evidence from your actual theme and checkout. Request examples for an anonymous visitor, a signed-in buyer with an address and a delayed payment. Ask where the accepted window is stored and how support retrieves it without recalculating it.

Agree who checks the first live orders, what failure triggers reversal and how the previous configuration is restored. The handover should identify settings changed, test baskets used and any unsupported placement, so your team can distinguish a configuration change from further integration work.

Measure accuracy and communicate delays

Save the original promised window with the order. Compare actual carrier delivery with the end of that window. Keep dispatch performance separate, so warehouse delays do not disappear into a transit average.

On-time delivery rate = delivered orders arriving on or before the promised latest date
                        / delivered orders with a recorded promise
                        * 100

Review a defined period, such as one month, by carrier, route, warehouse and product lead-time group. Note the sample size and missing tracking data. Set your service target from the service you sell and the performance you can sustain, rather than an arbitrary universal percentage.

If dispatch is late, review stock accuracy, processing rules and collection cutoffs. If dispatch is on time but arrival is late, review the carrier range and route. If orders arrive much earlier, assess whether a tighter estimate remains dependable before changing it.

Tell customers when a delay changes their expected date. Include the revised window, available tracking and the next update. Compare delivery-related contacts and checkout outcomes before and after changes using comparable periods. A visible estimate makes timing clearer; its commercial effect depends on your shop.

Questions owners ask

Can a customer choose an arrival day from this estimate?

An estimate describes the expected outcome of the selected service. Choosing a delivery appointment needs a separate booking process with service coverage, capacity and carrier confirmation. Do not present a calculated date as a reserved slot.

What if an order is edited after checkout?

Retain the original promise and record any revised window with the reason for the change, such as an added made-to-order item or a different address. Confirm the revision with the customer and make the history visible to support.

How do I measure orders without a delivered scan?

Mark their delivery outcome as unknown and report that group alongside the measured sample. Neither a tracking number nor a dispatch scan proves arrival. Keep those orders visible for follow-up rather than counting them automatically as on time.

Who maintains the rules after setup?

Give a named operations owner responsibility for upcoming closures, supplier changes and carrier notices, with cover for their absence. Record why an input changed and when temporary settings should end. For shop clocks and calendar evaluation, see schedules and holidays.