Sin impuesto Con impuesto

Correct addresses and phone numbers at checkout: fewer delivery problems

Some delivery problems start in the address form: a misspelt city, a postcode from another province or a phone number nobody can call. We go through the usual mistakes and what to validate without putting obstacles in the customer's way.

Equipo Rekire
Updated: 14/10/2026 52
Correct addresses and phone numbers at checkout: fewer delivery problems
Share:

The carrier sends a parcel back to you: “incomplete address”. Another one gets stuck at the depot because the courier called a phone number that does not exist. A third takes two extra days because the postcode belonged to the neighbouring province. None of these problems comes from the transport. They started at your checkout, when the customer typed their address by hand and nobody checked anything.

The most frequent mistakes

  • Misspelt city: missing accents, typos, written in another co-official language or with the name of a hamlet instead of the municipality.
  • Postcode that does not match the city or the selected province.
  • Wrong province, especially in municipalities close to a provincial boundary.
  • Phone number without a prefix from a foreign customer, or with a digit missing.
  • Phone number with a duplicated prefix or with spaces, hyphens and brackets that the carrier's system does not understand.
  • Data in the wrong field: the floor and door number in the city, the company name in the address.

Each one seems minor, but you pay for it: re-shipments, calls to the customer, parcels returned with their return postage and customers who do not come back.

Why PrestaShop lets these mistakes through

PrestaShop's address form validates formats: that the postcode has the country's format (five digits in Spain), that the phone number only contains allowed characters. It does not check that the city exists, that the postcode belongs to that city or that the phone number is valid for its country. “28001” with the city “Sevilla” goes through without a problem.

City, province and postcode: let them come from a list

The most effective way to avoid typing errors is not to ask people to type. If the customer chooses the province and then the city from a drop-down with search, the city always exists, is spelt correctly and is consistent with the province. If the postcode is also filled in when the city is chosen, a large part of the mismatches disappears.

Two important nuances:

  1. Large cities have many postcodes. Filling one in must not stop the customer from correcting it with the one for their street.
  2. You have to decide how strict you are. In strict mode only cities from the list are accepted; in flexible mode, customers can type their own if they cannot find it. If your list is complete, strict mode prevents mistakes; if you sell to countries where your list is partial, flexible is better.
Don't put up obstacles where none are needed. Every required field and every blocking validation is an opportunity for abandonment. Address validation should guide (suggest, complete, warn) before it rejects.

Phone number: with its prefix and in a format machines understand

The phone number is used for more and more things besides the courier calling: delivery notifications by SMS, WhatsApp messages, carrier verification. All these systems expect the number in international format, E.164: the plus sign, the country code and the number, without spaces (for example, +34 followed by the nine digits).

What you should do:

  • Detect the prefix the customer types. A French number with +33 is still French even if the address is Spanish.
  • Apply the prefix of the address's country if the customer does not enter one.
  • Validate length and format according to the country.
  • Store the normalised number on the server, not just display it nicely on screen: if the customer has JavaScript disabled, the data must arrive just as clean.
  • Choose between warning and blocking. A clearly invalid number can block the address from being submitted; a valid number from another country should only trigger a warning.

The back office also writes addresses

Many mistakes are not entered by the customer: they are entered by the team when creating a phone order or correcting an address. If validation is only in the checkout, the back office becomes the entry point for dirty data. The same city selector and the same phone validator have to be in the back office address form.

Compatibility with your checkout

Any change to the address form touches the most delicate part of the store. Before installing anything, check:

  • That it works with your theme (Classic, Hummingbird or a custom one) and with your checkout, whether multi-step or one-page.
  • That it does not use overrides that clash with other checkout modules.
  • That it works on your version of PrestaShop and PHP. If your store is on an unsupported version, the checkout is precisely where accumulated patches show the most; planning the upgrade usually saves more problems than any validation.

Privacy

Validating a phone number does not require storing more data than you already ask for. If you keep validation statistics, store the number masked, not in full, and define how long you keep those records.

Checklist

  • Review your latest delivery problems and classify them: how many came from the address or the phone number?
  • Make the city come from a list consistent with the province.
  • Fill in the postcode when the city is chosen, letting the customer correct it.
  • Store phone numbers in international format.
  • Apply the same validation in the back office.
  • Test the whole checkout on mobile with a foreign address.

Frequently asked questions

What about the addresses I already have stored? Validation applies when an address is created or edited. Old ones stay as they were: if a returning customer buys again, it is a good moment to ask them to check theirs.

Is asking for the phone number mandatory? It depends on your carriers: many require it to notify the delivery. If you ask for it, explain what you use it for and do not use it for anything else without consent.

How to solve it in PrestaShop

RKR Select City makes the customer choose the city from a list with search, with the postcode and province filled in automatically; it includes 8,024 municipalities in Spain and starter packs for Portugal, France, Italy, Germany and the United Kingdom, with strict or flexible mode. The phone number is validated with its international prefix for 178 countries, stored in E.164 on the server, and you can choose soft or strict mode. It hooks into PrestaShop's address form without overrides, works with the Classic theme, with Hummingbird and with one-page checkouts, and is also available in the back office address form. In the statistics the phone number is stored masked.

Loading...
Cookie consent
Back to top