Open mariuszsienkiewicz opened 2 months ago
Sorry, it's not just an issue with the number format; it goes much deeper. This is going to be a long comment, so please pay attention.
The method createMollieOrder
has a logic issue: if an exception occurs in the first try
block:
try {
$apiPayment = $this->createPayment($data, $paymentMethodObj->method);
} catch (Exception $e) {
...
}
then this error may be omitted in some cases. The entire code looks like this:
try {
$apiPayment = $this->createPayment($data, $paymentMethodObj->method);
} catch (Exception $e) {
if ($data instanceof OrderData) {
$data->setDeliveryPhoneNumber(null);
$data->setBillingPhoneNumber(null);
}
try {
$apiPayment = $this->createPayment($data, $paymentMethodObj->method);
} catch (OrderCreationException $e) {
$errorHandler = ErrorHandler::getInstance();
$errorHandler->handle($e, HttpStatusCode::HTTP_BAD_REQUEST, true);
} catch (Exception $e) {
$errorHandler = ErrorHandler::getInstance();
$errorHandler->handle($e, HttpStatusCode::HTTP_INTERNAL_SERVER_ERROR, true);
}
}
For example, if you use the Klarna Pay Now method, this part of code:
if ($data instanceof OrderData) {
$data->setDeliveryPhoneNumber(null);
$data->setBillingPhoneNumber(null);
}
This will remove the delivery and billing phone numbers, and Mollie\DTO\OrderData
will change those null values to N/A
. Klarna will then respond with the error: Error executing API call (422: Unprocessable Entity): The 'phone' field should contain a valid phone number, in E.164 format
. The serialized order data contains "phone":"N\/A"
, which is, of course, incorrect. The way this code works hides the root cause of the issue with the first createPayment execution.
In my example, this logic hid the error: Error executing API call (422: Unprocessable Entity): The amount of the order does not match the total amount from the order lines. Expected order amount to be €72.14 but got €70.68
. That’s why I initially thought there was an issue with the phone number and didn't know the real reason.
Maybe this should be a separate issue, but I'll leave it here for now while I continue debugging.
Hi there @mariuszsienkiewicz, thank you for the detailed comment.
We will check this issue and I will get back to you as soon as more details.
Thank you for your patience!
-- Best Regards, Invertus Support team.
Hey @justelis22!
One more thing – just to help you out with testing - try entering just one letter (e.g., S
) in the lastname field of the billing address and use this phone number: 0689124321
. In Klarna's production environment, this will trigger an error indicating that the lastname is not valid (it will be omitted). However, another error will occur during the next createPayment
execution, where the numbers are removed, and the real cause of the error is overridden by 'N/A' (by the way, why 'N/A'? Does some other payment gateway require this?). This will lead to the following error: Error executing API call (422: Unprocessable Entity): The 'phone' field should contain a valid phone number in E.164 format.
I really appreciate your effort.
Hi there @mariuszsienkiewicz, thanks for waiting!
We came back to this request, here are a few comments: It seems you have three issues here, two of them related to the phone number.
As for the last issue, we have checked this issue and tried to recreate it locally on our environments, however, everything seems to be working fine, but we were not able to prompt this issue.
That being said, we will need access to your shop to debug the issue. Can you provide the Back Office and FTP credentials? If you have a development environment, that would be even better. That way, we can work on the issue without disturbing the live store.
Also steps to recreate the issue would be also very useful.
You can add the credentials here - https://privatebin.net/ and share the link with us via email support@invertus.eu
Thanks!
Best Regards, Invertus Support team.
Hey,
I see that you closed this issue – that's fine. Thank you for the detailed response. I’d like to address a few points on your list:
"N/A issue should be fixed in the 6.2.3 release" – great, thank you!
"0689124321 format is incorrect as in documentation format must be like in E.164 format. [+] [country code] [subscriber number including area code]." – this number is still valid in the Netherlands. Please see this wiki for more information. This format is ubiquitous among Dutch people. Do you think it’s better to require customers to follow the E.164 format? I’m not sure if people would particularly like this change.
"Error executing API call (422: Unprocessable Entity): The amount of the order does not match the total amount from the order lines. Expected order amount to be €72.14 but got €70.68" – I’ll come back to this issue later. I’ll create an easy guide for you on how to replicate it.
Thanks! 🙂
Hi there @mariuszsienkiewicz,
We have discussed this internally, and we will approach the phone format issue from a different aspect.
We can't change how Klarna accepts the phone number. However, we can add steps to ensure the phone is sent to Klarna correctly.
Our team is currently refining this, but you can expect changes in the 6.2.5 Mollie version.
If you have any questions, please let me know! I will keep this open for now.
Best Regards, Invertus Support team.
The issue is with Dutch phone numbers.
In the Netherlands, as far as I know, the numbers
0689124321
and+31689124321
are the same and valid.Unfortunately, both are not transferred correctly to Klarna (I have tested it by using the Pay Now payment method) by the Mollie module, resulting in this error message being shown in the cart: It looks like you have entered an incorrect phone number format in the billing address step. Please change the number and try again.
0689124321
from the billing address is transformed (by PhoneNumberProvider::getFromAddress) to+689124321
, which is, of course, not valid.+31689124321
is left the same and Klarna still doesn't allow it.We are using the current version of the module and PrestaShop 8.1.7.