WooCommerce Address Autocomplete: 7 Providers Compared

Compare account requirements, billing, and checkout behavior

Start with the services your WooCommerce plugin supports. These providers are not interchangeable simply because each offers address search: the plugin must support the correct API, map its response, and preserve manual entry.

Plugin licensing and provider usage are separate cost checks. The table identifies what to verify, rather than comparing free allowances that may use different billing units. Official documentation is linked in each provider section below.

What matters in a WooCommerce checkout provider

A checkout autocomplete provider must do more than display a nice suggestion list. The selected result has to become valid WooCommerce order data. Street, city, postcode, country, state, county, province, and apartment details can all behave differently depending on the provider and country.

The most important test is not whether the provider can find famous addresses. It is whether it returns clean structured data for the addresses your customers actually enter.

• Test the countries and regions where the store actually ships.
• Check whether returned state or province values match WooCommerce's expected codes.
• Confirm how apartment, suite, unit, floor, and building details are handled.
• Review request limits, billing model, and key restrictions before production use.
• Keep manual address entry available when autocomplete cannot help.

Google Places: match billing to the API mode

Google Places requires an enabled billing account and credentials. Check whether the integration uses Places API (New) or Legacy, rather than assuming one set of setup instructions applies to both.

For the New API, autocomplete session pricing depends on how the session ends and which Place Details fields are requested. A plugin should manage tokens and request only the data it needs; do not budget on the assumption that every suggestion is free.

Loqate: support the full Find and Retrieve flow

Loqate Address Capture uses Find to search and Retrieve to obtain the final address. A suggestion can represent a container, such as a street or building, rather than a complete address. The integration must let the customer narrow that result before filling checkout.

Test the mapping of address lines, company, unit, locality, and postcode. Confirm the commercial terms for the Capture service you enable, rather than treating the number of suggestions as the number of paid address captures.

Mapbox: identify the search product before estimating cost

Mapbox offers several search products. Confirm whether a plugin uses Geocoding, Search Box, or Address Autofill before applying a pricing estimate or another product’s documentation.

With Geocoding autocomplete, input changes can create separate API requests. Minimum input length and a short delay between searches help limit unnecessary traffic. Geocoding also distinguishes temporary and permanent use: check the applicable storage permission before retaining returned data in WooCommerce orders.

HERE: distinguish address completion from coordinate lookup

HERE’s Autocomplete endpoint can return structured address information. It is different from broader Autosuggest search. An additional lookup or geocode step may be useful for coordinates, but should not be described as mandatory for every address-field workflow.

Results can be less specific than a complete house address. Test whether the checkout preserves a customer’s house number and lets them complete missing details. Count the endpoints your integration actually calls when reviewing the HERE plan.

TomTom: address typeahead is not just query completion

TomTom Fuzzy Search supports predictive partial input through its typeahead option and can return address components. Its separately named Autocomplete endpoint should not be assumed to provide the same completed address workflow.

Check the integration’s endpoint, country filters, and selected-result mapping. A search result label alone is not enough to populate street, postcode, country, and WooCommerce state fields correctly.

LocationIQ: budget for autocomplete requests

LocationIQ has a dedicated Autocomplete API with an access token and country filtering. Its documentation explicitly distinguishes this endpoint from Search / Forward Geocoding; an integration needs to handle the correct response format.

LocationIQ includes autocomplete calls in its request-credit model. Estimate calls from typing and repeated searches, then check both the plan allowance and rate limits. Inspect structured address components as well as the suggestion’s display text.

Geoapify: check credits and returned region fields

Geoapify Address Autocomplete uses a project API key and supports filters and location bias. Its structured results can include street, house number, postcode, country, and region information, but a state code is not available for every country and language.

Test how the integration handles missing region codes when WooCommerce expects a specific state value. Review credits, rate limits, and attribution requirements for the selected plan before treating a free allowance as sufficient for production.

Estimate API cost from searches, not completed orders

Consider a hypothetical month with 1,000 customers using autocomplete. If each generates four suggestion requests, that is 4,000 search requests. If 800 then select an address and the API requires one detail retrieval per selection, add 800 detail requests.

That is 4,800 network requests in this example, not necessarily 4,800 billable units. Session billing, included quotas, retrieval charging, and credit rules differ. Some APIs return usable address fields without an extra detail call; container drill-down or repeated selections can add calls.

Abandoned checkouts can still consume requests. Measure autocomplete usage rather than multiplying paid orders by one lookup. Add the plugin license separately, then estimate provider cost using the matching API’s current tariff and any storage requirements.

1. Count autocomplete users, suggestion requests, and final detail requests separately.
2. Check billing and shipping searches, retries, and address changes.
3. Apply the provider’s actual session, request, or credit rules and allowance.
4. Set usage alerts or limits where available, and verify manual checkout still works when requests fail.

How to compare providers without guessing

The safest comparison method is to build a short test set from real business requirements. Include addresses from the main countries, addresses that previously caused support issues, apartments or units, rural addresses, and postcodes with local formatting quirks.

Run the same test set through each candidate provider. Compare not only whether the result appears, but also what fields are returned and what WooCommerce would store on the order.

• Can the provider find the address from partial typing?
• Does the selected result include the required address components?
• Does the state, county, or province match WooCommerce's expected value?
• Can the customer still edit every populated field?
• What happens if the provider times out, returns no result, or returns an incomplete result?
• What request volume would a normal checkout session create?

Implementation mistakes that matter more than provider choice

A strong provider can still produce a poor checkout if the integration is careless. The biggest risks are exposed API keys, too many requests per keystroke, incorrect state mapping, blocked checkout when the provider is down, and hidden fields that customers cannot correct.

The autocomplete experience should assist checkout, not control it. Customers must be able to type manually, review the populated fields, and place the order even if the external service is unavailable.

• Do not expose unrestricted provider credentials in frontend code.
• Debounce search requests and avoid unnecessary calls while customers type.
• Never make provider success required for order placement.
• Keep billing and shipping fields visible and editable.
• Test classic checkout and block checkout separately when both are supported.

How QuixWP Address Autocomplete approaches provider choice

QuixWP Address Autocomplete is being prepared for WooCommerce Marketplace release. The plugin is designed around provider choice rather than forcing every merchant into one address service.

On WooCommerce versions that expose the native address-autocomplete provider framework, QuixWP registers the selected provider with Core and lets WooCommerce render the autocomplete interface for classic and block checkout. That keeps provider selection separate from the checkout UI instead of replacing WooCommerce checkout with a custom autocomplete layer.

QuixWP then adds the provider integrations, normalization, server-side API-key handling, country restrictions, request controls, and compatibility behavior needed around that Core framework. WooPayments is not required because the merchant connects the selected provider with its own API credentials.

The plugin supports eight provider modes across seven services: Google Places New, Google Places Legacy, Mapbox, HERE, TomTom, Loqate, LocationIQ, and Geoapify. The two Google modes are not two independent providers. Provider accounts and usage charges are separate from the plugin.

Until the marketplace listing is live, this article should be treated as a provider-selection guide rather than a purchase announcement. Once the extension is published, the practical next step will be to test the demo, review the documentation, and choose the provider that best fits the store's actual checkout addresses.