Magento developer in Denmark, for MobilePay and Dankort checkouts

Three real options for the Danish market, each with a different sweet spot:

• DanDomain (Danish-founded, Randers HQ), the “default” for small-to-mid Danish stores under DKK ~15M. Cheap (~DKK 200-800/mo), MobilePay + Dankort + ePay baked in, Danish-language admin. Hits a ceiling around 5k SKUs or any complex B2B logic. No serious headless / API story.
• Shopify Plus, wins early-stage DTC + fashion (Ganni, Mads Nørgaard-style brands often start here). MobilePay via Shopify Payments or Bambora app, Klarna native, fast time-to-market. Limits show up around B2B Net-30, multi-currency Nordic stores, NemHandel B2G, and custom checkout (Shopify locks checkout heavily). Plus license ~$2k/mo.
• Magento 2 / Adobe Commerce, the right call when you need any of: real B2B (CVR + Net-30 + tiered pricing), multi-store Nordic (DK+SE+NO+FI shared catalogue), NemHandel B2G OIOUBL, ERP integration (e-conomic, Uniconta, Microsoft Dynamics NAV/365 BC), or complete checkout control.

Rule of thumb: under DKK 15M revenue + B2C-only → DanDomain or Shopify. Over DKK 15M, any B2B, or any Nordic multi-store → Magento.

MobilePay is on roughly 90% of Danish smartphones, ~4.4M users in a country of 5.9M. Without MobilePay at checkout, you’re losing a meaningful share of Danish shoppers to a competitor who offers it. It’s not optional any more, it’s the Danish default.

MobilePay (now part of Vipps MobilePay AS, jointly owned with Norwegian Vipps) has two relevant Magento integration paths:

• Direct MobilePay Online API, Magento 2 module from MobilePay or community (e.g. Bambora/ePay aggregator). One-time payments + recurring/subscription support. Refunds via API. Tokenisation for one-tap repeat purchase.
• Via aggregator, Bambora/Worldline, ePay, QuickPay, or Adyen all support MobilePay as one rail among many. Easier setup, slightly higher fees, single dashboard.

What we ship on every DK build: MobilePay button on PDP + minicart + checkout, one-tap repeat from saved token, automatic Magento order placement on MobilePay confirm, refund-from-admin wired to the MobilePay refund API, and a fallback to Dankort if MobilePay is unavailable.

A complete Danish Magento checkout typically wires five to seven rails because Danish shoppers split across methods by age + cart value:

• MobilePay, mandatory (90% adoption, covers ~40-55% of transactions on most DK stores).
• Dankort, the Danish national debit card, issued by Nets (now Nexi). Co-badged with Visa on most cards. Lowest interchange fee in Denmark; B2C shoppers expect it. Magento integration via Nets Easy / Nets Checkout, ePay, Bambora, or QuickPay.
• Klarna, for “Pay later in 14/30 days” (invoice) and “Pay in 3” (BNPL). Particularly strong in fashion + furniture, where AOV is high. Official Magento module from Klarna.
• ePay / Bambora, legacy Danish gateway (now Worldline). Aggregates Dankort + Visa + MasterCard + MobilePay. Used by many DanDomain-migrators.
• Apple Pay, growing fast on iPhone-heavy DK demographic. Wired via Stripe, Adyen, or Nets.
• Stripe + PayPal, for non-DK / Nordic / international customers.

We typically configure 5 rails on a B2C store and 2-3 on a B2B store (where Net-30 invoice via Klarna or direct CVR-validated invoice replaces card).

CVR (Centrale Virksomhedsregister) is the Danish national company register, managed by Erhvervsstyrelsen (Danish Business Authority). Every Danish company / ApS / A/S / I/S / sole-trader has an 8-digit CVR number. For B2B Magento we validate it at three points:

• At registration / company create, call Erhvervsstyrelsen’s free cvrapi.dk or official CVR REST endpoint with the entered CVR, auto-fill company name + address + industry code + status. Reject closed (“Ophørt”) companies.
• At checkout for invoice / Net-30, re-validate CVR is still active before extending credit.
• For VAT (Moms) handling on cross-border B2B, combine CVR with VIES validation (the EU-wide VAT-number checker). A Danish CVR has the format DK + 8-digit CVR for VIES purposes. Valid VIES → 0% Moms reverse-charge on intra-EU B2B.

Magento implementation: add cvr + vat_id fields to the customer entity (or B2B company on Adobe Commerce), wire validation via observer + a cached lookup (CVR data is stable, 30-day cache is fine). Show the company name back inline so the user sees the validation worked.

NemHandel is Denmark’s national e-invoicing infrastructure, managed by Erhvervsstyrelsen and built on top of the European PEPPOL network. The Danish format is OIOUBL (Offentlig Information Online Universal Business Language), a UBL XML profile.

When you need it:

• B2G (mandatory), if you sell to any Danish public body (kommune, region, staten, hospital, university), invoices must be OIOUBL via NemHandel. This has been mandatory since 2005 (Denmark was the EU pioneer here).
• B2B (recommended, increasingly expected), many large Danish B2B buyers prefer NemHandel/PEPPOL e-invoices. EU directive 2014/55 + the 2026 ViDA (VAT in the Digital Age) timeline are pushing this further.

Magento integration: on order invoice generation, render an OIOUBL XML matching the OIOUBL 2.1 schema, route it through a NemHandel / PEPPOL access point (e.g. Pagero, Tradeshift, B2Brouter, Continia, or direct via your accounting system if it supports PEPPOL). We wire the sales_invoice save observer to produce + dispatch the OIOUBL XML, then store the NemHandel acknowledgement back on the invoice.

Denmark has the highest standard VAT in the EU, flat 25% Moms on virtually everything. There’s no reduced rate for food, books, or newspapers (unlike most EU countries), just a 0% rate on exports and a few tightly-defined exemptions (financial services, healthcare).

Magento configuration:

1. Create a single Moms 25% tax rate scoped to Denmark (or destination-based for EU shipping).
2. Create a Moms 0% rate for: (a) exports outside the EU, (b) intra-EU B2B sales with valid VIES-validated VAT number (reverse-charge, the buyer accounts for VAT in their country).
3. Assign products to the standard tax class, all goods get 25%.
4. For B2B reverse-charge: customer must have a valid vat_id validated against VIES (CVR for DK customers, equivalent EU VAT number for others). If valid + cross-border + B2B, apply 0% with the legal text “Reverse charge, Customer to account for VAT” on the invoice (also required in Danish: “Omvendt betalingspligt”).
5. For B2C shoppers in other EU countries, apply the destination country’s VAT (OSS / One Stop Shop rules since 2021 if you’re over the €10k threshold).

Storefront shows tax-inclusive prices (mandatory in EU B2C); tax-exclusive on B2B if explicitly opted-in.

Yes, Nordic cross-border is one of the cleanest multi-store use-cases in Magento because the four countries share enough (language families, similar logistics, similar legal frameworks) but diverge enough in payment, currency, and tax that each needs its own store.

• Denmark, DKK + 25% Moms + MobilePay + Dankort + Klarna + NemHandel.
• Sweden, SEK + 25% Moms + Swish + Klarna (Swedish-born) + Bankgiro / Plusgiro for invoice.
• Norway, NOK + 25% MVA + Vipps (Norwegian sister to MobilePay) + Klarna + Visa/Mastercard. Non-EU/EEA, customs declarations matter.
• Finland, EUR + 25.5% ALV (as of Sept 2024) + MobilePay (Finland is a MobilePay market too) + Klarna + Nets/Verifone.

Magento architecture: single backend, 4 websites or stores, shared catalogue with per-country price + tax + payment overrides. Use Magento’s native price-scope per website. For shipping, integrate PostNord (covers all 4 countries, the Nordic default) plus country-specific carriers (GLS DK, Bring NO, Posti FI). For customer-data privacy, all 4 are GDPR but enforced by Datatilsynet (DK), IMY (SE), Datatilsynet (NO), Tietosuojavaltuutettu (FI).

Three big Danish marketplaces with very different audiences, we’ve built feeds for all three:

• DBA.dk, Denmark’s biggest C2C / classifieds marketplace (Schibsted-owned, ~2.5M monthly users). Best for second-hand, refurbished, off-season inventory, and bulk pieces. Product feed via DBA Business / DBA Plus account, XML format spec from DBA Erhverv. We map Magento catalog_product → DBA listings with image / price / condition / category mapping.
• Trendsales, Vinted-style fashion resale, dominant in 18-35 Danish women + men’s fashion (especially second-hand premium). Owned by Adevinta. API-based feed for verified shops + Trendsales Pro account. Particularly relevant for fashion brands wanting to capture the resale loop.
• Saxo.com, Denmark’s biggest online bookstore + a major media / film / music seller, owned by JP/Politikens Hus. Marketplace via Mirakl-style platform; product feed via Saxo Partner API, ISBN-driven for books.

Implementation pattern: scheduled cron exporter (every 30-60 min for price/stock; daily for full catalogue), per-marketplace transformer (different XML / JSON schemas), order-import webhook back into Magento as “DBA / Trendsales / Saxo” sales channel for unified fulfilment.

Datatilsynet is the Danish Data Protection Agency, the GDPR enforcement body in Denmark. While the underlying law is the same GDPR, Datatilsynet has a reputation for being thorough on documentation and has issued some of the EU’s most-cited cookie-consent decisions:

• Cookie consent, Datatilsynet (with Erhvervsstyrelsen on the e-Privacy side) requires granular, per-purpose opt-in. No pre-ticked checkboxes. “Reject all” must be as prominent as “Accept all”. Continued-browsing-equals-consent is not valid. The Danish guidance closely mirrors CNIL (France).
• Documentation requirement, fortegnelse over behandlingsaktiviteter (record of processing activities) is heavily enforced. Stores get audited on this.
• Data-processor agreements (databehandleraftaler), every third-party processor (Magento host, Klaviyo, GA, MobilePay processor) needs a signed DPA. Datatilsynet has issued fines for missing DPAs.
• International transfers, Datatilsynet has been notably strict on Google Analytics + US transfers (2022 guidance discouraged GA + recommended server-side alternatives).

What we ship: a Datatilsynet-aligned cookie banner (Cookiebot is Danish-founded, very common locally; Axeptio + OneTrust also work), full DPA pack, processing-record template, and a GA4 server-side / privacy-friendly analytics alternative if needed.

For a Danish Magento store, three realistic hosting regions, each with a trade-off:

• Hetzner Falkenstein (FSN) or Nuremberg (NBG), cheapest credible EU option. Dedicated / cloud servers from €30-200/mo, ~25ms RTT to København. EU data residency, GDPR-compliant. Best for DKK 2M, 75M stores. Downside: less managed than AWS, you (or we) own the OS-level hardening.
• OVHcloud Frankfurt / Gravelines / Strasbourg, French sovereign cloud, ~30ms to København, GDPR-strong narrative. Good middle ground; many CNIL- / Datatilsynet-conscious clients prefer European-owned cloud. Slightly more expensive than Hetzner, less feature-rich than AWS.
• AWS Stockholm (eu-north-1), the lowest-latency major hyperscaler to Denmark (~10ms to København, geographically Nordic). Full managed services (RDS, ElastiCache, Fastly/CloudFront, EKS). Best for DKK 75M+ stores that need autoscaling for campaign spikes. Higher cost; some Danish clients prefer non-US-owned cloud for political reasons.
• Adobe Commerce Cloud (Frankfurt), if you’re already on Adobe Commerce. Fastly CDN, 24/7 Adobe support, auto-scaling. €25k+/yr.

We benchmark + migrate, the right answer depends on traffic profile, budget, and your stance on US-owned vs European-owned infrastructure.

Every project gets a fixed written quote. Send a short brief on WhatsApp and I reply within one working day with scope, price and timeline. Three packaged tiers for predictable Danish projects:

• Contact me for a quote. Written DK-specific health-check: MobilePay setup, Dankort/Klarna split, Moms 25% configuration, CVR validation, NemHandel B2G readiness, Datatilsynet posture, Core Web Vitals. Turnaround ~5 business days.
• Contact me for a quote. Full Danish Magento build: MobilePay + Dankort + Klarna + ePay + Apple Pay, CVR validation, Moms 25% rebuild, NemHandel OIOUBL pipeline, Datatilsynet-aligned consent, Hyvä or Luma rebuild. Typical timeline 4-8 weeks.
• Custom, quoted. Nordic 4-country cross-border, large B2B with full NemHandel + Net-30, design + furniture bespoke Hyvä (Bolia / HAY-style), ERP integration (e-conomic, Uniconta, Microsoft Dynamics). 6-14 weeks.

Credentials: Adobe-Certified Magento 2 developer, 10+ years on the platform, 200+ stores shipped including Nordic DTC + B2B builds. References from Danish + Swedish + Norwegian clients available on call. Public Upwork + Clutch profiles. We invoice in USD by default; DKK invoices via Wise / Revolut on request.

Three very different Danish Magento profiles, we’ve shipped all three and the scope differs sharply:

• København boutique (DKK 2-15M, B2C, single country), smallest viable Magento setup. Stack: MobilePay + Dankort + Klarna + Apple Pay, Moms 25%, Datatilsynet-aligned consent, Hyvä theme for mobile speed, PostNord + GLS shipping, simple e-conomic / Dinero accounting export. Every project gets a fixed written quote. Send a short brief on WhatsApp and I reply within one working day with scope, price and timeline. Hosted on Hetzner or Cloudways. NemHandel only if any B2G is involved.
• Nordic 4-country retailer (DKK 75M+, multi-country, mixed B2C+B2B), the “serious” tier. Stack: 4 Magento stores (DK+SE+NO+FI), per-country payment (MobilePay / Swish / Vipps / MobilePay-FI), 4 tax models (25% / 25% / 25% / 25.5%), per-country shipping (PostNord + Bring + Posti + GLS), ERP integration (Microsoft Dynamics 365 BC or NAV typical), B2B with CVR + Net-30, full NemHandel + PEPPOL for the Nordic public sector. Fixed quote on request. Hosted on AWS Stockholm or Adobe Commerce Cloud.
• Design + furniture brand (DKK 15-200M, AOV-heavy, brand-led), Bolia / HAY / Carl Hansen / Fritz Hansen profile. Stack: bespoke Hyvä storefront (luxury image-heavy PDP, configurator for upholstery / wood options), Klarna BNPL essential (high AOV needs financing), MobilePay + Dankort, large-format shipping integrations (white-glove furniture delivery via dedicated carriers), B2B trade-account portal for interior designers, made-to-order workflow. Fixed quote on request.

The audit step exists exactly to figure out which of these three profiles you fit (or which hybrid) before quoting.