WooCommerce will take payment for an address that only looks complete. A missing house number, a postcode from another country, or a street a carrier cannot find will still pass if the required fields are filled in. The customer leaves. Fulfilment finds the problem when the label fails.
Google Address Validation for WooCommerce closes that gap before the order is placed. Google’s Address Validation API checks the shipping address against postal data. Address Guard Pro then warns the customer, offers a corrected address, or blocks checkout, depending on the result and your rules.
This article explains what Google validates, how Places and Address Validation differ, and how to connect both at checkout with Address Guard Pro. For the broader validation flow, see How to Validate Addresses Before WooCommerce Checkout.
What Google Address Validation does at checkout
Google Address Validation is a Maps Platform API. It is not a WooCommerce field check. Required country, street, city, and postcode only prove the form is not empty. Google proves whether those values hold together as a real address.
At place-order, Address Guard Pro sends street, city, state, postcode, and country to Google. The API returns a verdict: whether the address is complete, how precisely it matched (building, street, or only city), and a standardized version when Google has one.
Typical outcomes:
- Verified. Street, city, postcode, and country match a known location, usually down to the building or unit. Google may still return a cleaned-up format for the label.
- Corrected. The address is close, but Google inferred or replaced a component. City, postcode, or street formatting should change. The customer can accept the suggestion.
- Unverified. Google cannot confirm the building. Rural properties, new builds, and some apartment formats land here even when a carrier can deliver.
- Invalid. There is no usable match. A fake street, an incomplete route with no house number, or a combination that does not exist usually lands here.
Your store then decides what the customer sees: a warning, a suggested address, a block, or a quiet pass with a review flag for fulfilment.
Google does not replace shipping zones, tax, or carrier rates. Those still run on country, state, and postcode. Validation answers a different question: can we ship to what they entered?
Why WooCommerce stores use Google Address Validation
Stores pick Google when they already pay for Maps Platform, use Google Places at checkout, or want one billing account to power both suggestions and the deliverability check. Address Guard Pro uses a single merchant-owned Google API key for both layers.
What that buys you at checkout:
- Postal verification instead of “fields are filled in.”
- Standardized addresses that match how carriers expect street, city, and postcode to look.
- A suggested correction the customer can accept without retyping the form.
- Component-level signals. Google can tell you it inferred a missing postcode, replaced a misspelled city, or could not confirm a unit.
- A record on the order of original versus normalized address, so fulfilment is not reconstructing the checkout from email.
That last point matters as much as the checkout message. A failed label is cheaper to fix when the order already shows that Google could not verify the street, or that the customer declined the suggested postcode.
The cost of skipping this is the usual chain: the label cannot be created, support emails the customer, delivery dates slip, and express orders miss the cutoff. One bad address might take ten minutes. Across a week of orders, those exceptions become a regular drain.
Google Places vs Google Address Validation
Stores often treat “Google Maps at checkout” as a single feature. It is two APIs, and they do different jobs.
| Product | Role at checkout | What the customer sees |
|---|---|---|
| Google Places | Autocomplete | A suggestion dropdown on address line 1. Selecting one fetches place details and fills street, city, state, postcode, and country. |
| Google Address Validation | Validation | A check before the order is placed. The store can warn, offer a corrected address, allow checkout, or block it. |
Places helps the customer enter a complete address. Address Validation checks whether that address is real. If you only turn on Places, a customer can ignore the dropdown and type a fake street. If you only turn on Address Validation, more addresses fail because they were typed poorly in the first place.
The comparison of validation vs autocomplete is worth reading if you are still deciding which layer to enable first. For Places setup in isolation, see the address autocomplete guide.
Most stores that print shipping labels need both. A practical Google pair is:
- Places on the shipping address, so city and postcode fill together.
- Address Validation on place-order, so unverified or invalid addresses are caught while the customer is still on the page.
- Local rules for missing house numbers, PO boxes, and postcode/country mismatches your warehouse will not ship.
You can mix vendors. Mapbox or Loqate for suggestions plus Google Address Validation for the check is a normal production setup. Address Guard Pro treats autocomplete and validation as separate providers. The simplest Google-only setup is Places plus Address Validation on one Maps API key.
What WooCommerce still will not do
Native checkout can:
- Require country, street, city, state, and postcode
- Offer shipping methods from those fields
- Copy billing into shipping
Native checkout cannot:
- Suggest real addresses as the customer types
- Confirm that the building exists
- Standardize formatting for label purchase
- Show a corrected address and let the customer accept it
- Keep original versus Google-normalized data on the order
Browser autofill is also not Google Address Validation. Autofill replays an address the customer saved earlier. It will fill a stale or incomplete address just as readily as a good one. Places suggestions are not validation either. A selected suggestion is structured search data. Address Validation is a separate verify step against postal records.
What happens when Google validates a WooCommerce address
A working Google Address Validation flow has four steps.
- The customer enters a shipping address. They type it, pick a Places suggestion, or reuse a saved address.
- Address Validation runs before payment. Street, city, state, postcode, and country are sent to Google. The response includes a verdict, a match granularity, and a standardized address when there is one.
- The plugin maps that verdict into a checkout action. Verified can pass. Corrected can show “Did you mean …?” Unverified can warn. Invalid can block. Provider errors can be marked for review so an API outage does not freeze checkout.
- The result is stored on the WooCommerce order. Fulfilment can see the original address, the normalized address, the status, and which rules matched.
Keep this on the shipping address. That is the address on the label. Billing can stay quieter unless invoices or tax IDs depend on a precise street. A customer may bill to a registered office and ship to a street. Those forms should stay independent.
How Google’s verdict becomes a checkout result
Google does not return a simple yes or no. It returns signals Address Guard Pro maps into statuses your rules can use.
| Google signal | What it usually means | Mapped result |
|---|---|---|
| Address complete, matched to building or unit | The location holds together | Verified |
| Google inferred or replaced a component | City, postcode, or street was standardized | Corrected |
| Formatting-only change on a complete building match | Casing, abbreviations, or punctuation changed | Verified or Corrected, not a hard fail |
| Complete but not confirmed to the building | Rural, new-build, or unusual unit format | Unverified |
| Incomplete, unconfirmed, or only matched to street or city | Fake, truncated, or internally inconsistent | Invalid |
Treat unverified and invalid as different problems. Invalid is usually a typing failure you can ask the customer to fix. Unverified is often a data-coverage gap. Blocking every unverified result will stop orders a carrier can still deliver.
When Google returns a standardized address that differs from what the customer typed, offer it. “Did you mean …?” converts better than a generic validation error.
Warn, block, allow, or mark for review
Google returns data. Your store decides the policy.
| Action | What the customer sees | Use it when |
|---|---|---|
| Warn | A checkout message. They can continue. | Unverified addresses, first-week validation, or provider uncertainty |
| Block | A checkout error. They must change the address. | Invalid matches, missing house numbers, unusable PO boxes |
| Allow | Nothing extra, or a quiet pass | Verified addresses, or cases you have chosen not to interrupt |
| Mark for review | The order can be placed. Fulfilment gets a flag. | API errors, heavy normalization, or destinations a human should check before buying a label |
Do not launch on Block checkout as the store-wide default. Rural properties and new buildings are often unverified in postal data even when a carrier can deliver there. A customer who cannot place the order does not wait around to argue with the validator.
A practical split:
- Warn on unverified Google results.
- Offer the suggested address when Address Validation returns a standardized version that differs from what they typed.
- Block missing house numbers and invalid postcode/country combinations once those rules are tested.
- Review when Google is unreachable, so a billing, quota, or network failure does not stop paid orders.
How to write the warning itself is covered in How to Warn Customers About Invalid WooCommerce Addresses.
Set up Google Address Validation with Address Guard Pro
Address Guard Pro connects Google Places and Google Address Validation to Checkout Blocks and classic [woocommerce_checkout]. You use your own Google Maps Platform API key. The plugin does not bundle provider usage, so you keep control of Google Cloud billing.
Address Guard Pro calls Google from your WordPress server. The key is never exposed in checkout JavaScript.
Step 1: Enable the APIs on a Google Cloud key
In Google Cloud Console, create or reuse a project with billing enabled, then:
- Enable Address Validation API.
- Enable Places API (New) if you want autocomplete.
- Create an API key.
- Restrict the key to the APIs you enabled.
A key that is only enabled for Places will fail the validation test. A key that is only enabled for Address Validation will fail the autocomplete test.
Watch the application restriction. Address Guard Pro calls Google from your server, so IP address restrictions on the site’s outbound IP are appropriate. An HTTP referrer restriction that only allows your domain will block server-side validation even when Places appears to work in the browser on other plugins.
Exhausted quotas, a disabled billing account, and a key restricted to the wrong APIs surface as provider errors, not as a generic WooCommerce checkout failure.
Step 2: Connect Google in WooCommerce
Go to WooCommerce → Address Guard → Providers.
- Choose Google Places as the autocomplete provider if you want suggestions.
- Choose Google Address Validation as the validation provider.
- Enter the Google API key.
- Click Test autocomplete provider and Test validation provider.
The validation tester sends a known-good address (Google’s Mountain View office) so you know the key can reach Address Validation before you turn the check on at checkout.
Do not enable checkout validation until both tests you intend to use succeed. A failed test usually means a missing key, an API that is not enabled on the project, a restriction on the key, or a billing problem.
You can mix providers on this same screen. Mapbox or Loqate for autocomplete plus Google Address Validation for verification is valid. Places plus Address Validation on one Google key is the simplest Google-only setup.
Limit autocomplete countries to the destinations you actually ship to. If the customer has already chosen a checkout country, that country should win. Otherwise a suggestion from another market fills the form, and shipping methods and tax look wrong.
Step 3: Enable validation on checkout
Go to WooCommerce → Address Guard → Checkout.
Recommended starting settings for a store that ships physical products:
- Enable checkout validation: On
- Enable address autocomplete: On, applied to the shipping address
- Validate shipping address: On
- Validate billing address: Off
- Checkout action: Warn customer
- Allow customer to continue with an unverified address: On
Start with warnings. Blocking on day one catches real problems and also edge cases you have not seen yet. Leave unverified on allow-to-continue until you have reviewed a week of real orders. Unverified is not the same as undeliverable.
Turn billing off unless you have a reason. Card networks tolerate a messy billing street better than carriers tolerate a messy shipping street.
Step 4: Put Google results on the right rules
Go to WooCommerce → Address Guard → Rules.
Google Address Validation tells you whether the address matched postal data. Rules encode what your warehouse will not ship. For most stores, start here:
| Rule | When it matches | Recommended action |
|---|---|---|
| Warn on unverified address | Google cannot fully verify the building | Warn customer |
| Block missing house number | Street line has no building number | Block checkout after you have tested it |
| Block invalid postcode/country combination | Postcode format does not match the country | Block checkout after you have tested it |
| Review provider errors manually | The Google API failed | Mark for review |
Add PO box and parcel locker rules only if your couriers cannot serve those destinations. Keep them on shipping. That workflow is covered in How to Block PO Boxes and Parcel Lockers in WooCommerce.
Rules run by priority. Lower numbers run first. Put blocking rules ahead of warnings so a missing house number is not hidden under a softer “please review” message.
Step 5: Write messages that include the Google suggestion
Go to WooCommerce → Address Guard → Messages.
When Address Validation returns a standardized address, the highest-converting prompt is the suggestion, not a generic error.
Good:
This shipping address could not be verified. Please check the house number, postcode, and country, or accept the suggested address below.
Good:
Did you mean: {suggested_address}?
Less helpful:
Address validation failed.
Use placeholders so one template works for shipping and billing: {address_type}, {suggested_address}, {postcode}, {country}. Name the field that is wrong. A message that sounds like a declined payment will raise abandonment even when the customer could have continued.
Step 6: Test Places and Address Validation on the live checkout type
Go to WooCommerce → Address Guard → Tester, then place a test order on Checkout Blocks or classic checkout, whichever your store actually uses.
At minimum, confirm:
- A known-good address places with no warning
- Places suggestions appear on address line 1
- Selecting a suggestion fills city, postcode, and country
- The same address with the house number removed matches the house-number rule
- A postcode from another country is flagged
- An unverified rural or new-build example warns and still allows Place order
- A corrected address appears when Google has one, and accepting it updates the form
- A key without Address Validation API enabled fails the validation test
- A key without Places API (New) enabled fails the autocomplete test
- Billing is left alone if you disabled billing validation
- The same flow works on a phone-width screen
- The WooCommerce order stores the original address, the normalized address, the Google status, and the checkout action
If the tester passes and checkout does not show the message, you are usually on the other checkout type (Blocks vs classic) or a theme is hiding notices. Fix that before you send paid traffic.
When Google is the right validation provider
Choose Google Address Validation when:
- You already have a Google Maps Platform project and want checkout to use the same billing account
- You want Google Places suggestions and Google Address Validation from one API key
- You ship to many countries and want broad coverage from one vendor
- You want a corrected, standardized address the customer can accept
- Fulfilment needs original versus normalized data on the order
Choose a different validation provider (or mix) when:
- You already have a Loqate or GBG account and want postal-grade Verify from that network. See Loqate Address Validation for WooCommerce.
- Your catalogue is mostly US and you already pay for Smarty
- You only need local rules (PO boxes, missing house numbers) and are not ready to add an API
Address Guard Pro does not force a single vendor. Connect the network you already pay for, or the one that covers your shipping countries best.
After the customer continues
Validation only helps fulfilment if someone can see it on the order.
Address Guard Pro stores the original address, the Google-normalized address, the validation status, matched rules, and the checkout action. Open the order and check the Address Guard panel before you buy a label when:
- The status is unverified or invalid
- The customer was warned and continued
- A suggested address was shown and declined
- A Google API error occurred
If the same Google warning keeps leading to return-to-sender parcels, change that rule from warn to block. If it never predicts a failed label, soften or remove it.
A Google setup that works for most WooCommerce stores
If you want a default that protects checkout without surprising customers:
- Enable Places API (New) and Address Validation API on your Google Cloud project.
- Create an API key restricted to those APIs, and to your server IP if you restrict by application.
- Connect both in WooCommerce → Address Guard → Providers and run the tests.
- Turn autocomplete and validation on for the shipping address only.
- Set the checkout action to Warn customer.
- Allow unverified addresses until you have reviewed a week of orders.
- After testing, block missing house numbers and invalid postcode/country pairs.
- Keep a suggested-address message so customers can accept Google’s correction in one click.
- Promote the warnings that consistently predict failed deliveries to blocks.
The goal is not to reject every unusual address. It is to catch the mistakes that would otherwise reach fulfilment, while the customer can still fix them.
Common questions
Is Google Places the same as Google Address Validation?
No. Places is autocomplete. Address Validation is the verify step. Places fills the form. Address Validation checks the form before payment. Use both if you print shipping labels.
Do I need a separate API key for Places and Address Validation?
Usually no. One merchant-owned Google Maps Platform key can power both, as long as both APIs are enabled on the project and allowed on the key. Address Guard Pro stores a single Google API key.
Does picking a Places suggestion mean the address is validated?
No. A suggestion is a structured capture from search data. Address Validation is a separate check against postal records. Run both if you need deliverability, not only a filled form.
Should I block checkout when Google returns unverified?
Not on day one. Unverified often means rural, new-build, or an unusual unit format. Warn first. Block invalid matches and local rules you have tested, such as missing house numbers.
Does this work with Checkout Blocks?
Yes. Address Guard Pro supports Checkout Blocks and classic [woocommerce_checkout]. Test the type your store actually runs, including a phone-width viewport so suggestions and notices are not clipped.
Can I use Google Address Validation without Places?
Yes. Expect more warnings, because more addresses arrive as free-typed text. Places is the cheaper way to reduce those warnings.
Can I use Google Address Validation with Mapbox or Loqate autocomplete?
Yes. Autocomplete and validation are separate choices. Mapbox or Loqate for suggestions plus Google Address Validation for the check is a normal mix.
Why did the validation test fail when Places works?
The key is probably missing Address Validation API, or it is restricted to HTTP referrers. Address Guard Pro calls Google from your server. Enable the API and allow the server IP.
Will Google Address Validation replace shipping zones?
No. Shipping zones decide which methods to offer. Google decides whether the address itself is complete and verifiable.
What if the Google API is down or over quota?
Set provider errors to Mark for review so checkout can continue and fulfilment gets a flag. Do not let a Maps billing or quota failure become a payment failure.
Check the address before you take payment
WooCommerce will accept any address that fills the required fields. Carriers will not.
Google Address Validation for WooCommerce is how you check the shipping address against postal data while the customer is still on checkout. Places helps them enter it. Address Validation confirms it. Rules encode what you will not ship. The order keeps the result so fulfilment is not guessing.
Learn more about Address Guard Pro, or start with the setup guide: Get Started.