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."
The badge, before they even open the form
If there's something worth a customer's attention, they don't have to open "Edit delivery address" to find out: a small label appears right on the row itself.
"Suggested fix available": Tacey has a specific, one-tap correction ready.
"Address check needed": something about the address is worth a look, but there's no single one-tap fix (for example, the area-only or building-only cases described below).
This shows on both pages the tool can appear on, the Thank you page right after checkout and the Order status page a customer returns to later, using the exact same check either way. It never appears for an address Tacey has nothing to say about, and it never appears when you've turned "Suggestion mode" to Never. The moment the customer resolves it, by tapping a fix, tapping "Keep it as it is," or otherwise saving, the badge disappears from the row for the rest of that visit.
On the Thank you page only, the badge can take a few seconds to appear. The address check runs in the background right after an order is placed, and the Thank you page can load before that check has finished. If it hasn't finished the moment the page loads, Tacey quietly checks again a few times over the following seconds; once a result exists, the badge appears with no page reload needed. The Order status page doesn't have this delay, because a customer only reaches it later, after the check has had time to finish.
What the customer sees
When Tacey has a specific corrected version of the address to offer, it's shown as two cards, side by side on desktop and stacked on a phone, not a list of per-field fixes:
Current — the address exactly as the customer typed it, marked "Current: undeliverable" or "Current: not confirmed", with one plain reason underneath (for example, "The postal service doesn't recognise this building number").
Suggested — Tacey's corrected version, pre-selected, carrying a Recommended badge and "Suggestion: deliverable." Where only some fields changed, the card names them (for example, "Postal code: 94043 → 94043-1351").
Above the two cards sits "We found a better match. Which should we use?" with "Choose an option below" underneath, and if something about the typed address looked wrong, an "Address issue detected" flag at the top. Below the cards, a short line — "We check your address before your order ships" — reassures the customer this is a normal part of checkout, not a problem unique to them.
The customer picks a card (each has its own selector, and the whole card is tappable), then presses the one button at the bottom. Its label follows whichever card is selected: "Use suggested address" or "Keep my address." Whichever they pick, pressing the button always does something — there's no state where the button is there but nothing happens.
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 How do I let customers edit their shipping address after checkout? 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