DPD module check and set delivery status for Prestashop

What the module is for

• No more manual status switching. Orders shipped with DPD are automatically changed to the shipped status, and after delivery – to the delivered status, without checking each parcel on the DPD tracking page.
• Up-to-date information for the customer. A status change triggers the email assigned to that status in PrestaShop (e.g. about the order being shipped), so the customer receives a message on the first check after DPD actually takes over or delivers the parcel.
• Order status kept tidy. The delivered status appears only when DPD confirms delivery.
• Dispatch status. The status is set when the events of at least one shipment in the order include a code from the “shipment dispatched” list: collected by courier, dropped off at a DPD Pickup point, accepted at a sorting centre or branch, out for delivery, or waiting at a pickup point.
• Delivery codes also count. If the parcel has already been delivered and the order still has a pre-shipping status, the module will set the shipping status and, in the same run, also the delivery status – if both checks are enabled and the shipping status is among the statuses checked for delivery (as in the default settings).
• Just registering the data is not dispatch. The event “shipment data registered, shipment not yet dispatched” (code 030103) does not change the status.

Delivery status

• All parcels delivered. The status is set when every shipment in the order has a code from the “shipment delivered” list: delivered to recipient, delivered with cash on delivery (COD), delivered with carry-in service, collected at a DPD Pickup point, and the other delivery codes from the DPD event table.
• Waiting at a pickup point is not delivery. Code 410135 (“ready for collection at DPD Pickup”) means the parcel is waiting for the customer and does not change the status to delivered.
• Returns and losses are blocked. DPD marks a return sent back to the sender with the same code as delivery, which is why a shipment with a code from the “returned or lost” list (return to sender, returned shipment) is blocked from being treated as delivered.

Shipment numbers

• Multiple numbers in one field. Numbers in the shipment number field may be separated by a space, comma, semicolon, or vertical bar; the module also takes numbers from each carrier row in the order.
• Up to 10 numbers per order. A number must be 6 to 32 letters or digits; letter case does not matter.

Editable DPD code lists

• Three lists in advanced settings. “Shipment dispatched” (40 codes by default), “shipment delivered” (20 codes), and “shipment returned or lost” (24 codes). The default lists were built from the DPDInfoServices event table published by DPD Polska in 2026.
• An empty list reverts to the default. Codes are entered as numbers separated by commas or new lines.

Which orders are checked

• Selected DPD carriers. Carriers are saved by permanent identifier (reference), so editing a carrier in PrestaShop, which gives it a new ID number, does not exclude it from checking. The list includes carriers from all shops, including inactive and module carriers.
• Selected statuses. For shipping and delivery checks, you separately choose the statuses to check and the status to set. After installation, both checks are disabled; by default, the status to set is the shipped and delivered order status, and delivery checking includes orders in shipped status. Orders that already have the target status are skipped.
• With a shipment number. The number comes from the shipment tracking number field in the order, entered manually or by another module; on PrestaShop 1.7 the module also reads the older order shipping number field.
• Not older than the selected number of days. By default, 30 days from placing the order; 0 means no limit, the maximum is 3650 days.
• Queue without skipping. Orders never checked are processed first, then those checked the longest time ago. You set the number of orders per run from 1 to 1000 (default 100), and the rest wait for the next run.

Automatic checking via cron

• Module controller URL. The Cron tab provides three URLs: checking dispatch and delivery, dispatch only, or delivery only, with copy buttons and a sample crontab line (every 30 minutes). The URL can be added to cron jobs on your hosting or to the PrestaShop “Cron jobs manager” module.
• Works on PrestaShop 9. Cron is a module controller, not a separate PHP file in the module directory, whose calls are blocked by PrestaShop 9 .htaccess rules.
• JSON response. It contains the run status, the number of checked orders, and the order numbers marked as shipped, delivered, and returned. HTTP codes: 200 after checking, 403 for an invalid token, 409 when another check is in progress.
• Shop maintenance mode. Cron also works when the shop is disabled for maintenance and is not blocked by geolocation restrictions.
• No parallel runs. A database lock prevents a second check from starting while the first one is still running.
• Limited execution time. One request to DPD waits at most 20 seconds, and the run stops accepting new orders after about 50 seconds, leaving the rest for the next run. An invalid login stops the run on the first refusal from DPD, and three consecutive connection errors stop it after the third attempt.
• URLs from version 1.x. On PrestaShop 1.7 and 8, the previous modules/pddpdcheckorderstate/cron.php URL still works because the update keeps the old key as the token. For 30 days from the last call to the old URL, the Cron tab displays a warning with its date. On PrestaShop 9, you must use the new URL.
• Dashboard and manual tools. The module page shows counters for the last run (checked orders, status changes, returns and errors), the number of orders waiting for each check, status changes from the last 7 and 30 days, and the 10 most recent changes with links to orders.
• “Check and update orders”. Runs the same check from the admin panel as cron, with the same limits.
• “Test DPD connection”. Checks whether DPD accepts the saved login and password.
• “Check shipment number”. Shows DPD events for a single shipment (time, code, description, branch) with an indication of which codes the module treats as dispatch, delivery, return, or redirection, and the result: what the module would do with the order. It does not change anything.
• Settings in five sections. DPD connection, DPD carriers, Shipped orders, Delivered orders, and Advanced – switched by tabs and saved with one button. If there is a form error, the section with the first error opens, and sections with errors are marked.
• Configuration warning. When the status set by the module is also among the checked statuses, saving displays a warning.

History and diagnostics

• Every status change. Date, order with reference number and link, shipment number, previous and new status, DPD event code and description, event time, and source: cron, admin panel, or old cron URL.
• Errors without flooding the history. An error for the same order is saved again only when it changes, and run-wide errors (e.g. login failure, no response, invalid XML) are saved once per run.
• History list. Filtering by date, order, shipment number, source, and type (status changes, returns, errors); 50 entries per page. Entries older than 180 days are deleted automatically, and the “Clear history” button removes all entries.

Connection to DPD Polska

• DPDInfoServices service. The module uses the getEventsForWaybillV1 operation – the single-shipment tracking service described in the DPD Polska documentation. The new DPD Services REST API does not include a tracking operation, so DPD Polska provides DPD shipment statuses through DPDInfoServices.
• Login and password from your DPD account manager. Credentials for DPDInfoServices are provided by the DPD sales/account manager; they are usually the same as for DPD Services (label printing). The channel field (FID) is optional – fill it in only if DPD has assigned a channel number.
• DPD test environment. The settings include the DPD test environment URL with a public test login. It checks login and request correctness, but does not return shipment events.
• No SOAP extension. The module sends requests via cURL and does not require the PHP SOAP extension or downloading the WSDL file with every request.

Security and permissions

• The DPD password is not sent back to the browser. The password field is always empty, and leaving it empty when saving keeps the saved password. When changing the service URL to another server, you must enter the password again.
• Encrypted connection only. The service URL must start with https (http allowed only for an address on the same server), and the DPD certificate is verified.
• Resistant to unusual responses. Responses with a DTD definition or larger than 2 MB are rejected.
• Cron token. On installation, a random 32-character token; after updating from version 1.x – the previous key; the “Generate new token” button assigns a new random token and immediately invalidates old URLs, including the old cron.php URL. In a shop with SSL, an http call gets a clear error instead of a redirect.
• Employee permissions. Saving settings and running checks require the module “configure” permission and edit rights on the modules page. An employee without these rights will not see the settings, DPD login, or cron URLs (PrestaShop 9 shows only the module header with information about missing permissions). Each form has its own module CSRF token, and actions are performed only after submitting the form.

Multistore

• One DPD account for all shops. Settings are shared, and checking covers orders from every shop. The form displays this information.
• Access for employees of all shops. Since settings and runs cover all shops, the module can be managed by a super administrator or an employee assigned to all shops.

Compatibility, installation, and update

• PrestaShop 1.7.0–9.x, PHP 7.0–8.5. Automated tests cover PrestaShop 1.7.2.4, 1.7.5.2, 1.7.6.7, 1.7.7.2, 1.7.8.5, 1.7.8.10, 8.0.0, 8.1.7, 8.2.6, 9.0.2, and 9.1.5 on PHP 7.0–8.1: checking logic on orders created in the shop (with a DPD service mock), the browser panel (Playwright, Chromium), and the cron URL. The syntax of all files is checked on PHP 7.0–8.5.
• Update from version 1.0.x. It migrates settings (including those saved in a single-shop context), converts saved carrier ID numbers to references, keeps the old cron key as the token, and removes files from the old version. Updating from 1.0.5 is verified by tests on PrestaShop 1.7.2.4, 1.7.8.10, 8.2.6, and 9.0.2.
• Version 1.0.x on PrestaShop 9. The old version does not load on PrestaShop 9 (the old cron.php file is blocked by .htaccess, and the old admin page uses deprecated code). The new version keeps the same functionality and settings, and old cron URLs on PrestaShop 1.7 and 8 continue to work unchanged.
• Languages. The module interface is available in Polish and English.

Important operating limits

• The module does not create shipments, labels, or shipment numbers – the number must be saved in the order manually or by another module.
• It supports only DPD Polska shipments checked through DPDInfoServices; a login and password for this service from DPD are required.
• Each shipment number is a separate request to DPD; a large number of orders is processed in subsequent cron runs.
• In the event of a return or loss, the module does not change the order status – it records the event in the history.
• The module does not send its own emails: the customer receives the message assigned to the status in PrestaShop if email sending is enabled for that status. If the email cannot be sent, the status still changes, and the history records a warning.
• The DPD test environment does not return shipment events, so status changes can only be checked on a production DPD account.
• The module works in the admin panel and via cron – it does not add any customer-visible elements to the shop.