How to test checkout address validation: formats, tax, and shipping the happy path misses

The address form is the part of checkout everyone tests once and never revisits. Type a real address, watch it get accepted, move on. But the address field is doing far more than collecting text — it decides whether the package can be delivered, which tax rate applies, which shipping methods appear, and what the final total is. Every one of those is a downstream consequence of what the form accepts, and every one of them is a place the happy-path test never looks, because the happy-path test only ever enters one address: a valid one, in the tester's own country, that the app already handles. Address validation is the logic that runs on all the other addresses. That's what this playbook tests.

What "correct" address validation actually looks like

Before testing the behavior, it helps to name it, because "validate the address" hides three different outcomes. Google's own address validation for checkout guidance sorts every submitted address into three buckets: Fix — the address is low quality, so prompt for more information; Confirm — high quality but the system changed something (a corrected city, a standardized street), so ask the user to confirm; and Accept — high quality, proceed with no prompt. A good checkout does something sensible in all three, and the interesting bugs are in the first two, because Accept is just the happy path wearing a badge.

There's a second principle in that same guidance that teams get wrong in the opposite direction — being too strict. Google is explicit: your implementation "doesn't block customers from checking out due to entering an invalid address," and recommends giving customers "up to two chances to enter their address, and on the second attempt, accept their entry, even if it does not validate," optionally flagging it for review. The reason is concrete: a newly constructed building has a real address that isn't in the postal database yet. Reject it outright and you've refused a paying customer for being early. So address validation has two failure modes — too loose (garbage gets through to fulfillment) and too tight (real customers get locked out) — and a test that only enters valid addresses proves neither is under control.

Prompt 1: international formats and reordered fields

The fastest way to find an address-validation bug is to submit an address that's valid somewhere your dev team doesn't live. Postal codes that contain letters, addresses with no state/province, countries where the house number comes after the street — a form built and tested against one country's shape tends to reject or mangle the rest.

Go to https://staging.yourapp.com and add any product to the cart, then
proceed to the checkout address form.

Test how the form handles addresses from several countries. Enter each
of these in turn and report what happens:
1. A UK address with an alphanumeric postcode (e.g. SW1A 1AA) and no
   "state".
2. A Japanese or German address where the postal code / house-number
   ordering differs from US format.
3. A US address with a valid ZIP+4 (e.g. 10001-2312).

For each: does the form ACCEPT the valid international address, or does
it reject a legitimate postcode, force a required "State" field that
doesn't apply, or silently drop a field? Report which fields were
required, which were rejected, and any address that a real resident of
that country would consider correct but the form refused. Capture the
form state after each submission.

The finding here is usually a required field that shouldn't be, or a postcode regex written for five US digits. Neither shows up when the only address you ever test is your office. The agent works from the described intent — "enter a valid UK address, report if it's refused" — so it's testing the behavior, not a memorized set of selectors that a form redesign would break.

Prompt 2: missing, malformed, and the two-attempt rule

Now push on the invalid side. An empty required field, a postcode that's the right length but nonexistent, a house number of 0, a city that doesn't match the postcode. The correct behavior isn't "accept everything" or "reject everything" — it's the graduated Fix/Confirm/Accept response, including the escape hatch Google recommends so a real customer isn't trapped.

On https://staging.yourapp.com, go to the checkout address form with an
item in the cart and test invalid and incomplete addresses:
1. Leave a required address field blank and submit. Confirm the form
   refuses clearly and names the missing field — not a generic error,
   not a silent pass.
2. Enter a well-formed but nonexistent postcode for the selected
   country. Report whether the app asks you to fix or confirm it, or
   accepts it without comment.
3. Enter an address the validator flags, then try to submit the SAME
   address a second time unchanged. Report whether the app eventually
   lets you proceed (with the order flagged for review) or traps you in
   a loop that never allows checkout.

Flag two opposite failures: an obviously broken address that sails
through to the payment step, AND a form that refuses to ever let you
continue after a couple of attempts. Capture the message shown at each
step.

Step 3 is the one nobody tests, because it requires deliberately failing validation twice — behavior a scripted happy-path test is structurally incapable of, and exactly the kind of accidental-path bug an agent catches that your scripts miss. An infinite validation loop is a checkout you can't complete, which is a revenue bug wearing a UX costume.

Prompt 3: the correction the customer never confirmed

The Confirm case is the subtle one. The validator decides your address is basically fine but tweaks something — corrects a misspelled city, standardizes "Street" to "St", adds a ZIP+4. Google's guidance is specific that this should not happen silently, because "the changes made by the API might fundamentally alter what was originally entered"; the recommended pattern is an interstitial that gives the customer three choices — confirm the corrected version, keep the address exactly as they typed it (optionally flagged for review), or cancel back to the form. The bug is a checkout that silently overwrites what the customer entered with the "corrected" version and ships to an address they never saw.

On https://staging.yourapp.com, go to checkout with an item in the cart
and enter an address with a small, correctable imperfection — for
example, a lowercase city, a common misspelling, or "Street" spelled
out where the app might standardize it.

1. Submit the address and watch what the app does: does it show you the
   standardized/corrected version and ASK you to confirm, or does it
   silently accept a changed address with no prompt?
2. If it prompts, confirm whether you can choose to keep your ORIGINAL
   entry, not just accept the correction.
3. Whichever you pick, proceed and then check the order confirmation to
   see which version — corrected or original — was actually stored.

Flag it if the app changed the address without showing you, or if the
prompt only offers "accept the correction" with no way to keep what you
typed. Report both the entered address and the stored address, and
capture the confirmation step.

A silent correction feels harmless until it turns a valid apartment into the wrong unit, or "re-corrects" an address the customer deliberately entered because they know their new building isn't in the database yet. Surfacing the change and letting the customer decide is the difference between helpful and presumptuous — and it's invisible to a happy-path test that only ever enters addresses the validator leaves untouched.

Prompt 4: tax and shipping recompute with the address

Here's where the address stops being a form and starts being money. In most stores the shipping address determines the tax rate and the available shipping methods, and both must recompute — visibly — when the address changes. The bug is a total that doesn't update: you enter a tax-free state, the tax line stays, and the customer is overcharged, or the reverse and you eat the difference.

On https://staging.yourapp.com, add a product to the cart and go to
checkout. Test that tax and shipping respond to the address:
1. Enter a shipping address in one region (e.g. a state/country with
   sales tax or VAT) and record the tax line and the order total.
2. Change ONLY the shipping address to a different region (e.g. a
   no-sales-tax state, or a different country) and record the tax line
   and total again.
3. Report whether the tax amount and the order total actually
   recomputed for the new region, or whether the old tax carried over.

Also check shipping: when the address changes, do the available
shipping methods and their costs update, or does a method that isn't
valid for the new destination stay selectable? Report the tax, the
shipping options, and the total for each address, and flag any case
where the total did not change when the region did.

Assert on what's presented, not on a tax table you're maintaining separately — the agent reads the tax line and total off the summary and reports them for each address, and the failure is a total that stayed the same across two regions that should tax differently. This is the same "test the seams between screen, provider, and total" logic the subscription-billing playbook uses on plan changes, applied to geography instead of time. One honest scope note: a browser agent confirms the total changed correctly relative to the address; it isn't a tax engine and won't tell you the rate itself is legally right for a jurisdiction — that's a job for your tax provider's own tests. What it owns is the far more common bug: the total that didn't move when it should have.

There's a related shipping edge worth its own attention: the type of address, not just its region. Many carriers won't deliver to a PO box, expedited or freight methods often aren't available to every destination, and some stores price residential and commercial addresses differently — Google's validation even returns a residential-or-commercial indicator in select regions for exactly this reason. Enter a PO box and confirm the methods that can't serve it actually disappear rather than staying selectable and failing at fulfillment; enter an address that only qualifies for standard shipping and confirm the express option isn't quietly offered. The pattern is the same as the region test — the available methods and their prices are a function of the address — but the trigger is the address's category, which is precisely the input a happy-path test using one familiar home address will never vary.

Prompt 5: the address that survives to the confirmation

The last mile of address testing is persistence: the address the customer confirmed is the address the order actually ships to. Corrections made mid-checkout, an apartment number added after autocomplete, a "confirm this standardized version?" prompt — any of these can end with the order storing a different address than the one on screen at the final step.

On https://staging.yourapp.com, complete a checkout end to end with a
specific shipping address you record exactly (include a unit/apartment
number, e.g. Apt 4B). If the app suggests a standardized or corrected
version of the address, note both what you entered and what it
proposed.

After placing the order:
1. Open the order confirmation page and the order in account history.
2. Compare the shipping address stored on the order against the address
   you confirmed at checkout, field by field.
3. Report any discrepancy — a dropped apartment number, a silently
   applied correction the customer never confirmed, a reordered field.

Flag any case where the stored/confirmed address differs from what the
customer actually approved at the final step. Capture the checkout
address and the order-history address.

A dropped unit number is the address bug that generates a "where's my package" ticket a week later, long after the checkout looked perfect. This is the address-specific cousin of confirming the discount and total reconcile at checkout and that a Stripe charge matches the order — the through-line is that what the customer saw and approved has to equal what the system stored, and multi-step forms are where those quietly diverge, the same drift the multi-step form playbook chases.

Reading the results

Each run returns a Monito Session: a screenshot timeline of every address state, plus the network log. For address validation the network log matters because the total, tax, and shipping options are usually recomputed by a request the app fires when the address changes — captured with its method, URL, and status — so a total that didn't update is visible as a request that didn't fire or a response that came back unchanged. The screenshot timeline is where the format-rejection and dropped-field bugs show themselves.

The one to run right now

If you run one address test today, run the tax-and-total recompute — it's the one that costs real money in both directions. Save it as a Test Scenario, point it at staging, and wire it into CI against every deploy that touches checkout, tax, or shipping.

Test checkout address handling on https://staging.yourapp.com. Add any
product to the cart and go to checkout.

First, enter a shipping address in a region that charges sales tax or
VAT and record the tax line, the available shipping methods, and the
order total. Then change ONLY the shipping address to a different region
(a no-tax state, or a different country) and record the tax line,
shipping methods, and total again.

Report both sets of numbers side by side and confirm the tax and the
order total actually recomputed for the new region, and that the
shipping methods offered are valid for the new destination. Flag any
case where the total or tax did not change when the region did, or where
a shipping method that shouldn't apply to the new address stayed
selectable. Capture the order summary at each address and include the
full network log.

A full run is typically 8–13 credits — about $0.08–$0.13 — and your first run is free. Monito plans start at $99/mo, Enterprise at $129/mo. The address form looks like the simplest thing in checkout; it's quietly the field that decides whether the package arrives, what the customer pays, and whether the total is right. Test the addresses you don't live at — that's where it breaks.