A customer can know their address better than your checkout does. A new building may be missing from the lookup. A business may receive parcels through an entrance with a different street number. A suggested address may identify the building while dropping the apartment that makes the delivery possible.
The checkout needs a useful way forward in each case. Repeating “Enter a valid address” after the buyer has entered the same real address twice gives them no new information. Let them distinguish a typing mistake, a missing lookup result and a delivery restriction, then respond to the actual problem.
The GOV.UK address pattern explicitly provides for manual entry when an address is missing or listed incorrectly. Its country-specific guidance concerns UK services; the broader recovery principle is useful for commerce: a lookup should help someone supply their address, and its failure should have a defined alternative.
Start with four different outcomes
Treat address lookup as a branching interaction. The following is a proposed checkout design, not a report of a tested retailer implementation.
| Lookup outcome | What the buyer sees | Useful next step |
|---|---|---|
| A complete match | The selected address, including any unit details | Continue or edit |
| A suggested change | Their entered address beside the proposed address | Accept the suggestion, retain their entry where permitted, or edit |
| No matching result | A specific explanation that the search found no match | Enter the full address manually |
| The lookup service is unavailable | An explanation that address search is temporarily unavailable | Continue through manual entry if the ordering system supports it |
Keep a separate outcome for an address the business cannot serve. An unsupported destination is a commercial constraint. A search returning no matches is a limitation of the search. Calling both “invalid address” leaves customers guessing whether a different spelling will solve the problem.
Before writing the messages, ask operations which destinations and address types the business actually accepts. If a carrier restriction prevents delivery to a particular type of address, explain that restriction and offer the supported alternative. Do not invent a manual override that the fulfillment system cannot honor.
Preserve the buyer’s version
Suppose a customer enters the fictional address “18 Sample Lane, Unit C” and the lookup returns “18 Sample Lane.” The suggestion has made the address shorter, but that does not make it more useful. If the interface silently replaces the entry, the customer may never see that the unit disappeared.
Show the address that will be sent to fulfillment before the buyer continues. If a suggestion changes a consequential part, make the comparison visible. Labels such as “You entered” and “Suggested address” explain the choice without presenting a confidence score the customer cannot interpret.
Preserve the original entry when the customer opens the correction form. Retaining street, unit, postal code and country saves retyping and lets the person focus on the disputed part. If the buyer chooses the suggestion, retain an obvious edit action. Accepting a standardized street abbreviation should not make an apartment field disappear.
The same principle applies after navigating back from delivery options. The confirmed address should reappear as confirmed. A fresh lookup must not quietly overwrite it with a different version simply because the customer revisits the page.
Ask for the missing part, not the entire address
Google’s Address Validation guidance distinguishes responses that call for fixing an address, adding a subpremises such as a unit number, confirming a possible issue, or accepting the address. These are different prompts, and Google describes the workflow as dependent on the application’s circumstances and risk tolerance.
Use that distinction to keep the question narrow. When a unit number appears to be missing, ask whether the address has an apartment, suite or unit. Do not state that every address in the building must have one unless the business has reliable support for that requirement.
A proposed message could read: “Does this address have an apartment or unit number? Add it below, or continue if there isn’t one.” Whether continuing is available depends on the actual delivery rules. If it is unavailable, explain the specific detail that must be supplied and provide a contact route for exceptions.
When the postal code and city appear inconsistent, keep both visible. Let the buyer correct either one. Forcing a new postal-code search can be frustrating if the issue is an outdated city label rather than a mistyped code.
Make manual entry a complete route
A manual-entry link that opens unusable fields is only a decorative escape hatch. The customer still needs enough space for their address, appropriate labels for the selected country and a way to include delivery details that matter.
Try the route with an apartment, a business name and a longer street address. Check what happens when the country changes after some fields have been filled. Does the form retain reasonable information, or does it reset everything? Does it demand a state in a country where that field does not fit? Does the address that appears in the order review match what the customer entered?
Avoid making every field required merely because the database has a column for it. Separate the postal address from optional delivery instructions. A request to use a side entrance should not become part of a street line if the carrier integration has a dedicated instructions field.
Manual entry also needs a clear final action. “Use this address” is easier to interpret than another ambiguous “Search” button. If the system will validate the entry again, handle the result without returning the person to the same unanswered question.
Put a limit on the correction loop
Consider a buyer who sees a suggestion, chooses their original entry and then receives the identical suggestion at the next step. The system has accepted the click but rejected the decision. A second screen cannot resolve the uncertainty if it contains no new information.
Define which problems block an order and which require acknowledgement. For an acknowledged warning, retain the decision for that address and order. For a blocking problem, name the condition and the available resolution. Repetition is justified only when something material has changed, such as a different destination or delivery method.
Give support enough context to help. A reference to the order attempt and the disputed field is more useful than asking the buyer to repeat the entire journey over email. Handle address information through the business’s normal customer-service process; a public screenshot or analytics event does not need the full postal address.
Check the package that leaves checkout
The most revealing review follows one address through selection, correction, delivery choice and order review. Compare the final address with the buyer’s confirmed version. Check that the unit survives, the country remains correct and the selected delivery service still serves that destination.
Then try a missing result and an unavailable lookup. Someone should be able to tell which happened and what to do next. Include keyboard use in this review so that the manual-entry option and suggested-address choices are reachable without a pointer.
If abandonment remains high, examine the address step alongside the wider checkout diagnosis. Count correction loops and manual-entry completion separately from ordinary lookup success. A rising share of manual entries may reveal a coverage problem even when total checkout completion looks stable.
The release decision is practical: can a buyer with a supported, real address get the correct address into the order without fighting the lookup? That is the standard the recovery flow should meet.