Available pickup time error

[Laimonas-Mituzas]

Module versios 3.3.1
What is the cause of error?

Request Response

[SimasKorolis]

Hi,

Thanks for flagging this — we've been able to reproduce it and confirm what's happening.

What's going on: when creating a courier pickup request, the "Desired pick-up time" field is automatically pre-filled with the current time plus 30 minutes. DPD's system, however, only accepts pickup requests at specific fixed time slots — it doesn't accept an arbitrary time. Because the pre-filled value almost never lines up exactly with one of those fixed slots, DPD rejects the request with an error like:

Available pickup times: 08:00, 09:00, 10:00, 11:00, 12:00, 12:30, 13:00, 13:30, 14:00, 14:30, 15:00 (pickup window ending at 15:00, 16:00, 17:00, or 18:00)

Workaround in the meantime: when creating a courier request, please manually adjust the "Desired pick-up time" and "Last pick-up time" fields to one of the values DPD lists above, rather than leaving the auto-filled default in place. That will let the request go through normally.

A ticket has been created addressing this issue and our team is looking into it.

Sorry for the inconvenience in the meantime, and thanks again for the report.

[Laimonas-Mituzas]

Thank you.
Picking the right times did not gave same type error, but had a new one :)
Label was created https://prnt.sc/KTsV3FHi1ggI
Carrier request log does not show relative entry https://prnt.sc/5T0hX7wE7_3P
New error in log https://prnt.sc/O13-4waSB9wV
What can be wrong in this case?

But it looks like that request form is not working well. Order number is not in console. Look at the

attachment.

[SimasKorolis]

Hello,

To fully understand what's happening here, it would be best if You could export the full logs and send them over to us.

Alternatively, you could give us the credentials to Your Prestashop Backoffice, so that we could take a look at the whole picture. Credentials we would need:

• Backoffice URL;
• Login email;
• Backoffice password;

Once we have this information, we can better understand and help you with this issue.

--
Best Regards,
Invertus Support Team

[Laimonas-Mituzas]

Can you provide any email to sent it?

[SimasKorolis]

simas.korolis@invertus.eu

[SimasKorolis]

Hello,

Thank you for your patience.

The credentials you provided were very helpful in gathering the information needed to look into this issue. At this point, however, we have not yet identified the root cause or a workaround. We have created a ticket and forwarded it to our development team, who are now looking into it.

We will get back to you as soon as possible with an update.

--
Best Regards,
Invertus Support Team

[PauliusSamu]

Same issue here — confirming on a production shop (module v3.3.1, PrestaShop 8.2.7, PHP 8.1).

Courier pickup (pickupOrderSave) has stopped working completely. Every request fails with the same error.

What the module sends (Request):

endpoint: https://integracijos.dpd.lt/ws-mapper-rest/pickupOrderSave_
pickupTime: "2026-08-26 14:48:07" // single exact timestamp

What the DPD API returns (Response):

json
{
"level": "error",
"body": {
"message": "Available "pickupTimeFrom" values: [08:00, 09:00, 10:00, 11:00, 12:00, 12:30, 13:00, 13:30, 14:00, 14:30, 15:00]. Available "pickupTimeTo" values: [15:00, 16:00, 17:00, 18:00]."
}
}

Root cause: the DPD API has changed its pickup-time validation. It no longer accepts a single exact pickupTime — it now requires two separate values, pickupTimeFrom and pickupTimeTo, each chosen from a fixed list of allowed times. The module (even v3.3.1) still sends the old single-timestamp format, so the API rejects every request.

Secondary bug: when the API returns this JSON error object, the module tries to run strpos() on it and crashes, because the response is now a stdClass, not a string:

strpos(): Argument #1 ($haystack) must be of type string, stdClass given [TypeError]

So instead of showing the DPD validation message, the whole page throws a fatal error.

This affects order fulfillment — the courier cannot be called from PrestaShop at all. As a temporary workaround we are creating shipments and pickups manually through the myDPD portal.

Requested fix:

Send pickupTimeFrom / pickupTimeTo from the allowed list instead of a single pickupTime.
Handle the JSON (stdClass) API response properly so the module doesn't crash on strpos().

This has been open since Aug 19 with no response — could someone from DPD please confirm it's being worked on? It's currently breaking pickups on live stores. Thanks.

[SimasKorolis]

Hello,

Thank you for a thorough report.

Before we proceed, could you confirm whether manually selecting a pickup time from the available "pickupTimeFrom" and "pickupTimeTo" values works correctly, or do you also get errors after doing that?

In the meantime, please be assured that we have created a high-priority ticket and forwarded it to our development team to look into this.

--
Best Regards,
Invertus Support Team

[PauliusSamu]

Hello, and thank you for the quick response and for escalating this.

To answer your question: yes, I still get the error even after selecting a valid pickup time. I tested a next-day pickup from 08:00 to 17:00 (whole hours, from the allowed list) and the module still crashes. So the problem is not just an invalid time value on my side.

The root cause appears to be that the module still sends a single pickupTime field, while the DPD API now expects two separate fields, pickupTimeFrom and pickupTimeTo, from the fixed lists:

pickupTimeFrom: [08:00, 09:00, 10:00, 11:00, 12:00, 12:30, 13:00, 13:30, 14:00, 14:30, 15:00]
pickupTimeTo: [15:00, 16:00, 17:00, 18:00]

Because the module sends the old single-field format, the API returns an error regardless of which time I choose.

Then, when handling that error response, the module crashes. From the PrestaShop log:

TypeError: strpos(): Argument #1 ($haystack) must be of type string, stdClass given
at modules/dpdbaltics/src/Service/API/CourierRequestService.php:109

Looking at CourierRequestService.php, the whole response handling seems to assume a plain string response, while the API now returns a JSON object (stdClass):

getCourierRequestError() (lines 105–113):

php
private function getCourierRequestError($courierRequestResponse)
{
$errorPosition = strpos(
$courierRequestResponse,
Config::API_COURIER_REQUEST_ERROR_STATUS
);
return substr($courierRequestResponse, $errorPosition);
}

strpos() receives a stdClass instead of a string, which throws the TypeError.

Also, checkIfCourierRequestIsSuccess() (lines 96–103):

php
private function checkIfCourierRequestIsSuccess($courierRequestResponse)
{
if ($courierRequestResponse === Config::API_COURIER_REQUEST_SUCCESS_STATUS) {
return true;
}
return false;
}

Since the response is now an object, the strict comparison === Config::API_COURIER_REQUEST_SUCCESS_STATUS is never true, so it always falls into the error branch, which then crashes in getCourierRequestError().

So there seem to be two things to fix:

Request side: send pickupTimeFrom / pickupTimeTo from the allowed lists instead of a single pickupTime.
Response side: handle the JSON (stdClass) response in both checkIfCourierRequestIsSuccess() and getCourierRequestError() (e.g. read ->body->message) instead of treating it as a string.

Environment: module v3.3.1, PrestaShop 8.2.7, PHP 8.1.

As a temporary workaround I'm creating shipments and calling the courier manually via the myDPD portal. I'd appreciate an update once a fix is available. Thanks again for the fast response.

[SimasKorolis]

Hello,

Thank you for the detailed explanation.

I have added this information to the ticket for our development team. I will let you know once an update, or at least a patched version, becomes available.

--
Best Regards,
Invertus Support Team

[SimasKorolis]

Hello,

Thanks for your patience.

We have a fix ready, and the module zip is attached below.

dpdbaltics.zip

It's important to note that this is a patch version, not a full release, and it hasn't been tested to the same extent as a full release. Because of this, please test it on your staging/testing environment first, if you have one, before deploying it to production.

We'll be waiting for your feedback on whether this resolves the issue. Please don't hesitate to write back either way, whether the fix worked or not.

--
Best Regards,
Invertus Support Team

[PauliusSamu]

Hello,

The patch works — thank you! After installing the provided dpdbaltics.zip, the module no longer crashes, and the courier pickup request now goes through successfully. I can confirm it on the DPD side: a new pickup appeared in eSiunta ("Kurjerio išvietimai" → "Būsimi išvietimai", pickup date 2026-09-03).

One minor note: the crash (strpos / stdClass) is gone and the request reaches DPD correctly. The only small thing is that the new pickup didn't visually appear in the module's own courier request list in PrestaShop back office, even though it was created successfully on the DPD side — possibly a display/caching thing on our end. Not blocking, but wanted to mention it in case it's relevant.

Environment: module patch on PrestaShop 8.2.7, PHP 8.1.

Thanks again for the quick turnaround — looking forward to this being included in a full release.

[Laimonas-Mituzas]

I confirm that fix helped, but BO do not show carrier requests.
PS 1.7.8.11