FeeShield

Framing the Problem

Online international shopping has an invisible cost baked into the checkout. The price you pay at the checkout, the product price plus shipping, isn't the final price. The rest like import duty, VAT, and other charges arrive later, often demanded weeks after purchase, at the door, before the parcel is released.

I've lived this myself. I bought a shirt from Europe for €280 with free shipping, into India. On delivery, I was charged roughly €100 more just to collect it. That is a 36% surprise on a total I thought was final.

Similarly, a UK musician named Simon Potthast ordered a software and hardware package costing £603 from Ableton for his work. A few days later, UPS got in touch wanting £112.55 in import fees before they'd hand the parcel over. He'd already paid in full. Nothing on the website had warned him.

This isn't a rare edge case. The UK is the world's third-largest e-commerce market at £134bn, ahead of Germany at £94bn and France at £60bn, according to ECDB. A recent Whistl's survey of 1,000 UK e-commerce consumers found that 31% of UK online shoppers buy from overseas, a third of them at least once a month, with the habit skewing toward Gen Z and Millennials. That same study found the biggest concerns among cross-border shoppers are long delivery times, difficulty with returns, and unexpected customs fees.

The pain is also growing. Global cross-border e-commerce expands 15-25% a year, faster than domestic e-commerce. As cross-border shopping becomes more normal, more people will hit this same wall.

The loss lands entirely on the buyer, and it is large relative to the purchase. A £300 clothing order shipped to the UK can pick up around £115 in duty, import VAT, and handling fees, close to 38% on top of a price that looked final. There's a reason buyer never sees it coming - the courier collects the charge at the border, not the retailer, so the retailer has no real incentive to show it at checkout, and the courier only appears weeks after you've already paid. The charge is real the whole time. It just stays invisible until it's standing at your doorstep, with no warning.

Source: https://www.whistl.co.uk/insights/beyond-uk-attitudes-cross-border-ecommerce

Idea Explanation

We make that number visible before you pay, not after.

FeeShield is a browser extension that shows the real landed cost of an international purchase, right on the product/checkout page.

This isn't a calculator. Calculators exist, but nobody opens one mid-purchase. That's exactly where feeShield comes into play, it puts the number right where the decision happens. It reads the page, works out where the item is shipping from and where it's going, and shows a breakdown of the extra charges you'd otherwise only find out about later.

UK clothing duty runs 12-16% depending on the exact item, so we calculate against the higher end of that range and label the number clearly as an estimate.

For the MVP, we scope to clothing shipped from the US into the UK. Our live example is Taylor Stitch, a real US menswear brand with no UK handling.

Implementation

Implementation

For the hackathon, the demo runs the real extension on Taylor Stitch's product page. A content script reads the price from the page's metadata and takes the destination from a saved address. Origin and duty-handling status are hardcoded for this demo, Taylor Stitch flagged as US-based with no UK duty handling, and the category is locked to clothing at 16% duty, the cautious end of the UK's 12-16% range, labelled as an estimate.

The calculation:

1. Check the order's total value against the UK's £135 threshold, this applies to the whole consignment.

2. Above it, apply duty, then 20% VAT on goods + shipping + duty, VAT compounds on top of duty, not just the price.

3. Add a flat estimated courier handling fee.

4. Show the breakdown as a popup on the checkout page.

The full product would be built using the same logic, split across three parts so it can scale past one hardcoded retailer.

• Frontend (the extension): does the reading, not the maths. It sends price, destination, and category to a backend instead of calculating locally.

• Backend: runs the threshold check, duty, VAT, and handling fee calculation shown above, but pulls the rates from a database instead of a hardcoded value, so rules can be updated without pushing a new extension version to every user.

• Database: stores what the backend reads from, duty rates by category, the threshold, fee estimates, and a retailer-to-origin mapping that includes whether each retailer already bakes import costs into their price. That flag is what separates a brand like Eton, which handles it, from one like Taylor Stitch, which doesn't.

Knowing a seller's origin reliably is the one piece we can't fully solve yet, there's no universal signal for it on a page. For now it would be a maintained lookup table, a scoped limitation.

Challenges

• UK clothing duty sits between 12-16% depending on the exact item, and getting more precise than that needs a real commodity code. We scoped it to clothing but even within clothing the rate moves around. We could not classify every garment perfectly in a hackathon, so we picked the cautious end of the range, and chose to label the number as an estimate with a breakdown.

• Knowing who already handles the duty, and where a shipment actually dispatches from. Even in cases where the retailer has UK presence, the shipment might be dispatched from outside the country. There's no flag anywhere on a product page that says "this seller has already sorted your import costs." We only found the answer for Taylor Stitch by digging into their help centre and couldn't confirm Eton's dispatch origin with the same certainty. For the MVP, we solved this with a small hardcoded lookup.

• No two retailers structure their pages the same way. Anything built around a fixed page layout broke the moment we tried a different site. Reading price from page metadata instead of a fixed selector made this far more reliable, though it's still something that would need real testing across more retailers before this could scale.

• Monetization model is something we are still evaluating, it isn't locked in yet. Two real options: a freemium model, or Wise's own affiliate program, which already pays £10-£50 per new user who completes their first cross-currency transfer. The fit is natural: when someone's checking out in a foreign currency, their card is usually adding its own FX markup, a second hidden cost sitting right next to the customs one. Flagging it and linking to Wise's real rate solves both with one feature. For the demo, this shows as a static line in the breakdown, not a live integration.

Accomplishments

• We worked well as a team. Tasks were assigned to each member's strength and interest, which let us build a working Chrome extension for the demo, one that reads a live product page, calculates a real landed cost using actual UK duty and VAT rules, and shows it before checkout, on Taylor Stitch's actual site.

• We scoped hard. One country, one category, one retailer, to get the demo ready in time. Given the timeframe, identifying, prioritising, and scoping the MVP was as much a learning as the build itself.

• We found that Wise already has an affiliate program that pays out for the exact currency-conversion moment our extension surfaces, so there's a real path to revenue here, approval aside.

Next Steps

• Replace the hardcoded retailer lookup with real detection, starting with domain, currency, and shipping-policy signals.

• Expand past clothing into other categories, with a real duty-rate lookup instead of a single fixed band.

• Expand past the US-UK lane to other common shopping corridors like China and the EU.

• Apply to Wise's affiliate program and build the FX-markup line into a live integration, replacing the static demo version.