How Google’s Geocoding solves Address Validation

For the e-commerce business, it is very important to have a valid and correct address base. Sending packages to incorrect addresses causes significant losses, since packages are not delivered and sent back. In the case of the Kickz online shop, we faced exactly this problem. Thus, we thought about how to improve and force users to enter correct addresses. Learn how we used Google’s Geocoding service to solve this problem.

There are many commercial providers for addresses, however not all of them provide a world-wide address base and the Kickz shop is delivering world-wide. It turned out that the best value for money would be to use Google’s Geocoding web service. Geocoding is the process of converting addresses into geographic coordinates, i.e. latitude and longitude.

However, as the response from Google includes not only the longitude/latitude data but also further address suggestions, this service can also be easily used to present refined/suggested addresses to the user. And that was exactly what we needed. So our basic idea of the service usage was to request exact coordinates and refined addresses (suggestions) for a given address. The coordinates were then used to show the location on the map.

The Geocoding web service is part of the Google Maps API and is offered both as free and as commercial. The basic service is free for 2500 requests per day and does not support HTTPS requests. As Kickz requires HTTPS and more requests per day, we decided to go for the commercial service, which allows of up to 100,000 requests per day and provides HTTPS access with signed web service requests.

Using the Geolocation Web Service

Google’s Geocoding web service is quite simple to use. All you need to do is send a simple HTTP request to the specified address and you will receive a response in either XML or JSON format. The response contains zero, one or even several addresses, depending on the precision of the input. It can be empty if Google cannot locate your address — but based on our experience, this rarely happens.

A JSON response is the obvious choice for JavaScript-based validation on the client-side using (AJAX). XML is more suitable for classic server-side validation. For the Kickz project, we chose the XML format. We validate using the Google web service all over the application, where the user enters a address, i.e. during customer registration and checkout. In these scenarios, the request from the browser is first sent to our server-side application, which calls the Google web service with a certificate-signed request. The request for the input “Frankfurstein ring 105a,München, de, 80000″ looks this:

[code light=”true” wraplines=”true”],M%C3%BCnchen,de, 80000,&sensor=false&client=gme-kickzag&signature=VF930KLrbu98sKKLqIjn4adIoTs=

Google returns the following XML document as a response:

<formatted_address>Frankfurter Ring 105, 80807 Munich, Germany</formatted_address>
<long_name>Frankfurter Ring</long_name>
<short_name>Frankfurter Ring</short_name>

The XML response is deserialized to Java objects using JAXB 2. After the response is processed, the user is given some options to refine the original address entered in the browser.

It’s convenient that all responses from the Google web service are localized. In the screenshots below, you see the same validation done in the German shop (left) and in the international shop (right). The only difference is the language parameter sent with the web service request and set in the HTTP request header “Accept-Language”. To visually improve validation, we also use static Google maps URL to display the address to the user graphically.

The Geolocation web service is localized: Address data returned for the german shop (left) and for the international shop (right). Click to enlarge.


Google’s Geocoding web service turned out to be an effective tool for the validation of the user addresses in our Kickz online shop. Furthermore, this service can be used free of charge for small projects or sites with lower traffic. In Kickz though, we are using the commercial version of the web service, since the traffic is higher and we need the HTTPS service URL.