Flat Above the Chip Shop: The Quiet Chaos of UK Address Data

Buying anything online in Britain can feel like a test of faith. You type your address, the form insists your postcode is invalid, then it offers a dropdown of three streets that are all wrong. The parcel still arrives, usually, because a human somewhere reads the label and makes a judgement call. That is not a checkout flow. It is a folk remedy.

The awkward truth is that UK addresses are not a single piece of text. They are a set of overlapping systems, each with its own authority, quirks and failure modes. Treat them like a free-text field and you will lose customers quietly — not with a dramatic crash, but with abandoned baskets and support tickets that say 'it would not accept my flat'.

An address is a protocol, not a string

Protocols have rules, versions and edge cases. They also have a centre of authority. In the UK, that centre is split. Royal Mail maintains the Postcode Address File, usually called PAF. Ordnance Survey maintains the Unique Property Reference Number, the UPRN. Postcode geocoders turn a postcode into a point, sometimes with a rooftop-level accuracy claim and sometimes with a vague shrug. what3words offers a three-word location that is brilliant for a picnic bench in a field and not a postal addressing system.

Each layer answers a different question. PAF asks: where does Royal Mail deliver? The UPRN asks: which property is this, exactly? Geocoding asks: where is it on a map? what3words asks: where is this specific three-metre square? A checkout that treats all of these as one text field is not simplifying the problem. It is hiding it.

The layers most checkouts ignore

PAF is the backbone of UK address lookup. It is licensed, structured and very good at what it does, but it is not a live mirror of every new build, subdivision or informal flat conversion. If your address lookup only accepts a PAF match, you will occasionally tell a real customer that their real home does not exist.

The UPRN is the identifier most product teams underuse. It is stable, property-level and useful for matching records across systems. It will not replace a human-readable address, but it gives you something a postcode cannot: a way to say 'this exact property' without relying on line one being typed the same way twice.

Postcode geocoding is similarly seductive. A postcode is not a point. It is a set of delivery points, sometimes a few, sometimes dozens. Centroid coordinates are fine for rough analytics and useless for saying which door is yours. If you use a pin to validate an address, you are testing geography, not deliverability.

what3words is a useful supplement, not a replacement. It is excellent for rural meetups, event entrances and awkward delivery notes. It is not a postal address, and it should never be the only way a customer can tell you where they live.

Where the flat above the chip shop breaks

The classic UK failure is mixed-use property. A flat above a chip shop may share a postcode with the shop, have no separate PAF entry, and use a door that is not the obvious front door. The customer knows exactly where they live. Your form does not.

Other edge cases are just as ordinary:

• Flats and sub-units that were carved out after the building was built.
• New builds that are occupied before the address data catches up.
• Student halls and serviced apartments with their own internal room numbering.
• Rural properties with names instead of numbers, and no street line that makes sense to a database.
• PO boxes, BFPO addresses and business addresses that are not residential but still need to be valid.
• Customers who live somewhere that Royal Mail knows about but your third-party lookup vendor has not refreshed.

The common thread is not stupidity. It is over-strict validation. A form that refuses a manually entered address because it cannot find a match is optimising for clean data at the expense of actual orders. Clean data is nice. Revenue is nicer.

What to build instead

Start with lookup, not gatekeeping. Offer an address finder for the happy path, then always provide a manual entry route. Do not hide it behind a tiny link that says 'enter address manually' in grey. Make it a first-class option.

Store what you need, not just what you can verify. Keep the human-readable lines, the postcode, any UPRN you have, and a delivery notes field. If a customer says 'flat 3, above the chip shop, blue door', that is not noise. That is operational intelligence.

Be careful with regex. UK postcodes are more varied than many developers assume, and postcode validation should reject obvious nonsense without rejecting real life. The same goes for house numbers and flat numbers. If your validation rule assumes a number followed by a street name, you have already lost.

Test with messy addresses before launch. Grab a handful of real examples from support tickets: the flat above a shop, the new build, the farm with a name, the hall with a room number. Run them through your checkout. If the form fails, fix the form, not the customer.

The protocol mindset

A UK address is brilliant infrastructure with visible seams. PAF, UPRNs, geocoders and what3words each solve a different slice of the problem. The product teams that get this right do not treat address entry as a text field with a postcode checker bolted on. They treat it as a protocol: multiple authorities, imperfect freshness, edge cases by default and a human fallback that is always available.

That is less tidy than a single regex. It is also how you stop losing the flat above the chip shop.