When a customer changes the delivery address on their order, Tacey checks it against an address-verification service before saving — automatically, with no button to press. This article explains what that check can tell them, and where the line is between "we can fix this for you" and "we can't be sure, so it's your call."
What the customer sees
Every problem is shown against the specific field it's about, with a one-tap fix where one exists:
"Did you mean 6750 Ayala Avenue?" with a Use 6750 Ayala Avenue button — the street name looks like a typo of a real, deliverable address.
"The postal code for this address is 94043-1351." with a Use 94043-1351 button — same idea, for a postal code.
"This address is in Mountain View." with a Use Mountain View button — the city doesn't match what the postal code and state say.
The customer taps whichever fixes apply, and only those fields change — nothing else about what they typed is touched. There is deliberately no single "replace my whole address" button. A one-tap whole-address swap is more than most customers need, and it's a bigger change than the specific typo actually calls for.
When only the general area can be confirmed
Some countries' address services can only confirm a general area, not the exact street or building, even for a completely correct address. Tacey never treats that as a problem the customer needs to fix:
"We found the area, but couldn't confirm the street" — shown for countries where the service reaches this ceiling. Deliveries generally still work; there's simply no more precise confirmation available.
"We found this address, but can't confirm the exact building" — the equivalent message for Brazil and Mexico specifically, where the address service can confirm the neighborhood or street but not the individual building, even on a flawless address.
Both of these come with a Keep it as it is button that always works, because there's genuinely nothing more specific for the customer to confirm.
What Tacey never flags
A handful of things are deliberately never treated as a problem, because flagging them would waste a customer's time correcting something that was never wrong:
A single-letter spelling difference in a name or street — the kind of thing a delivery person reads correctly without a second thought. Truncated or clearly wrong text still gets flagged; a near-identical spelling doesn't.
A neighborhood or district the customer typed, when the address service's own answer for that address independently names the same area — Tacey doesn't second-guess a customer who was more specific than the service's summary.
A correction to a field your store's address form doesn't even ask for. If the service comes back with an opinion about a field the customer was never shown, Tacey doesn't surface it or block on it.
Postal code and state/province checks (US, Canada, Brazil)
For these three countries, Tacey also checks that the postal code and the state or province actually belong together — a wrong-state, right-postal-code combination is a physically impossible address, and it's caught before the change ever reaches Shopify, with a plain explanation. This check always runs, on every order, regardless of your "Block addresses we can't confirm" setting — it isn't optional, because there's no legitimate case where the two genuinely disagree.
"Keep it as it is"
Your customer's own word is the final answer whenever Tacey's check genuinely can't tell them anything more specific than "something looks off." That's why "Keep it as it is" or "Keep my address" shows up on every "we found the area but not the street" and "can't confirm the exact building" result, with no exceptions.
Your "Block addresses we can't confirm" setting (in the tool's settings page) governs what happens when the check can't confirm anything at all about an address — see Let customers edit their delivery address for what that setting does.
If the customer taps a specific fix (like the postal code correction above), the address is re-checked, and once every flagged field is resolved, the save goes through normally.
A check that's down never blocks the customer
If the address-verification service is slow, unavailable, or returns something Tacey doesn't understand, the save is never held up because of it — the address is saved as the customer typed it, with no check at all. A temporary outage on our side, or a vendor's, should never cost you a delivery-fixing customer their chance to fix it.
Confirming before it saves
If you've left "Ask the customer to confirm" on (the default), the customer sees a plain summary — "Check before we save" — naming the exact address about to be saved, before anything actually happens. They can go back and change something, or confirm and save.
What this does NOT do
It does not guess. Every fix offered comes from a real answer the address service gave for that specific address — Tacey never invents a correction.
It does not silently replace an address the customer wants to keep. A tapped fix always requires the customer's own tap.
It does not treat "we can only confirm the general area" as a reason to refuse the save. That's a limit of what's checkable, not a problem with the address.
It does not hold up checkout, or the customer's ability to fix their own order, because a vendor is slow.
Frequently asked
Why did my customer's correct address get flagged as needing attention?
A small number of countries only get area-level confirmation from the address service, even for a genuinely correct address. If your customer sees "we found the area but couldn't confirm the street" or the Brazil/Mexico "can't confirm the exact building" message, their address is very likely fine — that's exactly what "Keep it as it is" is for.
My "Block addresses we can't confirm" setting is on. Why did an address save anyway?
That setting is meant to only block addresses the check couldn't confirm anything about — it never blocks the two area-only results above, because postal services generally still deliver to a confirmed neighborhood, and refusing those would create refusals with nothing for the customer to fix.
Related