Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phone number format issues with Klarna #972

Open
mariuszsienkiewicz opened this issue Sep 17, 2024 · 7 comments
Open

Phone number format issues with Klarna #972

mariuszsienkiewicz opened this issue Sep 17, 2024 · 7 comments

Comments

@mariuszsienkiewicz
Copy link

mariuszsienkiewicz commented Sep 17, 2024

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.

  • The number 0689124321 from the billing address is transformed (by PhoneNumberProvider::getFromAddress) to +689124321, which is, of course, not valid.
  • The number +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.

@mariuszsienkiewicz
Copy link
Author

mariuszsienkiewicz commented Sep 17, 2024

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
Copy link
Collaborator

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
Copy link
Author

mariuszsienkiewicz commented Sep 18, 2024

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
Copy link
Collaborator

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.

  • N/A issue should be fixed in the 6.2.3 release
  • 0689124321 format is incorrect as in documentation format must be like in E.164 format. [+] [country code] [subscriber number including area code].
  • 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

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 [email protected]

Thanks!

Best Regards,
Invertus Support team.

@mariuszsienkiewicz
Copy link
Author

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
Copy link
Collaborator

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.

@justelis22 justelis22 reopened this Nov 18, 2024
@justelis22
Copy link
Collaborator

Hello there @mariuszsienkiewicz,

We have created a beta release with the improvement to handle Klarna's phone number.

If possible, please try to install the beta version as the feedback would be helpful to us.
You can find the new version here - https://github.com/mollie/PrestaShop/releases/tag/v6.2.5-beta

If you have any questions, please let me know!

Best Regards,
Invertus Support team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants