The address was accepted, the parcel came back

A parcel comes back marked undeliverable. The address on it looked fine – the customer typed it themselves, the checkout accepted it, the label printed. Then the carrier's own database says no such street number in that postcode, and the merchant pays for the failed delivery, the re-ship, and the twenty minutes of support that sit between the two.

The awkward part is that nothing was broken. Adobe Commerce and Magento Open Source check that a shipping address is filled in. Whether it exists is a question only the carrier can answer, and the checkout never asks.

What it is for

FedEx Address Validation asks it. Each address is checked in real time against the FedEx Address Validation REST API, using the merchant's own FedEx developer credentials, and where the carrier can improve the address the customer is shown the standardised version beside what they typed and picks one. The order is placed against an address the carrier has already agreed it can find.

It runs in three places, each switched on independently: the storefront checkout, the customer's address book, and the admin Create Order screen. The third matters more than it sounds. An address a support agent types on the phone is the one nobody else ever proofreads, and it is the one most likely to carry a mishearing.

What changes in the week is small and cumulative: the failed-delivery mails stop arriving in ones and twos, and the carrier's address-correction surcharges stop appearing on the invoice.

How it can be used

Validate at checkout and let the customer decide. The default shape. The popup shows both addresses; the customer keeps theirs or takes the carrier's. Merchants who want the correction taken more often can auto-open the popup or require a validated address before the shipping step continues. The trade-off is stated plainly: every setting that pushes harder for a correction is a setting that can cost a conversion, so they are separate switches rather than one "strict mode".

Validate quietly, and only where it helps. An address already verified is not re-checked, and an address the carrier cannot judge can be configured to pass without a message. Shoppers in countries FedEx does not cover never see that they were considered.

Clean the address book instead of the checkout. Some stores would rather not touch the shipping step at all. Switch checkout off and the account address-book form on, and corrections happen where a customer edits an address deliberately, with no risk to a live order.

Validate what staff type. Checkout off, admin on: telephone and B2B orders get the check, the storefront stays exactly as it is.

How it compares

Measured on 2026-09-03 by opening eight live Marketplace listings in a browser. Everything in this area files under Shipping & Fulfillment → Address Verification, and it divides cleanly in two.

The paid shelf belongs almost entirely to one vendor, EcomPlugins, which sells the same product against four back-ends – FedEx, UPS, USPS and Smarty – at USD 49.95 for Magento Open Source, 99.95 for Adobe Commerce on-premise and 289.95 for Adobe Commerce cloud. The free shelf is three regional listings – Postcode.eu, Ideal Postcodes, Fetchify – which are thin clients for their vendors' own paid address services, excellent inside Benelux or the UK and irrelevant outside them.

Where the alternatives are genuinely better, and it is worth saying: the direct FedEx rival advertises compatibility with One Step Checkout and third-party checkout modules, which this extension does not claim – it is tested on the native Luma checkout and nothing else. It offers a public live demo, frontend and backend. It has a sibling listing that classifies an address as residential or commercial, which this extension does not do at all. And it costs 49.95 on the Open Source tier. If the requirement is a carrier lookup on a customised checkout at the lowest price, that is the honest answer.

What this one does that the measurement found nowhere else is the layer on top of the carrier's reply.

The carrier's answer is checked, not just displayed. FedEx confirms that a postcode and state exist; it does not confirm that the city spelling belongs to that postcode. "New York, NY 30301" passes – 30301 is an Atlanta postcode. The extension cross-checks the city against a bundled US database of 29,470 postcode-to-city entries across all 51 states and territories, and corrects the spelling when they disagree.

The unit number survives. A standardised address that quietly drops "Apt 4B" is worse than no standardisation, because it looks authoritative. The apartment or suite line is preserved across every address line.

More of the world is actually checked. Magento stores some region codes in a form FedEx will not accept, and the carrier rejects the whole request when it sees one – so the street, the city and the postcode go unchecked too, silently. Two releases fixed this in two different ways: 1.5.0 strips the country prefix Magento puts in front of a region code, and 1.5.2 leaves the region out entirely where it is longer than the two characters FedEx takes, letting the carrier resolve it. That covers Australia, Belgium, Colombia, Finland, Latvia, Mexico, Paraguay and Peru, among others.

A validation failure cannot cost the order. Whatever the carrier says, or fails to say – an expired session, a timeout, a firewall answering instead of the store – the shipping step proceeds. That was the whole of release 1.5.1, and it is the failure mode a merchant should ask any address-validation extension about before buying it.

It is rule-based and deterministic. It calls no service other than FedEx, using the merchant's own credentials, stored encrypted. It adds one customer-address attribute and touches no native sales table.

What it does not try to be

It is not a carrier integration: no rates, no labels, no tracking. It does not classify addresses as residential or commercial. It is not a deliverability guarantee – FedEx's answer is FedEx's answer. And it runs on the Luma theme only; there is no Hyvä storefront integration in this release. The rest of the absences are in the FAQ on the extension's page, stated as facts.