Cross-border e-commerce with Shopware 6: setting up a multi-country shop correctly

A wholesaler from North Rhine-Westphalia, three years on Shopware 6, a clean DE shop, solid numbers. At the Q2 kick-off, someone says: "From the autumn, we also want to sell to Austria, Switzerland and the Netherlands. That's just a language switcher, isn't it?"

Six months later: three storefronts live, a fourth in preparation, OSS registration done – and on the Saturday of Black Friday weekend, a logged-in CH customer suddenly sees EUR prices on the .ch domain, because a custom plugin filters out the Varnish cache-key cookie. Several orders with the wrong amounts, three angry phone calls before the coffee break, and on Monday a compliance notice from the external data protection lawyer. Nobody had seen that coming. That's exactly where this article sits: between "just a language switcher" and "a broken cache key".

Shopware 6 makes cross-border technically easier than any other mid-market shop system in the DACH region. But between "works technically" and "sells in four countries, legally sound, search-engine-friendly and without a logistics nightmare" lies a series of architecture and process decisions that you're better off making at the start, not over Black Friday weekend.

Why cross-border now?

In 2026, the EU single market finally works the way it was meant to in 1993: one online shop, many countries, hardly any legal hurdles left at the borders. If you run a clean DE shop, you're sitting on a pipeline to around 120 million inhabitants with strong purchasing power in DACH plus the Netherlands. The question is no longer "whether" but "how, without losing momentum to friction".

The one thing that matters is that cross-border doesn't mean "a translation in the footer". If you sell in Austria, you're selling to Austrian consumers under Austrian case law, with slightly different tax rules and a different payment mix. That applies even more to Switzerland, where you're formally selling to a non-EU country – with its own tax regime, its own logistics reality and a mail-order rule that many DE retailers still don't have on their radar (more on that later).

Architecture decision: multi-sales-channel vs. multi-instance

This is the fundamental question that shapes every decision that follows. Out of the box, Shopware 6 supports multiple sales channels, multiple languages per sales channel and multiple currencies – all in one instance, one database, one admin. The alternative: a separate Shopware installation per country, with its own DB, its own domain and its own deployment.

From our consulting practice: of the last twelve cross-border setups we've supported, eleven are multi-sales-channel. Exactly one is multi-instance – a Swiss subsidiary with its own accounting, its own warehouse and its own management. That split tells you more than any theoretical recommendation: multi-sales-channel is the default, multi-instance the justified exception. Here's why.

Multi-sales-channel: the default

• One product master. Maintenance, imports and ERP integration happen in one place. Image, price and stock updates propagate across all storefronts.
• One customer base per sales channel, one shared platform. Customer groups, B2B logic and newsletter consent can be configured per sales channel, without manual synchronisation.
• One update path. Shopware major updates, security patches, plugin updates: once. Three separate Shopware instances mean three rounds of regression testing.
• Native language and currency support. Translations are maintained in the admin, currency conversion is built in, and tax providers can be assigned per sales channel.

But if AT and DE share the same range while NL has a significantly different one (other brands, other product groups), the shared product master with sales channel filters bloats the listing queries. If the NL team wants its own features that DE mustn't have, you need sales channel conditions scattered across the codebase. And a plugin bug that kills checkout in DE can potentially kill it in AT, CH and NL at the same time. Building that kind of sales channel logic cleanly is Shopware development, not admin configuration.

Multi-instance: the justified exception

This makes sense when the country setups are genuinely fundamentally different or have to be kept separate for regulatory reasons:

• Switzerland as a special case. Your own Swiss GmbH or branch with its own UID, its own accounting and its own stock – that legal separation needs to be mapped cleanly on the technical side too.
• B2B and B2C in parallel. DE primarily B2B, NL primarily B2C? Ranges, pricing logic and checkout flows can differ so much that a second instance means less complexity than a second sales channel.
• Independent release cycles. When country teams are meant to release autonomously, without DE waiting for the NL deployment.

Cost: not "double the infrastructure", but a factor of 1.6 to 1.8, because know-how, the CI/CD setup and the monitoring infrastructure can be shared. Still significantly more expensive.

When a headless approach makes sense

Headless (the Shopware 6 Store API plus your own frontend in Next.js, Nuxt or Vue Storefront) isn't an end in itself for cross-border, but it solves two specific problems elegantly: very different frontend experiences per country without fighting the Twig theme layer, and composable commerce setups in which PIM (e.g. Akeneo), CMS (e.g. Storyblok), search (e.g. Algolia) and personalisation are configured differently per country, while the Shopware backend runs in the background as the commerce engine.

At Bike-Discount, we had exactly this question on the table: is the classic storefront enough, or will the shop go headless in the long run? In that specific case, the trigger wasn't internationalisation itself but a PIM switch and the wish for a much faster product listing. The decision came down to a hybrid path: the storefront stays for most pages, while performance-critical listings and a few brand-specific landing pages run on custom frontends against the Store API. The lesson for the cross-border question: headless is a strategic decision in its own right, with its own costs. Tying it wholesale to "we're going international now" mixes two roadmaps that should have different drivers.

If you "only" want to launch four countries with similar requirements, the classic Twig storefront plus sales channels will, as a rule, get you there faster, more cheaply and with less maintenance surface.

Language and content strategy

Once the architecture is in place, you hit the question that gets underestimated in 80% of cross-border projects: how do we actually translate all this? And "underestimated" means it gets tackled too late, done too cheaply and corrected too late.

Translation quality: machine, manual, hybrid

In 2026, machine translation via DeepL or GPT-4o is much better than it was three years ago – but it's rarely good enough for your conversion levers. There are three realistic tiers:

1. Fully machine-translated for internal fields, category filters, long-tail products with no ranking ambitions, and the initial content of large range imports. Rule of thumb: anything that doesn't need to rank on the first page of Google can start out machine-translated.
2. Machine translation with editing – the most common default. A machine produces the first draft, then native-speaking specialist editors correct the tone, industry terms and SEO keywords. In our projects, that typically takes 5–15 minutes per language and product page instead of 30–45 minutes for a full translation. Time well invested for top products, category copy and service pages.
3. Manual translation by native speakers – mandatory for terms and conditions, withdrawal notices, privacy notices, shipping terms and any content that carries the brand voice. This is where machine translation is the biggest risk, because a legally shifted half-sentence can earn you a formal warning letter (Abmahnung).

Setting hreflang tags correctly: the most common mistakes

If you sell in several languages or countries, the hreflang annotation is how you tell Google which version is meant for which region and language. Get it wrong and Google ranks your DE shop in Austria, your AT shop in Germany, or neither of them.

The most common mistakes from our migration audits:

• Mixing up language and country. hreflang="de-DE" for the Austrian sales channel is wrong – the correct value would be hreflang="de-AT". We had a client whose AT storefront was practically invisible in Vienna for six months, because the sales channel was tagged as de-DE and Google classified it as a duplicate of the DE shop. Recovery: four months after the fix, six weeks of which passed before the first organic clicks came back.
• Missing x-default. Without hreflang="x-default", Google doesn't know what to serve when neither the language nor the region matches.
• Asymmetric references. If the DE page points to the AT page, the AT page has to point back to the DE page. Google generally ignores one-way hreflang references.
• Hreflang pointing to 301 targets. hreflang points to a URL that redirects via 301 – this doesn't work reliably, because Google only follows the annotation if the target URL responds directly.
• Hreflang rendered in JS. Works to a limited extent, but it's fragile – server-side delivery in the <head> or in the XML sitemap is safer.

Shopware sets hreflang in the storefront theme automatically if sales channels with domain mappings are configured cleanly. Even so, don't rely on it blindly – after every go-live, check every language/country combination with Screaming Frog or Sitebulb.

Localisation ≠ translation

A translation says the same thing in another language. Localisation says what works locally.

• Units and sizes. Shoe sizes, clothing sizes, inches vs. centimetres. In NL, bike frames are given in centimetres and tyre sizes in inches – mixed formats that a German mail-order retailer has to map cleanly per country.
• Product names. A brand that sells as "Power-Tool 3000" in DE can have a borderline vulgar ring to it in NL. A check by native speakers is mandatory.
• Visual language. A Black Forest cabin sells in Bavaria. In Amsterdam, it looks exotic in the wrong way. Sales-channel-specific media library assignments plus an image brief per country should be factored in from the start.
• Date, time and currency formatting. 1.234,56 € in DE, € 1.234,56 in NL, CHF 1'234.55 in CH. It sounds like nitpicking, but it's the trust signal international buyers prioritise.
• Service expectations. NL expects fast replies in Dutch. FR expects more detailed product explanations and more extensive service in French. If you launch cross-border without preparing your customer service workflow for the new languages, you're setting yourself up for returns and bad reviews.

Tax and legal requirements by country

This is where it gets dry, but expensive if you ignore it. Above all, this is where it's decided whether the architecture and caching further down the line can operate in a legally compliant way at all – the reason this article opens with a Black Friday cache bug has its roots in exactly this chapter.

The OSS scheme (One-Stop-Shop) for EU distance sales

Since 1 July 2021, the OSS rules have applied to cross-border B2C sales within the EU:

• An EU-wide threshold of €10,000 in net sales per year for all distance sales combined. Up to that point: the German VAT rate. Above it: the VAT rate of the country of destination.
• Instead of registering in every EU country: you register with the Federal Central Tax Office (BZSt) and report all EU sales centrally every quarter.
• OSS doesn't cover everything. Holding stock in another EU country (Amazon FBA in the Netherlands, a fulfilment centre in Belgium) generally still triggers a registration obligation in that country.

From an audit: a client kept invoicing with German VAT until Q3, arguing "we're still below the threshold" – but the €10,000 threshold had already been crossed in April. The quarterly return turned into a back-tax exercise. Avoidable pain: around €23,000 in VAT to pay retrospectively, plus a breach of trust with the tax adviser. If you're expanding, track the OSS trigger properly in your ERP or in dedicated monitoring.

In practical terms for Shopware, this means: tax rates properly maintained per country, correct logic for B2C vs. B2B with a valid VAT ID (reverse charge), and OSS-compliant invoicing and reporting mechanics. Sales-channel-specific tax providers and custom rules engines deliver this technically – but the configuration isn't trivial. Budget half a day with your tax adviser plus a developer. It saves months of clarification later.

Thresholds and VAT rates (as of May 2026)

• DE: 19% standard, 7% reduced
• AT: 20% standard, 10% / 13% reduced (note: from 1 July 2026, the 10% rate on certain basic foodstuffs drops – relevant for food ranges)
• NL: 21% standard, 9% reduced
• FR: 20% standard, 10% / 5.5% / 2.1% reduced
• CH: 8.1% standard (since 1 January 2024), 2.6% reduced, 3.8% special rate – and CH isn't part of OSS, because it's outside the EU

The rates change from time to time. If you hard-code Shopware tax rates and don't review them every year, you risk systematically incorrect invoices.

Switzerland: the mail-order rule nobody talks about

Since 1 January 2019, Switzerland has applied its mail-order rule (Versandhandelsregelung) to foreign online retailers: if you generate more than CHF 100,000 in annual sales from small consignments to Switzerland (small consignments = orders below the import tax exemption limit), you count as a VAT-liable mail-order business from the moment you reach the threshold. You then have to register with the Swiss Federal Tax Administration (ESTV) and charge Swiss VAT directly at checkout on all subsequent orders – including small consignments that were previously imported tax-free.

The import tax exemption limit itself: postal consignments from abroad are exempt from Swiss import tax if the tax due is less than CHF 5. At the standard rate of 8.1%, that corresponds to a goods value (including shipping costs) of around CHF 62; at the reduced rate of 2.6%, it's around CHF 193 (source: BAZG / ESTV).

For your Shopware configuration, this means: once you cross the CHF 100,000 threshold (which happens quickly if you're serious about CH), you need CHF VAT logic in the checkout. You charge Swiss VAT directly at checkout, much like the OSS scheme on the EU side, but as a "registered mail-order business" with the ESTV. This is the setup many DE retailers ignore at their first CH launch, because German law has no equivalent they'd recognise.

New since 1 January 2025 is platform taxation (Art. 20a MWSTG): under certain conditions, electronic platforms that act as intermediaries between seller and buyer themselves become the supplier for Swiss VAT purposes. That's relevant if you sell into Switzerland not only through your own Shopware shop but also via marketplaces. For classic direct sellers using their own shop, the platform rule changes little for now; but if you're planning a multichannel setup with a Swiss component, you should know the rule.

Country-specific legal texts (terms and conditions, right of withdrawal, GDPR)

Every country has its own mandatory information, its own withdrawal notices and its own requirements for the legal notice (Impressum) and privacy notices. AT and DE look similar, but they aren't identical in the detail. NL has its own requirements for "algemene voorwaarden". CH has no statutory right of withdrawal for distance selling in the EU sense – which you as a retailer shouldn't automatically take advantage of, because CH customers have different service expectations.

Invest in country-specific legal texts from a recognised provider (Trusted Shops, eRecht24 with country modules, Händlerbund). The hosting question – the same contract or a separate one per country? – is one to settle with your law firm, not with templates from the internet.

The BFSG also applies to EU customers

A common misconception: the Accessibility Strengthening Act (BFSG, applicable since 28 June 2025) is German law – but it kicks in as soon as you target consumers in Germany. That holds for every sales channel that serves DE customers, regardless of whether AT, CH or NL are served alongside it. If you launch a multi-country Shopware shop, every storefront that serves DE customers has to be set up to comply with the BFSG.

As for the other EU countries: most member states transposed the European Accessibility Act into national law in 2025, although implementation in some countries was still patchy that year. In practice, this means BFSG compliance isn't just a DE-specific side project but the baseline for every EU storefront. If you're rebuilding for cross-border anyway, it's best to build BFSG compliance in straight away.

Localising payment and checkout

Launch in NL with only credit card and PayPal, and you'll lose orders. The same goes for launching in CH without TWINT. Local payment preferences are one of the most underestimated conversion topics.

Rough guidance (market share figures are industry estimates and vary by source and survey):

• DE: Purchase on account (especially for B2B and higher-value orders), PayPal, credit card, Klarna (instalments are growing). SEPA direct debit remains relevant.
• AT: Similar to DE, with a slightly larger share for credit card and EPS bank transfer.
• CH: TWINT is a must – according to the Swiss Payment Monitor 2025, it accounts for well over 60% of mobile transactions. Alongside it: credit card, PostFinance, and purchase on account via POWERPAY (MF Group). Without TWINT, you lose mobile conversions structurally.
• NL: iDEAL leads by a wide margin (iDEAL's own figures ~70%, industry sources mostly 55–65% of online payments), Klarna "Achteraf Betalen", Bancontact for BE crossover.
• BE: Bancontact (industry estimates ~40–50% of online payments), credit card, PayPal, Klarna.
• FR: Credit card (Carte Bancaire – careful: not every credit card integration covers CB!), PayPal, Klarna, Apple Pay/Google Pay growing, alma for instalments.

Wero is the most important payment detail that many people overlook in 2026. The Dutch iDEAL brand is being migrated step by step into the pan-European Wero system (EPI) from January 2026; the full migration is due to be completed by the end of 2027. Bancontact-Payconiq has also been gradually replaced by Wero since 2024. If you're launching in 2026, plan for Wero from the start – not as a nice-to-have, but as a strategic card for the next generation of payments in NL and BE.

Shopware supports these methods via the PSPs' official plugins. Mollie and PayPal cover most of them with a single integration; for TWINT and CH-specific methods, you usually need a Swiss PSP such as Datatrans or Wallee. Important: configure which payment methods are enabled per sales channel carefully – nothing is more embarrassing than a CH customer being offered iDEAL at checkout.

Logistics and fulfilment

Shipping is the other half of the customer experience. There are three models:

1. Shipping from DE to all countries. Works for most ranges: AT 1–2 working days, NL/BE 2–3 working days, FR 3–5 working days. Advantage: one warehouse, one operations team. Disadvantage: longer delivery times than local competitors, higher shipping costs beyond a certain distance, and CH is a case of its own (customs clearance, and the risk of frustrated customers facing customs charges on orders above the import tax exemption limit – see the tax chapter).

2. Shipping from DE with a local carrier partner. DHL to AT/CH, PostNL for NL/BE, Colissimo for FR. Usually the fastest lever: the central warehouse logic stays, and a carrier that's familiar locally is added. Show the carrier per sales channel in the storefront – Dutch customers would rather see PostNL than "DHL via Frankfurt".

3. Local warehouse / fulfilment partner. In our projects, worth looking into from around 5,000 orders a month per region, and typically economical from around 15,000. Watch out: it triggers a VAT registration obligation in the country where the warehouse is (OSS isn't enough for that), plus operational complexity in managing returns. In practice, the trigger is rarely a single threshold. It's a combination of service-level ambitions ("same-day in Amsterdam") and freight costs per order, which beyond a certain point simply work out worse than the fixed costs of a local warehouse.

For CH, a dedicated logistics solution (a local warehouse or fulfilment via Swiss Post, Planzer, Asendia) is the clean way to go beyond a certain volume. Shipping everything from DE with customs clearance per consignment works for pilot phases, but not for serious volumes.

In Shopware, also plan the returns workflows per country: return addresses, possibly several RMA processes, local return labels. Standard Shopware is enough for simple setups; for complex multi-country logistics, you'll usually need an OMS (order management system) or a direct ERP integration as the single source of truth – typically SAP, Microsoft Dynamics or industry-specific systems such as Sage or pixi.

SEO for multi-country shops: domain strategy

If you're seriously serving three or more countries: ccTLDs. Full stop. Everything else is test mode. In over 80% of our cross-border setups that rely on SEO in the medium to long term, we end up with dedicated country-code domains. Here's why, and when the other options still make sense:

ccTLDs: meinshop.at, meinshop.ch, meinshop.nl

The strongest trust signal for local users and for Google. Clear geographic targeting information. The option to separate content clearly for legal and tax purposes. Dutch customers click on .nl significantly more often than on .de/nl.

Disadvantages: SEO authority has to be built up from scratch for each domain – you start from zero in every country. More operational overhead (DNS, SSL certificates, trademark registrations per country). Higher initial investment in local backlinks and brand awareness.

Subfolders: meinshop.de/at/, meinshop.de/ch/, meinshop.de/nl/

All countries benefit from the same domain authority. Fastest SEO impact at launch. Simplest maintenance. One SSL configuration.

A weaker local trust signal, and hard to get across in Switzerland, where .de/ch/ signals to many customers "the Germans just happen to sell to us too" – not "a local CH address". For quick market tests ("does NL work at all?"), subfolders are the pragmatic way in, with the deliberate option of migrating to dedicated ccTLDs later – although for that you'll need a clean 301 migration plan.

Subdomains: at.meinshop.de, ch.meinshop.de, nl.meinshop.de

The weakest option in practice. Google tends to treat subdomains as separate sites, and authority doesn't transfer as well as it does with subfolders. The cognitive clarity for users is weaker than with a ccTLD. Useful in exceptional cases (separate technical setups, a dedicated CDN endpoint per country), but rarely the best SEO path.

In Shopware, all three options are mapped via the sales channel domain configuration. Important: renew the TLS certificates for all domains automatically and keep them monitored – Let's Encrypt works without any problems, but nobody wants to experience an expired SSL configuration on the CH domain during Black Friday.

Varnish cache: where everything comes together

Back to where we started. The CH customer seeing EUR prices on Black Friday Saturday isn't a one-off – it's the typical symptom when a multi-country Shopware setup under load meets caching that doesn't cleanly distinguish between all the dimensions.

Shopware 6 supports HTTP caching via reverse proxies; in most production setups, that's Varnish. In a single-language, single-currency shop, that's simple: one page, one cache entry. As soon as several sales channels, languages and currencies run in the same instance, the cache needs logic that distinguishes these dimensions correctly – otherwise the Austrian customer suddenly gets German prices, or the Dutch customer sees the AT shipping banner.

How the cache key works in the current Shopware VCL

In the official varnish-shopware VCL, the central driver of the cache key today is the sw-cache-hash cookie. It bundles sales channel, language, currency and other context dimensions into a single key, which Varnish includes in the cache key in its vcl_hash subroutine. According to the Shopware documentation, the older sw-currency cookie is marked as deprecated and will be removed in version 6.8.0.0 – if you still run custom VCL adjustments that use sw-currency, switch over before you upgrade.

In addition, sw-states cookies (e.g. for logged-in status) act as a bypass indicator, ESI components pull personalised building blocks into the output after the first render, and API-specific headers such as sw-language-id apply in the Store API, not in storefront caching.

Where it actually goes wrong

We've seen this pattern in several audits: at first glance, a shop runs stably, but under load it suddenly serves the wrong prices or shipping banners, because a custom plugin filters or overwrites the cache-key cookie. That can happen through faulty response header manipulation, through an aggressive cookie banner that swallows the hash cookie on the server side, or through a misconfigured CDN layer in front of Varnish that strips out cookies.

In one B2B project with customer group pricing, a home-built analytics plugin filtered the cache-key cookie out of the response. The symptom: for three weeks, anonymous CH visitors saw EUR list prices from the anonymous cache before they logged in. Over that period, the CH conversion rate fell measurably below the benchmark, and nobody connected it with the plugin – because the plugin ran without a hitch in DE and NL. Only the cache hit rate per sales channel in the monitoring revealed the break.

This isn't just a bug. If a logged-in CH customer sees EUR prices and an order is then placed at the wrong price, you're looking at a breach of the Price Indication Ordinance (PAngV) and a breach of trust that goes beyond the compliance risk.

Pragmatic rules for multi-country caching

• Make sure the sw-cache-hash cookie is passed through all layers (CDN, WAF, Varnish) intact, and that the vcl_hash subroutine includes it in the cache key.
• Logged-in customers (including B2B customers with customer-group-specific prices) bypass the anonymous cache.
• Personalised components (mini basket, wishlist status) are loaded via ESI (Edge Side Includes), not rendered inline in the HTML.
• Pre-warm the cache per sales channel after invalidations – otherwise the first visitors after a price update are the losers who get the slow DB response.
• Monitoring: track the cache hit rate separately for each sales channel. If the NL channel suddenly has a 30% lower hit rate than the DE channel, a plugin is usually to blame – and it's often only noticed weeks later.

For more complex setups with B2B customer group pricing and individual product ranges, there's no way around a custom VCL plus dedicated monitoring (Tideways, Blackfire). That takes effort. But it's exactly this effort that decides whether your cross-border shop feels like a local provider – or like "the German mail-order shop flying a Dutch flag".

What remains: three lessons we take from real cross-border projects

Back to the wholesaler from North Rhine-Westphalia. Six months after the Black Friday cache bug, the shop runs stably in four countries. OSS registration is done, the tax rates per country are properly maintained, the CH sales channel has been charging Swiss VAT correctly since the threshold was triggered, and the cache hit rate per channel is visible in production-grade monitoring. Not because there was yet another fix – but because the architecture decisions made at the start were designed for four countries from the outset, not for "the DE shop, plus three".

Three takeaways from the twelve cross-border setups we've supported over the last three years:

1. Multi-sales-channel is the default, multi-instance the justified exception. If you decide on the architecture first – before the first translation order, before choosing a payment PSP, before the first marketing brief – you don't build twice. If you do it the other way round, you learn that lesson eight weeks behind schedule in the Q3 plan review.

2. Tax and law are architecture drivers, not compliance homework for the last week. OSS, the BFSG, the Swiss mail-order rule, terms and conditions and the right of withdrawal belong in the initial brief, not the final check. What looks trivial at the start turns into an expensive stopgap under time pressure – see the €23,000 in back taxes in the OSS example.

3. Caching and performance are country-specific – and only visible in country-specific metrics. Load tests, cache hit rates and conversion rates have to be run separately for each sales channel. What ran cleanly in the DE shop for weeks can break in the CH sales channel on a Black Friday Saturday – and you'll hear about it from a customer, not from your monitoring.

In 2026, cross-border e-commerce with Shopware 6 is a mature e-commerce solution in DACH and Western Europe – provided the architecture is right from the start, tax and legal issues are built in early, and localisation is treated as a discipline in its own right rather than a translation task. Take these three points seriously and you won't build "the DE shop with a language switcher" but a genuine multi-country pipeline: the foundation of an honest e-commerce strategy and, depending on your market approach, of a viable omnichannel commerce setup.

And if you're looking for the language switcher: there is one. It sits at the top right of the top bar. But it's the least important of the many decisions that really determine whether you make sales in Vienna, Zurich and Amsterdam.