This document describes methods for combining Place Autocomplete, Address Validation API1, and Maps in an ecommerce checkout for the purpose of capturing high quality addresses.
PrerequisitesGoogle recommends familiarity with the following:
The Address Validation API is a service that accepts an address. It identifies address components and validates them. It also standardizes the address for mailing and finds the best known latitude/longitude coordinates for it. Optionally, for addresses in the United States and Puerto Rico, you can enable the
Coding Accuracy Support System (CASS™).
Why do you need address validation at checkout?Collect accurate addresses during the ordering process:
This is an important step to promoting successful deliveries, increases on-time fulfillment, and reduces costly address correction charges.
Guide customers to enter the address quickly and accurately:
Place Autocomplete speeds up address entry and reduces input errors, allowing customers to move easily through the checkout. Address Validation gives feedback on the overall address quality, makes corrections such as standardization and spelling mistakes, and enhances metadata, such as providing a residential or commercial indicator (available in select regions.
This section outlines the recommended address entry workflow for ecommerce checkouts. The process is comprised of three steps:
Next, we'll delve into each step individually.
Step 1: Address entry flow - using the Place Autocomplete serviceImplement Place Autocomplete using the JavaScript API on the first line of the address entry form.
Place Autocomplete provides suggestions to the customer as they enter their address details. When implemented using the JavaScript API, as users start typing, a drop-down appears under the address entry form field, showing results from the Autocomplete service that update with every keystroke. Once the user has entered enough information to find the address, they select it from the drop-down. This action automatically populates the form fields with the address data.
You can provide two form entry styles to the user with Place Autocomplete: either a display with all address fields, or a display with a single input field. This single input field prompts the user to begin searching as they type, rather than entering in address components individually. Once autocomplete populates the address, the workflow expands the form fields with the address data, allowing the customer to review and make edits, for example adding an apartment or unit number.
Here is an example of how this flow might appear, using a single input field:
Tip: If you are using Autocomplete (New), use Session Tokens on your Autocomplete and Address Validation API calls to take advantage of Autocomplete for checkout and delivery pricing. Step 2: Use the Address Validation API to validate addressesAfter the user enters the address, Google recommends you call the Address Validation API at checkout to confirm that the address is valid and complete. Trigger a call to the Address Validation API upon the user clicking the Next or Continue button on the address form. This button often leads to the payment page.
Google recommends calling Address Validation API for every transaction.
The following flow diagram illustrates an example end-to-end integration of the Address Validation API within a checkout:
This document discusses address acceptance scenarios later.
Step 3: Provide visual confirmationAfter address entry, provide the user visual confirmation of the delivery location by displaying it on a map. This offers the customer additional assurance that the address is correct, and it reduces delivery or pickup failures.
The map can be shown during the checkout process, or sent within the transaction confirmation email. Both of these use cases can be accomplished with the following APIs.
Note: Use the geocode returned by the Address Validation API to show the location of an entered address. Deep Dive - address acceptance scenariosAddress Validation API responses can be categorized into three main scenarios:
This concept is covered in the Build your validation logic section of the Address Validation API docs, and we will discuss each scenario in this section.
Tip: The logic is also available as an open source web component, in the Extended Component Library. FixThis section shows how to fix an address input. For information about specific signals that the Address Validation API returns to indicate a low quality address, see Fix an address in the Build your validation logic documentation.
If the response from the Address Validation API indicates an invalid address, redirect the customer to the address entry form to check their entered data. Once the address has been fixed, your service should resend to the Address Validation API to ensure the corrections made are valid.
You can also highlight specific address line errors by using the signals returned at the addressComponents
level. An example of this can be seen in the screenshot to the right.
This section shows how to confirm an address. For information about specific signals that the Address Validation API returns to indicate an address should be confirmed, see Confirm an address in the Build your validation logic documentation.
Often your system will want to prompt a user to confirm an address. For example, a customer misspells the city name, which would then be corrected by the Address Validation API. You should confirm this fix with the customer. This is because the changes made by the API might fundamentally alter what was originally entered.
Use an interstitial modal to display the information to the customer, enabling three options to proceed:
An example of this can be seen in the screenshot to the right.
AcceptThis section shows how to accept an address. For information about specific signals that the Address Validation API returns to indicate an address is good quality and should be accepted, see Accept an address in the Build your validation logic documentation.
In this scenario, the checkout process should move onto the next stage, likely payment capture, with no prompts to the customer in regards to address quality. The API has confirmed that the address entered by the customer is good quality, and deliverable.
We recommend using the returned address data from the Address Validation API against the order, because this could contain minor corrections and additions, such as the following:
When building your address acceptance logic, be sure your implementation doesn't block customers from checking out due to entering an invalid address. Construct logic in a way that prevents the possibility of an infinite loop if the API repeatedly indicates their entry is invalid.
Google recommends that you provide customers up to two chances to enter their address, and on the second attempt, accept their entry, even if it does not validate. On the second attempt, the goal is to let them proceed regardless of validation.
Two suggested methods to accept the second attempt:
If possible, design your system to flag addresses that don't validate, so that a customer service representative can review them before the order ships. This extra measure ensures you catch any mistakes.
New building construction offers a good illustration of why this check is recommended. There may be a gap between when new building construction is finished and when that building's address is populated in the postal address databases. Customers should have the option to force-proceed through the checkout page with their typed address, even if it does not validate.
Once a checkout session has been completed, optionally use the provideValidationFeedback
method to send Google feedback about a specific address validation attempt.
This document has given an overview of a checkout flow implementing Autocomplete, Address Validation, and visual confirmation on a Google Map. Use this document as a starting point to design your implementation, following the recommended address entry flows.
Next StepsDownload the Improve checkout, delivery, and operations with reliable addresses Whitepaper and view the Improving checkout, delivery, and operations with Address Validation Webinar.
Suggested further reading:
Henrik Valve | Solutions Engineer
Thomas Anglaret | Solutions Engineer
Sarthak Ganguly | Solutions Engineer
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4