A customer reaches checkout, enters their postcode and cannot find their flat in the address list. They know where they live, but your website will not let them continue. That is a checkout problem worth investigating before spending more money bringing people to the store.
For UK retailers, the practical fix is usually to keep address lookup as a convenience and provide a working manual-entry route. Customers should be able to supply their real delivery details, while your business still checks whether it can fulfil the order.
This guide explains how to investigate missing addresses, make the fallback useful and test what reaches your order and dispatch systems. The recommendations apply to custom checkouts and commerce platforms where these controls can be configured or developed.
Separate missing addresses from delivery restrictions
An unsuccessful search does not tell you why checkout has failed. Start by reproducing the reported problem and identifying which of these situations applies:
- The postcode entry is incomplete or malformed. The customer needs a specific correction.
- The search completes but the address is missing. They need another way to enter it.
- The lookup service fails. Your developer needs to investigate the integration.
- The address is outside your delivery coverage. The customer needs an accurate explanation of that restriction.
Do not use the same “invalid address” message for all four. Otherwise, a genuine delivery restriction can look like a technical fault, and a technical fault can look like the customer’s mistake.
The GOV.UK address pattern explicitly allows for addresses that are absent or incorrectly listed in a lookup and recommends providing manual entry. A missing lookup result therefore does not, by itself, establish that an address is wrong.
Ask your developer which provider supplies your checkout results. For a reported address, compare that provider’s response with Royal Mail’s public finder. This is a diagnostic comparison, not proof that two different services must return identical records. Check the lookup connection and its errors before changing your address rules.
Offer manual entry before customers get stuck
Make the alternative visible beside the lookup, with straightforward wording such as “Enter address manually”. Keep it available when there are no results and when the lookup is temporarily unavailable.
The Scottish Government’s address pattern, updated on 24 June 2026, includes manual entry alongside postcode search and says unsuccessful searches should explain what happened and what to do next. These are useful design recommendations for a commercial checkout; they are not a requirement to adopt government styling.
For an online shop, we recommend editable address fields that preserve the postcode already entered. Switching routes should not clear the basket, selected delivery option or unrelated checkout details. Let customers review the resulting address before committing the order.
Manual entry must work beyond the screen. Ask whether the order can be saved without a lookup-provider reference. If your integration requires that reference for every address, displaying editable fields alone will not resolve the problem.
Agree how uncertain destinations will be handled operationally. Where fulfilment needs additional confirmation, give your team a clear review route and tell the customer what happens next. Avoid silently substituting a nearby address just to make an integration accept the order.
Accept normal postcode variations and complete delivery details
The GOV.UK address guidance recommends accepting postcodes in upper or lower case, with or without spaces, and tolerating unwanted spacing and punctuation. It also recommends accommodating longer addresses, including company names and flat numbers, and making county optional because it is not needed for postal delivery.
Your developer should distinguish harmless formatting from missing information. Normalising spacing should not remove an apartment identifier, replace a building name or turn an incomplete entry into an apparently confirmed destination.
Our practical starting point is to check the information your fulfilment process actually uses: recipient, building or street details, any flat or unit, town, postcode and destination country. Make additional lines optional unless the particular delivery genuinely requires them. If county has a business purpose, explain it rather than treating it as a universal postal requirement.
A delivery instruction such as where to leave a parcel belongs in a separate field. Test that it stays separate in the dispatch record too. A correct-looking checkout can still produce an incomplete label if an integration maps the flat number into the wrong place or drops an additional address line.
Help browsers fill the right address
Address lookup and browser autofill solve different tasks. Lookup retrieves an address from a service; autofill helps a customer reuse details stored in their browser. Test both routes.
The HTML Living Standard’s autofill definitions include address-line1, address-line2, address-level2 and postal-code, plus shipping and billing tokens to distinguish the two address groups. Ask your developer to apply the appropriate values to the real checkout fields.
W3C’s explanation of WCAG 2.2’s Identify Input Purpose criterion says supported fields collecting recognised types of information about the user should expose their purpose programmatically. Visible labels alone do not provide that machine-readable meaning. Correct autocomplete attributes are a relevant HTML technique; they do not guarantee that every browser will offer an autofill suggestion.
Check a saved delivery address on a phone and a computer. Then test a different billing address. Confirm that selecting or editing one group does not unexpectedly replace the other, and that the final order records both correctly.
Let customers reuse an address when it is the same
Provide a clear way to use the delivery address for billing while retaining an option to enter a different one. W3C’s Redundant Entry guidance says information required again in the same process should be populated or available to select, subject to exceptions for essential re-entry, security or information that is no longer valid. It gives matching billing and shipping addresses as an example. Browser autofill alone is not the website providing previously entered information.
Make each failure recoverable
When checkout detects an input error, WCAG 2.2’s Error Identification criterion requires the affected item to be identified and the error described in text. A coloured border alone is insufficient.
Write messages for the situation you have actually detected. An empty postcode needs a request to enter it. No matching addresses needs a manual-entry option. An unavailable lookup needs an explanation that address search is unavailable, with a usable alternative where your checkout supports it.
Keep entered details visible during correction. Check that customers can reach the address suggestions, select an entry, switch to manual entry and continue using a keyboard. If the fallback appears dynamically, ask your developer to verify that assistive technology users can discover and use it.
For faults your team must investigate, record enough technical context to distinguish a lookup failure from an empty result. Keep customer names and complete addresses out of general analytics events. Use appropriately controlled support records when a particular customer’s details are necessary to resolve their case.
Test the order, not just the address box
Ask for a short test record covering the following routes in an isolated test checkout, using agreed test addresses and the payment provider’s supported test method:
- A normal lookup result: select it, review it and confirm the saved order matches.
- A missing address: use manual entry and verify that the order does not require a lookup reference.
- A flat or business unit: check that every essential address line survives into the dispatch system.
- Postcode variations: try lowercase, omitted spacing and extra spaces with the same expected destination.
- Lookup failure: have the developer simulate an unavailable service and demonstrate the recovery route.
- Different billing and delivery addresses: verify both, then test the option to reuse one address.
- A destination you do not serve: confirm manual entry still enforces the delivery restriction and displays the correct explanation.
Repeat the important routes on mobile and check the keyboard journey. Inspect the order confirmation, stored address and test dispatch output. Do not sign off on the strength of fields merely appearing correctly on screen.
After release, review address-related support requests and checkout errors alongside completed orders. Separate provider outages from input corrections and genuine coverage restrictions. That gives you a useful repair list without assuming every abandoned checkout was caused by address entry.
Make address entry part of a dependable checkout
Start with one clear outcome: a customer with a serviceable destination can provide complete details, recover from a missing lookup result and place an order your team can fulfil.
Address entry belongs within the wider customer journey covered by BuzzBoost’s web design service. If customers are getting stuck at this stage, talk to BuzzBoost about reviewing your checkout and address integration. Bring a reproducible example and the point where it fails so the work can begin with evidence.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
