mollie / PrestaShop

iDEAL, Creditcard, Bancontact, SOFORT, Bank transfer, PayPal & paysafecard for Prestashop
http://www.mollie.com
BSD 2-Clause "Simplified" License
69 stars 44 forks source link

Phone number format issues with Klarna #972

Open mariuszsienkiewicz opened 2 months ago

mariuszsienkiewicz commented 2 months ago

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.

We are using the current version of the module and PrestaShop 8.1.7.

mariuszsienkiewicz commented 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.

justelis22 commented 2 months ago

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.

mariuszsienkiewicz commented 2 months ago

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.

justelis22 commented 2 weeks ago

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.

mariuszsienkiewicz commented 1 week ago

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:

  1. "N/A issue should be fixed in the 6.2.3 release" – great, thank you!

  2. "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.

  3. "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! 🙂

justelis22 commented 4 days ago

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.