Common questions about hiring a Magento developer for a Dutch store — iDEAL, Mollie, Adyen, AVG, BTW, PostNL.
How do I integrate iDEAL (and the new iDEAL 2.0) with Magento?
iDEAL handles 70%+ of all Dutch online payments — if your store doesn’t support it, you’re losing two-thirds of your potential checkouts. The standard route is via Mollie or Adyen (both Dutch-founded), each of which exposes iDEAL as a payment method out of the box. We install and configure the official Mollie or Adyen Magento modules, wire them to your bank-acquirer of choice, and turn on iDEAL 2.0 (formerly iDEAL+) which is rolling out across 2024 – 2025 with one-tap mobile checkout, recurring SEPA mandates, and tokenisation. Payment-method ordering, bank-list rendering and PSD2 SCA hand-off are all configured at the store-view level so iDEAL appears first for NL customers and elsewhere for BE / DE.
Was this helpful?
Mollie vs Adyen — which is better for my Dutch Magento store?
Both are excellent and both are Dutch-founded, but they target different sizes of merchant. Mollie is the simpler choice for SMBs — flat per-transaction pricing (~€0.29 + ~1.8% for iDEAL), 2-day onboarding, no monthly fee, and a Magento module that’s a 5-minute install. It supports iDEAL, Bancontact, Klarna, Apple Pay, SEPA, credit cards. Adyen is the better choice for high-volume / enterprise stores — interchange-plus pricing (cheaper at scale), unified global processing, advanced fraud (RevenueProtect), and a much more powerful back-office (financial reports, settlement timing, dispute automation). Rule of thumb: under €5M revenue Mollie wins on simplicity, over €5M Adyen wins on cost. We’ve shipped both and can recommend based on your transaction volume + currencies + cross-border footprint.
Was this helpful?
How do I configure AVG-compliant cookie consent in Magento?
AVG is the Dutch implementation of GDPR, and the Dutch Telecommunicatiewet (Telecomwet) + ePrivacy rules require explicit opt-in for any non-essential cookie — no “by using this site you accept” banners, no pre-ticked boxes. We install Cookiebot, OneTrust, or a Magento-native consent manager (Mageplaza GDPR / Amasty), configure it to: (a) block GTM, Hotjar, marketing pixels and chat widgets before consent, (b) categorise cookies as essential / functional / analytics / marketing, (c) honour withdrawal of consent without re-asking immediately, and (d) log consent records (timestamp, IP, scope) for the 24-month Autoriteit Persoonsgegevens (AP) audit window. We also wire DSAR request flows to your support inbox.
Was this helpful?
What’s the BTW (VAT) setup for a Dutch Magento store?
Three rates: 21% standard (most goods), 9% reduced (food, books, medicines, public transport, hairdressers, etc.), and 0% (intra-EU B2B with valid BTW-nummer + intra-community supply). In Magento we configure: (1) tax classes per product (21% default, 9% for food/books, 0% for B2B EU), (2) tax rates per customer-tax-class (B2C BTW-included, B2B BTW-excluded with reverse-charge note), (3) BTW-nummer validation at customer registration via VIES (the EU’s central VAT validation service), (4) invoice templates that show BTW separately with the correct percentage and your BTW-id + KvK-id, and (5) the "BTW verlegd" reverse-charge text on cross-border invoices.
Was this helpful?
How does the KOR small-seller scheme work in Magento?
The Kleineondernemersregeling (KOR) exempts Dutch businesses with under €20,000 in annual NL revenue from charging BTW. If you opt in, you don’t charge BTW, can’t reclaim input BTW, and can’t show BTW on invoices — instead invoices must say "vrijgesteld van BTW vanwege de kleineondernemersregeling". In Magento this means: (a) tax class “None” on all products with a 0% rate, (b) invoice template that omits BTW lines and shows the KOR-exemption note, (c) checkout that doesn’t display "incl. BTW" anywhere. If you cross €20,000 mid-year you must register for BTW immediately and start charging from that day — we add a Magento dashboard widget that warns when revenue approaches €18k.
Was this helpful?
What’s PEPPOL e-invoicing and do I need it?
PEPPOL (Pan-European Public Procurement OnLine) is the EU standard for structured e-invoices. In the Netherlands it’s mandatory if you sell to government suppliers (central government has required it since 2017, municipalities since 2019) and increasingly expected for B2B. It’s not yet mandatory for private B2B, but the EU’s VAT in the Digital Age (ViDA) reform will roll it out across 2028–2030. We integrate PEPPOL via Magento extensions (Storm, AvaTax, or custom via the official PEPPOL Access Point providers like Tradeshift, Storecove or BasWare). Output is a structured UBL 2.1 XML invoice routed via the PEPPOL network — not a PDF. If you sell to ministries or larger municipalities you need this; if you’re pure DTC you can wait.
Was this helpful?
How do I validate BTW-nummer for B2B customers?
For intra-EU B2B sales you can apply the 0% reverse-charge BTW rate only if the buyer has a valid BTW-nummer registered in the EU’s VIES database (VAT Information Exchange System). In Magento we add a custom customer attribute btw_nummer (or vat_id if you’re using Magento’s built-in field) to the registration form, validate it real-time against the VIES SOAP API on submission, and gate the B2B-only customer group + 0% tax rate behind a successful validation. We also store the validation timestamp for audit and re-validate every 90 days (since BTW-nummers can be revoked). For non-EU B2B (UK post-Brexit, US, etc.) we use the relevant local validation API or fall back to manual approval.
Was this helpful?
How do I integrate PostNL (delivery, pickup-point, return)?
PostNL dominates Dutch parcel delivery and Dutch shoppers expect three things: (1) a delivery date picker at checkout (PostNL guarantees next-day for 99% of NL addresses), (2) pickup-point selection (~3,500 PostNL points in NL — Dutch shoppers love these for "delivery while at work"), and (3) a self-service return label. We use the official PostNL Magento extension or one of the popular alternatives (Tig PostNL is the de-facto choice). It wires to your PostNL business contract and adds: address-validation against the Dutch postcode + house-number database, dimensional-weight quoting, label generation directly inside the order admin, COD support if needed, and webhook-driven shipment-tracking sync back into Magento. We also integrate DHL Parcel NL as a fallback / multi-carrier option and Pakketdienst Quick for B2B same-day Randstad delivery.
Was this helpful?
Can I run a single Magento store for NL + BE + DE?
Yes — this is one of Magento’s strongest features. We typically architect it as 1 website → 3 stores (NL, BE, DE) → 3 store-views with a shared catalogue and shared customers, but per-store BTW rates, currencies (all EUR but separate tax-config), languages (Nederlands / Frans-Nederlands / Deutsch), payment methods (iDEAL for NL / Bancontact for BE / Klarna + Sofort for DE), and shipping carriers (PostNL for NL / bpost for BE / DHL for DE). Hreflang per store-view, separate sitemaps, separate Google Search Console properties. Same Magento backend, ~30% lower TCO than running three separate Magento installations.
Was this helpful?
Should I use Adobe Commerce Cloud Frankfurt or TransIP / Leaseweb?
Depends on revenue + ops maturity. Adobe Commerce Cloud (Frankfurt region) is the right pick if you’re on Adobe Commerce (paid Magento), have >€5M revenue, want managed Fastly + New Relic + 24/7 Adobe support, and don’t want a sysadmin on staff — ~€30k/yr+. TransIP (Dutch, founded in 2003 in Leiden) is excellent for SMBs — cheap (~€30/mo VPS), local NOC, native Dutch support, Magento-optimised hosting plans starting around €100/mo. Leaseweb (also Dutch, Haarlem) is the choice for high-traffic / B2B where you need bare-metal or hybrid — ~€200/mo+ for proper Magento dedicated. Combell and Hostnet are alternatives. We can audit your current hosting + recommend per workload.
Was this helpful?
Should I migrate to Hyvä for my Dutch DTC store?
Almost certainly yes. Dutch shoppers have very low patience for slow checkout (consistently in EU surveys), and Hyvä cuts page-load to < 1.5s and Lighthouse to 95+. Combined with iDEAL (which is already a 2-tap flow) the result is a checkout that’s objectively faster than most native apps. Stores typically see 8 – 25% conversion lift in the 90 days post-migration. Hyvä supports iDEAL via Mollie / Adyen / Multisafepay out of the box, ships with native Hyvä Checkout, and integrates with PostNL pickup-point modules. Project takes 4 – 6 weeks for a typical NL DTC store and pays back in 2 – 4 months from conversion lift alone.
Was this helpful?
What time-zone overlap can I expect from India?
India is UTC+5:30 and the Netherlands is UTC+1 (CET) or UTC+2 (CEST in summer). The reliable daily working overlap is 4 – 6 hours — specifically 12 PM – 6 PM IST = 7:30 AM – 1:30 PM CET. We schedule status calls + design reviews in your morning (your espresso, our afternoon) and ship the day’s work to staging by ~5 PM CET. Loom recap + written EOD note follows so you wake up with the full picture. For urgent production incidents we’re reachable on WhatsApp / Slack until ~9 PM CET. No "we’ll get back to you tomorrow" surprises — you have real working overlap, not just async hand-offs.
Was this helpful?
Request a quote
I'll reply within 2-4 hours business with a written quote and timeline.