openprovider / Openprovider-WHMCS-domains

Openprovider WHMCS Domain Module
43 stars 31 forks source link

[BUG] error Invalid zipcode! #228

Closed Raboo closed 3 months ago

Raboo commented 2 years ago

Describe the bug When transferring a domain with a Swedish zip code formatted like '17266' instead of '172 66'. The transfer will fail due to Invalid Zipcode!.

I have not tried registering a domain with a zip code that doesn't include a whitespace in the zip code.

To Reproduce Client in whmcs has their zip code without whitespace. Try to transfer domain (using openprovider plugin)

Expected behavior It should work with and without whitespace in the zip code.

Screenshots

An order has received its first payment but the automatic provisioning has failed and requires you to manually check & resolve.

Client ID: 1
Domain ID: 31
Registration Type: Transfer
Domain: domain.se
Error: Invalid zipcode!

Server info:

wmetge commented 2 years ago

Hello @Raboo , thank you for bringing this to our attention. Our support team will investigate whether the issue is from the module or the Openprovider API.

Lippur commented 1 year ago

The zip code validation for various countries is incredibly and unnecessarily strict in Openprovider, also when using the UI. Trivial differences like spaces in the wrong place, dashes vs spaces, etc. all cause errors with no details on which format is actually expected. And it's a much bigger inconvenience when the order is placed through WHMCS, as the admin has to Google the "correct" format for the specific country's zip code, change it on the user's account, and resubmit the domain order. This is completely unfeasible with a large order volume.
There is no reason why the zip code has to be so strictly validated.

sapillai commented 3 months ago

Hi @Raboo,

I wanted to follow up on this issue to check if there have been any updates or if further assistance is needed.

I noticed that your support ticket was auto-closed as we didn't hear back from you. I reviewed API logs for your account from the period and I could only find two .se domain transfer requests. One was failed with error "Empty authorization code!" and the other with "Organization registration number cannot be blank".

If you are still experiencing zip code issues transferring .se domains with latest version of the module, please contact our support team with following details so that we can investigate it:

The zip code validation for various countries is incredibly and unnecessarily strict in Openprovider, also when using the UI.

@Lippur, I completely understand the inconvenience this may cause. However, please note that some registries strictly validate zip codes and may return an error if the zip code is invalid or incorrectly formatted. As a responsible registrar, we must follow registry rules and requirements. For example, zip code should not contain any blank spaces for .al domain extension and for .rio, zip code should be in format "12345-123". We document such requirements in our knowledge base and are in the process of adding info boxes in control panel to help customers.

Lippur commented 3 months ago

@sapillai Glad to hear things are finally starting to move.

I understand your need as a registrar to comply with specific formats for the data you collect, but I really hope you are not suggesting I should tell my customers to read through the knowledge base of OpenProvider before submitting their order for a domain. Until now, and this has been an issue for years, that would have been the only way they could have possibly learned about the "correct" format for their own post code, otherwise the order simply fails mysteriously. All I'm asking is a little bit of common sense when validating, and possibly adjusting, the input on your end. If the customer enters "1234AB" as a Dutch postcode, and the format you expect is "1234 AB", it does not require especially complex and arcane logic or advanced computer science to convert from one format to the other. The customer, or indeed the administrator who is using you as a registrar, should not have to think about where your downstream registries want the spaces and dashes to be, that should be transparently taken care of by your API layer.