Sell internationally without breaking the market you already have

Most stores do not need a market-sizing report to choose the next country. The evidence is already in the account. Analytics shows which countries send sessions that browse deeply and then stop at the shipping step. The order table holds foreign billing addresses on failed or abandoned payments. Search Console shows impressions from outside the home market on queries you never targeted, and support has the emails asking whether you ship there, written in the language you would need. That is unassisted demand: people who found you despite the store making no effort to be found by them. It beats a forecast, because it has already survived contact with reality. If your analytics are wired to the funnel and not to pageviews, this is an afternoon of work, not a research project.

• Sessions by country that reach the cart but never reach checkout
• Abandoned or declined orders carrying a foreign billing address
• Search Console impressions and queries from outside your home market
• Support messages asking whether you ship there, and in which language

Translation is the visible part and the smallest part. The real job is to stop asking a foreign buyer to do conversion arithmetic in their head or fight a form built for someone else's country. Sizes in the system they use, not a footnote table. Weights and dimensions in their units. Dates in the order they read them. An address form with the fields their country actually has: a state selector that exists or does not, a postal code that may be alphanumeric, a house number that goes before or after the street. Phone input that accepts a local format without throwing a validation error. Baymard Institute's checkout usability research devotes a striking share of its length to address fields, which tells you how often this is where motivated buyers quit. Translate the pages where money is decided first; the blog can wait.

• Sizes, weights and dimensions in local units, not a conversion footnote
• Address forms with the right fields, order and postal code rules
• Phone and date inputs that accept local formats without errors
• Translate the product, delivery, returns and checkout copy before anything else

A translated store that only takes cards is still closed to part of the market. Card dominance is a US habit, not a universal one. iDEAL carries an enormous share of Dutch online payments, Bancontact plays the same role in Belgium, BLIK and Przelewy24 are normal in Poland, Klarna's pay-later invoice is what many German and Nordic shoppers expect (which pay-later provider works in which market), and wallets dominate much of Asia. If your gateway cannot present the local method, that part of the market cannot buy from you at all, no matter how good the translation is. The catch is that these methods are tied to a currency. iDEAL and Bancontact only accept euros and BLIK only Polish zloty, so the WooCommerce Stripe Gateway hides them from a cart priced in dollars. A store that charges only in USD cannot offer them, whatever it enables in the Stripe Dashboard. Payment methods and currency therefore get decided together, and the currency side, from display versus charge to rounding and refunds, is covered in multi-currency pricing on WooCommerce. Keeping the native WooCommerce checkout through a hybrid handoff is what keeps this plugin ecosystem available after a storefront rebuild.

• Netherlands: iDEAL, euros only
• Belgium: Bancontact, euros only
• Poland: BLIK in zloty, plus Przelewy24
• Germany and the Nordics: Klarna pay-later and invoice

What closes or kills an international sale is the total the customer pays, at the door, in their currency. Shipping is the obvious half. Duties and import taxes are the half that arrives later and does the damage. Choose one of two models on purpose. Under DDP (delivered duty paid) you collect duties and import tax at checkout and the parcel arrives with nothing left to pay. Under DDU or DAP the carrier collects on delivery, adding a handling fee and a delay. DDU looks cheaper until you count refused parcels, chargebacks and the support hours spent explaining a bill you did not mention. Either way, duty is calculated from the product's HS code, the six-digit Harmonized System classification customs authorities share, together with its declared value and country of origin. WooCommerce has no HS code field out of the box, so the code lives in your label tool, ShipStation or WooCommerce Shipping, or in a custom product field your developer adds. Customs forms and label tools for the three biggest English-speaking markets are covered in Royal Mail, Canada Post and Australia Post in WooCommerce. Without one, the parcel waits while the carrier asks you for it. Returns are the same trap, because a customer who has to ship an item back across a border at their own cost is a customer who leaves a public complaint instead.

• Quote the delivered total, duties included, before the payment step
• Choose DDP or DDU deliberately and state which one on the product page
• Publish realistic delivery windows that account for customs clearance
• Name a returns address and say plainly who pays return shipping

This is the part where honest scope ends. Registration thresholds, EU VAT and OSS handling, US economic nexus rules that differ state by state, commodity codes for customs declarations, invoice requirements that vary by country — none of that is a development decision. A developer can implement any rule you are given, wire it into WooCommerce tax classes and shipping zones, and make the storefront display it correctly. What a developer cannot do is tell you what you owe. Or where you must register, or when crossing a threshold changes your obligations. A few fixed rules show why the order matters. The EU removed its €22 low-value VAT exemption on 1 July 2021, so every consumer import now carries VAT (EU VAT and OSS in WooCommerce has the per-country setup); for parcels up to €150, the Import One-Stop Shop (IOSS) lets you collect it at checkout and file once, and a US seller has to appoint an EU-based intermediary to use it. The EU's €10,000 distance-selling threshold applies only to sellers established in the EU. US stores that assumed they were under it are not. The UK works on a £135 line: below it, an overseas seller charges UK VAT at the point of sale and registers with HMRC, which UK VAT in WooCommerce walks through. Canada is friendlier to US exporters, with courier shipments under CUSMA free of duty up to C$150 and of tax up to C$40; inside Canada the rate follows the ship-to province (GST/HST by province). Australia is stricter: 10% GST is charged at checkout on almost anything under A$1,000, which the Australian GST guide unpacks. Get an accountant familiar with the target country before the first order, not after the first audit letter. Tax errors are not bugs you patch in a release; they accrue quietly and are settled with interest.

Search is where a second market most often damages the first. Pick one URL strategy, whether subdirectories, subdomains or country domains, and keep it. All three are defensible; mixing them is not. Then implement hreflang properly: every alternate listed on every version, reciprocal, including a self-reference, with an x-default for the fallback. Google treats hreflang as a signal and not a command, so the annotation only helps if the pages genuinely differ. Machine-translating a catalog and publishing it is the expensive mistake for exactly this reason: you create pages that read as low quality in the target language and compete with your originals for the same intent. Localized metadata means titles and descriptions written by someone who knows how that market searches, because the German query is not the English query translated. A multilingual storefront renders those signals server-side, which is where they need to be.

Opening a second country does not require replatforming, though expansion is exactly where teams start believing it does. WordPress and WooCommerce keep everything operational: products and variations, stock, orders, refunds, coupons, tax classes, shipping zones and rates, payment gateways, order emails, and whatever multi-currency or translation plugin you already use as the source of that data. Your team adds a German shipping zone on the same admin screen they use today. What changes is the customer-facing layer. The Next.js storefront resolves locale and currency before the first paint, renders the localized route with the right metadata and hreflang server-side, formats units and addresses per market, and hands the shopper to the native checkout with the cart intact.

The honest recommendation is often to wait. Localization is a standing cost, since every product, policy and campaign now exists twice, and it is a poor way to discover whether anyone abroad wants your product. The cheaper test comes first: switch on international shipping, quote an accurate delivered price in English, and see whether orders appear. If nobody buys, language was not the constraint, and translating the catalog would have bought you a second silent store. Do not start if your home market still has an unsolved problem: a slow storefront, a leaking checkout, or margins that only survive domestic shipping. Fix the paying market before diluting attention. When you do move, move once. One country, launched completely, measured across a full purchase and returns cycle, before the second. Our pricing is structured around that sequencing, which is why there is no multi-market launch package.