USPS can charge you $50 after the package ships. I built a free checker to catch it before you buy the label

CanWeShip — Sat, 12 Sep 2026 17:40:18 +0000

A package gets accepted at the post office counter, ships without a problem, and weeks later the shipper's account takes an adjustment: a $50 hazardous materials noncompliance fee. Nobody warned the shipper. The counter clerk didn't catch it. The parcel was already delivered.

I kept running into this story while researching USPS's dangerous goods rules, and the more I dug into the official documents, the stranger it got. So I built a tool to catch it before the label gets bought. This post is about what I found and how the tool works — the design might interest you if you build anything where correctness matters more than cleverness.

What the official documents actually say

Here's the fun part. The authoritative sources don't agree with each other — and the newest information isn't where you'd expect it.

On 2026-05-15, a Federal Register document (2026-09785) described the fee as an 8-point "Hazmat Quality" check with a 100% threshold.
Seven weeks later, USPS walked that back in a PostalPro Industry Alert (2026-07-07): the fee is assessed per package through Census and Automated Package Verification (APV), by comparing four data points — Service Type Code, service icon, barcode banner text, and DOT markings.
The same alert says a package that both skipped the handling fee and failed the markings check gets charged twice. The Federal Register text only says the higher of the two.
And the bit I couldn't find in any Federal Register document at all: USPS Returns shipments become subject to the fee starting 2027-02-01. That date exists only in a follow-up Industry Alert, corroborated by Postal Bulletin 22709 (a DMM revision).

So the ground truth lives in three Industry Alerts, a Federal Register notice, and a Postal Bulletin — none of which a regular seller would ever think to cross-reference. Meanwhile the top Google results for "why did USPS charge me a hazmat fee" are forum threads and outdated blog posts.

That gap is the whole product thesis: the answers exist, they're official, and they're scattered across documents that contradict each other.

What I built

CanWeShip is a free pre-shipping checker: pick your product (perfume, power bank, laptop, dry ice, nail polish, paint, perishable food…), answer a few questions about quantity, packaging and carrier, and get USPS, UPS and FedEx side by side — ship / conditional / don't buy the label — with the exact requirements and a cited official source plus verification date on every row.

It also refuses to guess. If a critical fact is unknown, you get MORE_INFO_NEEDED or CONDITIONAL with a list of exactly which facts are missing — never a confident "probably fine". For the USPS fee specifically there's a path that just says don't buy this label before you're at the counter.

The part I'd discuss with dev.to readers: no LLM in the decision path

It's 2026, so the obvious question is why this isn't a chatbot. Three reasons:

1. Determinism is the product. The verdicts come from a rule engine running over versioned JSON rule sets. Every rule row traces to a source ID with a verification date and a content hash, and the rule directory ships with a validation suite that rejects duplicate product IDs, conflicting aliases, and sources from unofficial domains. If someone asks "why did it say don't ship this?", the answer is a traceable chain, not a plausible paragraph.

2. LLMs are on the input side, locally. The AI-adjacent features — parsing text you paste from an SDS, reading battery label photos for voltage/Ah/Wh hints — run entirely in your browser. They produce evidence cards with extracted values, source section, and confidence. You confirm them; only then do confirmed facts feed the deterministic engine. Photos never leave the device.

3. Privacy is a feature, not a promise. No account. No emails. Server-side analytics are anonymous funnel events without IPs, raw URLs, or your answers. A SDS PDF you read stays local.

The same rule runtime also powers a stateless API (POST /api/v1/check — you send confirmed product facts, it returns the three-carrier result plus a decision trace with rule versions) and an MCP tool, so a script or agent can pre-check a cart before checkout.

Honest status

It's a solo project, early. ~25 product risk profiles, US domestic, three carriers. Traffic is tiny but converting well — the people who land on it do finish checks. The gaps I know about: no batch catalog checks, no multi-item same-box compatibility, and the coverage is nowhere near "every SKU".

Feedback I'd genuinely value

If you ship batteries or flammables regularly: do the outcomes match what you're told at the counter? Disagreements are exactly what the correction form is for.
If you've built anything with a "deterministic core, fuzzy shell" architecture: how do you keep the fuzzy side from leaking into the core?