Magento Entwickler für österreichische Shops

For the Austrian market, all three are credible options — but they solve different problems:

• Shopify Plus — fast to launch, easy UI. But Austrian payment coverage is thin (no native EPS-Überweisung, RatePay is third-party, RKSV-compliant POS connector requires apps). Best for Austrian DTC fashion or food brands < €5M GMV that don’t need deep ERP integration.
• Shopware 6 — the DACH market leader, headquartered in Schöppingen (DE). Strong native EPS, RatePay, B2B suite. Excellent for AT + DE B2B and mid-market. Smaller global ecosystem than Magento.
• Magento 2 / Adobe Commerce — deepest customisation, biggest extension ecosystem (~3,000 modules), strongest B2B (Adobe Commerce). Best for €5M+ stores, deep ERP (BMD, Sage, SAP) integration, multi-country DACH split, and full RKSV-POS-hybrid setups.

If you’re Wien-only B2C under €1M GMV with no ERP, Shopify is faster. If you’re DACH cross-border B2B or run a Heuriger-Weinhandel with hybrid online + retail (RKSV), Magento or Shopware wins.

EPS-Überweisung (electronic payment standard) is the Austrian instant-bank-transfer standard — used by ~40% of Austrian online buyers. It’s the AT equivalent of giropay (DE) or iDEAL (NL). Without EPS, you lose a huge chunk of Austrian conversions.

Magento integration options:

• Mollie — native EPS support, official Magento 2 module, ~1.9% + €0.25 per transaction. Easiest route.
• Stripe — EPS launched as a payment method in 2021. Official Magento module.
• Klarna — bundled with the Klarna Pay Now flow (Klarna acquired Sofort which routes through EPS).
• Adyen — EPS supported via the unified payment form.
• PSPs with bank-direct routing — Hobex (Austrian), Concardis, Wirecard successor (Worldline / Bambora).

We configure the PSP, add the EPS option (with bank-selection dropdown listing Erste, Bank Austria, Raiffeisen, BAWAG, Sparkasse, Hypo, etc.), and verify with test bank IBANs from the PSP’s sandbox.

The typical Austrian B2C stack covers ~95% of buyers with five rails:

• EPS-Überweisung — ~40% of AT online buyers (above).
• Klarna — the BNPL / Pay-later king in AT. Klarna Pay Now (former Sofort, now folded into Klarna), Klarna Pay-in-3, Klarna Pay-in-30. Huge with Austrian under-40 fashion / electronics buyers.
• RatePay — Otto Group’s BNPL, very strong in AT B2C (open invoice / Rechnungskauf is culturally preferred). Often paired with Klarna for full BNPL coverage.
• PayPal — ~50% of Austrian online buyers use PayPal. Required.
• Apple Pay — strong in AT mobile commerce (~30% of mobile payments).
• Cards (Visa / Mastercard) — via Stripe, Adyen, Mollie, Hobex (Austrian), Worldline. Bambora also common.

We wire all five on a single Magento checkout with method-suppression by cart value (e.g. RatePay only above €30, Klarna BNPL only on certain categories) and B2B-only IBAN-on-invoice (Vorauskasse) for industrial accounts.

Two Austrian B2B identifiers, two validators:

• ATU (Austrian VAT-ID, format ATU + 8 digits — e.g. ATU12345678) — validated against the VIES VAT service (EU-wide) for cross-border B2B, or against the Austrian Finanzonline for domestic-only.
• UID-Nr. (Umsatzsteuer-Identifikationsnummer) — same as ATU, different name. The two are interchangeable.

For Magento B2B we:

1. Add an ATU field to the customer entity (or B2B company on Adobe Commerce).
2. Validate ATU against VIES on registration — rejects invalid / closed companies, auto-fills company name + address from VIES response.
3. Apply 0% USt on B2B intra-EU sales (reverse charge / intra-Community supply) with a valid VIES-validated ATU; 20% USt on B2C + AT→AT B2B; 0% USt on exports outside the EU.
4. Cache VIES validations 30 days, re-validate on any address change. VIES outages are common — we degrade gracefully to manual-approval queue.
5. Per Austrian Finanzamt rules, store the VIES validation timestamp + response on the order for audit purposes (7-year retention).

RKSV (Registrierkassen-Sicherheitsverordnung, 2017) is Austria’s cash-register security law — every cash transaction above €7,500 / year requires a tamper-proof, signed, QR-coded receipt. It was designed for brick-and-mortar but applies to hybrid online + retail businesses too.

When does it apply to your Magento store?

• Pure online B2C / B2B — RKSV does not apply. You’re fine with standard Magento invoices.
• Hybrid online + retail — if you also sell in a physical shop (Heuriger-Weinhandel, Trafik, ski shop, Wien boutique with both shop + online), the retail side needs an RKSV-compliant cash register, and orders that ship from a physical location may need RKSV documentation too.
• Click & collect — if customers pay on pickup at your shop, that’s a cash transaction subject to RKSV.

For Magento we integrate with RKSV-certified POS systems (BMD, Helmut Schmidt, ready2order, foxsy, GASTRO-MIS) — Magento places the order, POS issues the RKSV-compliant receipt with signed QR code, both systems sync via webhooks. We’ve done this for Vienna boutiques, Salzburg restaurants doing online ordering, and Tirol ski-rental shops.

Yes — and you almost certainly should. ~80% of Austrian merchants we work with want at least AT + DE coverage from day one, and many add CH within a year. Magento’s multi-store architecture handles this cleanly:

• Single Magento backend, 3 stores — AT (yourbrand.at), DE (yourbrand.de), CH (yourbrand.ch). Shared catalogue, separate URLs.
• Per-store currency — AT + DE in EUR, CH in CHF (live FX or pinned rate).
• Per-store tax — AT USt 20% (13% / 10% / 0% reduced), DE MwSt 19% (7% reduced), CH MwSt 8.1% (2.6% / 3.8% reduced). Each with separate tax_zone rules.
• Per-store payment methods — AT adds EPS + RatePay, DE adds giropay + RatePay, CH adds TWINT + PostFinance + Reka. PayPal + Apple Pay + cards across all three.
• Per-store shipping — AT: Österreichische Post + DPD AT + GLS AT. DE: DHL + DPD DE + Hermes. CH: Swiss Post + DHL Express.
• Per-store legal pages — AGB + Datenschutz + Impressum per country. DSG-A enforces in AT, BfDI in DE, EDÖB in CH.
• Per-store language — all three share Hochdeutsch (the default), but AT prefers Jänner over Januar, Marille over Aprikose, Topfen over Quark. We add an Austrian-German locale override on top of de_DE so the AT store gets the right vocabulary.

Austria’s top three local marketplaces — combined they reach the vast majority of Austrian online shoppers:

• Willhaben.at — Austria’s eBay + classifieds hybrid, >3M monthly users, market leader. Both C2C and B2C (Willhaben Marketplace + Willhaben Shop). Magento feed via Willhaben’s XML / CSV product feed spec.
• Shöpping.at — Österreichische Post’s marketplace, AT-focused, ~10k merchants. Magento integration via REST API (Shöpping Connect) or XML feed.
• Universal.at — Otto Group’s Austrian marketplace, fashion / lifestyle / home. Feed via the Otto Marketplace Connector.

For Magento we install a marketplace-feed module (M2E Pro, ChannelPilot, or custom) that:

1. Maps Magento catalog_product attributes to each marketplace’s required spec (some demand specific category trees, condition fields, EAN).
2. Pushes price + stock updates every 15–30 min so over-selling is rare.
3. Pulls orders back into Magento as native orders with marketplace channel metadata.
4. Handles per-marketplace fees + commission accounting (Willhaben takes ~5–9%, Shöpping ~7–12%).

Yes — it’s a small touch with outsized trust impact. Austrian-German is the same written language as German but with hundreds of vocabulary differences that locals notice instantly. Common examples that matter in e-commerce:

• Jänner (not Januar) for January — appears in delivery date strings, sale-window banners.
• Feber (occasionally, not Februar) — less common but used in formal contexts.
• Marille (not Aprikose) — apricot. Critical for AT food / Heuriger-Weinhandel / preserve shops.
• Topfen (not Quark) — curd cheese. Critical for AT food / bakery.
• Erdapfel (or Kartoffel; both used) — potato. AT food shops use both.
• Sackerl (not Tüte) — bag. Appears in cart UI strings.
• Schlagobers (not Schlagsahne) — whipped cream.
• Heuer (not dieses Jahr) — this year. Common in promotional copy.
• Servus + Grüß Gott — common greetings, the de_DE “Guten Tag” feels foreign to AT customers.

We add an Austrian-German locale override (custom de_AT translation file) on top of de_DE so storefront strings (cart, checkout, emails, transactional messages) all use AT vocabulary. Combined with .at domain + AT-hosted images + ATU validation, this signals “real Austrian shop” vs “German shop in disguise”.

Austria implements GDPR via the DSG (Datenschutzgesetz) — locally called DSG-A to distinguish from older versions. Enforcement is by the DSB (Datenschutzbehörde), headquartered in Wien.

Concrete differences from a Magento perspective:

• Cookie consent — DSB requires explicit, granular, per-purpose opt-in. No pre-ticked checkboxes. The “Alle ablehnen” (Reject all) button must be as prominent as “Alle akzeptieren”. Aligned with EDSA (European Data Protection Board) guidance but DSB has been more aggressive than some neighbours on enforcement.
• Cookie wall ban — you cannot block content for users who refuse non-essential cookies (DSB position, similar to CNIL).
• Data localisation — DSB prefers EU-region hosting. Adobe Commerce Cloud Frankfurt, ANEXIA (Austrian), A1 Internet (Austrian), Hetzner (Germany) all acceptable. US hosting requires DPF (Data Privacy Framework) compliance.
• Schrems II — Austrian privacy activist Max Schrems triggered the EU-US data-transfer ruling. DSB is highly aware. We default to EU hosting + EU CDN for AT clients.
• NIS2 directive — for critical sectors (energy, transport, finance, health) the Austrian transposition adds incident-reporting + cybersecurity requirements that affect Magento stores serving those sectors.

We ship Cookiebot / Usercentrics / Borlabs (German-native, AT-compliant) wired into Magento’s cookie API, banner copy reviewed against DSB guidance, German + Austrian-German translations.

Depends on volume + data-residency posture + budget. From an Austrian merchant perspective:

• A1 Internet (A1 Telekom Austria) — Austria’s biggest telco-cloud. Best for Austrian data-residency optics + government / regulated sectors. Costs higher than Hetzner, less auto-scaling than AWS. Wien + Salzburg + Linz DCs.
• ANEXIA — Austrian cloud provider (Klagenfurt-HQ), strong on enterprise managed-hosting + GDPR-compliant DCs. Good balance of Austrian-flag + modern tooling.
• Hetzner (Germany, EU) — cheapest reliable EU host. Falkenstein + Nürnberg DCs, < 50ms latency to Wien. Many AT merchants use Hetzner for cost reasons; DSB-compliant.
• Adobe Commerce Cloud (Frankfurt region) — best if you’re on Adobe Commerce. Auto-scaling, Fastly CDN, 24/7 Adobe support, < 30ms latency to Wien. Costs €25k+/yr.
• AWS Frankfurt (eu-central-1) — if you want US-grade tooling but EU data residency. Common for mid-large Austrian stores.
• Hyvä Cloud / Cloudways Frankfurt — managed Magento, €200–800/mo. Good middle ground for €500k–€5M AT stores.

We benchmark + migrate — for most Austrian merchants Hetzner or Cloudways gives the best price/performance; for Wien-based regulated sectors or government suppliers, A1 or ANEXIA wins on data-residency optics.

Two starting price points at our $25/hr standard rate (the hours math is on the pricing card):

• Audit — \$499 (~€459) — ~20h @ \$25/hr. Free 30-min discovery + a paid 20-hour audit covering EPS integration check, ATU validation review, DSG-A cookie banner audit, RKSV compliance check (if hybrid), Core Web Vitals, and a written 14-day fix plan.
• Build — \$4,999 (~€4,599) — ~200h @ \$25/hr. Full DACH multi-store rebuild or Hyvä migration with the Austrian payment stack (EPS + Klarna + RatePay + PayPal + Apple Pay), ATU + USt + RKSV setup, DSG-A consent banner, marketplace feeds (Willhaben / Shöpping).
• Custom — quoted to scope. Multi-region DACH split, ski-seasonal scale-up, full BMD / Sage X3 / SAP ERP integration, RKSV-compliant POS hybrid.

Credentials:

• Adobe Certified Magento 2 Developer — both Front-End and Back-End certs, validated on the Adobe Skill Exchange.
• 8+ years of Magento — 200+ stores shipped across DACH (AT + DE + CH), UK, US, AU, IN, IE, NL, FR.
• Upwork “Top Rated Plus” + 100% Job Success — profile ~016dd1767321100e21.
• WhatsApp: wa.me/918401270422. Email: kishansavaliyakb@gmail.com.

Daily 4 PM CET review on staging is the typical cadence. Timeline is 2–3 weeks for the Build tier, 6–12 weeks for Custom multi-region.

The architecture changes meaningfully across these three Austrian edge cases:

• Wien boutique (one shop, online + click & collect) — single Magento store, AT only, EUR only, USt 20%. EPS + Klarna + PayPal + Apple Pay rails. RKSV-compliant POS integration if click & collect pays at the counter. Cookiebot for DSG-A. Hosting: A1 or Cloudways Frankfurt. Typical scope: 60–120 hours.
• DACH cross-border (AT + DE + CH, all serving B2C + B2B) — three-store Magento (separate URLs or one domain + country selector), shared catalogue, per-country tax (USt 20% / MwSt 19% / MwSt 8.1%), per-country currency (EUR / EUR / CHF), per-country payment (EPS + RatePay / giropay + RatePay / TWINT + PostFinance). VIES validation for cross-border B2B. Mandatory: separate Impressum + AGB + Datenschutz per store. Typical scope: 250–450 hours.
• Tirol ski / outdoor seasonal (Innsbruck / Kitzbühel) — AT or DACH, but with extreme December–March traffic spikes. Architecture must auto-scale: Adobe Commerce Cloud, AWS Frankfurt with auto-scaling groups, or Hetzner with horizontal scaling + Cloudflare. ImageMagick + WebP at scale for product catalogs of skis / jackets / boots. Often paired with rental-extension modules + multi-warehouse inventory (Innsbruck + Kitzbühel + Sölden). Typical scope: 200–500 hours, peak-season ops retainer.

We pick the right architecture in the audit phase — over-engineering a Wien boutique costs you, under-engineering a Tirol ski shop breaks December.