Common questions about hiring a Magento developer for a Hungarian store — Barion + OTP SimplePay, Online Számla (NAV), ÁFA 27%, Adószám + VIES, NAIH (Hungarian DPA), eMAG.hu / Vatera / Jófogás marketplaces, Hungarian-language admin.
Magento vs Shoprenter vs Shopify Plus for the Hungarian market — which one?
The three real options for a Hungarian merchant evaluating platforms in 2026:
Shoprenter — Hungarian-founded SaaS (Debrecen, 2007). Dominates the HUF 50M–500M Hungarian SMB segment. Cheap (HUF 15–80k/month), pre-wired for Barion + OTP SimplePay + Online Számla (NAV). Limited customisation, no B2B, capped at ~HUF 1B GMV before perf cracks.
Shopify Plus — wins early-stage Hungarian DTC + cross-border CEE brands. Strong on UX and apps. Weak on Online Számla NAV integration (you wire it via 3rd-party apps like Pannon, Számlázz.hu, or Octopus), no native CB scheme, and apps tax compounds quickly past HUF 500M GMV.
Magento 2 (Open Source / Adobe Commerce) — the right answer when you have HUF 500M+ GMV, B2B with Adószám validation, multi-region CEE (HU + RO + SK + HR), or eMAG.hu marketplace at scale. Native control over Online Számla XML, ÁFA 27% / 18% / 5% per-category tax classes, and unlimited customisation of Hungarian-language admin.
If you’re under HUF 200M GMV and don’t need B2B, Shoprenter is faster. Above HUF 500M GMV, or with B2B / eMAG / multi-country needs, Magento is the long-term cost winner.
Was this helpful?
Barion vs OTP SimplePay vs Stripe — which Hungarian payment gateway?
You usually want two of these wired in parallel, not one:
Barion — Hungarian-origin PSP (founded 2014 in Budapest), white-label friendly, strong on installments, e-money license. Native Magento 2 module, supports Mastercard / Visa / Maestro. Best for Hungarian-led brands that want a domestic-feel checkout. Fees ~1.7%–2.4% + HUF 8.
OTP SimplePay — OTP Bank’s gateway. OTP is the largest bank in Hungary (and CEE), so SimplePay carries weight with conservative Hungarian shoppers who recognise the OTP brand. Strong on B2B + invoice-pay. Fees competitive, native Magento module.
Stripe — Hungary-supported since 2018 (Stripe HU). Best for cross-border CEE or international DTC. Apple Pay + Google Pay support out of the box. Fees 1.4% + HUF 8 for EEA cards, 2.9% + HUF 8 for international.
Klarna — native BNPL, growing fast in Hungary 2024+. Pair with one of the above for AOV lift.
K&H / CIB / Raiffeisen direct-bank — legacy bank-direct gateways for large retailers. Lower fees but heavier integration.
Typical Magento HU stack: Barion (or OTP SimplePay) as primary + Stripe for international + Klarna BNPL + PayPal fallback. We wire all four with a unified card form and route by BIN.
Was this helpful?
How do I validate Adószám (Hungarian tax-ID) + VIES for EU B2B in Magento?
Two Hungarian B2B identifiers, two validators:
Adószám — the 11-digit Hungarian tax-ID, format 12345678-1-23 where the first 8 digits are the unique taxpayer ID, the middle digit is the ÁFA status (1–5), and the last 2 digits are the regional code. Validated against NAV’s public taxpayer register (free SOAP / REST API).
EU VAT (HU prefix) — Hungarian EU VAT format HU + 8-digit core. Validated via the VIES VAT service (EU-wide) for cross-border B2B.
Add Adószám + EU VAT fields to the customer entity (or B2B company on Adobe Commerce).
Validate Adószám against NAV’s register on registration — rejects invalid / suspended / closed entities, auto-fills company name + ÁFA status.
Validate EU VAT against VIES for cross-border zero-rated B2B sales (intra-EU reverse charge).
Apply 0% ÁFA on B2B intra-EU sales with a valid VIES-validated EU VAT number; 27% on HU-domestic B2C and HU→HU B2B without VIES; 5%/18% for reduced-rate categories.
Cache validations 30 days, re-validate on any address change.
Was this helpful?
What’s Online Számla (NAV) and how does the 5-minute real-time invoice reporting work?
Online Számla is the Hungarian government’s mandatory real-time invoice reporting system run by NAV (Nemzeti Adó- és Vámhivatal), the Hungarian tax authority. Every invoice issued by a Hungarian taxpayer must be reported to NAV via XML within 5 minutes of issue.
2020 — expanded to all B2B invoices (no threshold).
2021 — expanded to B2C invoices — every invoice now reports to NAV.
How Magento integrates:
Build a Magento invoice (sales_invoice) on order placement or shipment.
Serialize the invoice to Online Számla XML 3.0 schema (Számla 3.0).
POST to NAV’s invoiceService REST endpoint with your tech-user signature + HMAC.
Receive a transaction ID, poll status until DONE or ABORTED.
Store the NAV transaction ID against the Magento invoice for audit.
Non-compliance fine: HUF 500,000 per missing or late invoice. Most merchants route through certified middleware (Számlázz.hu, Pannon, Octopus, Billingo) rather than direct, because the middleware handles XML schema updates + NAV downtime queueing.
Was this helpful?
How do I configure ÁFA 27% / 18% / 5% multi-rate (EU highest VAT) in Magento?
Hungary has the highest standard VAT in the EU at 27%, with two reduced rates:
27% — standard ÁFA (most goods + services).
18% — reduced (accommodation / hotel stays, dairy event services).
5% — super-reduced (bread, dairy, medicine, books, newspapers, internet access, district heating, residential housing under 150 m², restaurant food + non-alcoholic drinks since 2017).
Magento configuration:
Create 3 tax classes in Stores → Tax Zones & Rates (ÁFA-27, ÁFA-18, ÁFA-5).
Create 3 tax rules per rate, scoped to HU (or EU + auto-detect via destination).
Assign each product’s tax class based on its category — we wire this via the category_id → tax_class mapping in a custom CategoryAttribute observer so admins don’t set it per product.
For B2B intra-EU with valid VIES TVA, override to 0% (reverse charge).
Tax-inclusive prices on storefront (mandatory in EU B2C); tax-exclusive on B2B if explicitly opted-in. ÁFA 27% impacts perceived price dramatically — for cross-border shoppers a HUF 12,700 price (HUF 10k + 27% ÁFA) feels heavier than the same EUR equivalent elsewhere, so storefront price-presentation matters.
Was this helpful?
How do I integrate Vatera + Jófogás + eMAG.hu marketplace feeds?
The three Hungarian marketplaces with meaningful e-commerce volume:
eMAG.hu — the dominant marketplace in Hungary. Romanian-origin (Bucharest, 2001), expanded to HU 2013, now > 40% of Hungarian online retail. Full marketplace (3P) + retail (1P). Feed-in via XML / API, pricing rules, category mapping, fulfilment-by-eMAG option. eMAG performance score matters — low scores get delisted.
Vatera — Allegro-owned auction + buy-now site. ~3M active users. Good for collectibles, electronics, fashion overstock. Feed-out via Vatera Connect API; lower margin but steady volume.
Jófogás — classifieds (Schibsted/Adevinta-owned). C2C-heavy but B2C section growing. Less integrated, often manual posting.
Magento integration:
Build a per-marketplace XML feed — product, price, stock, category, images. Cron-refresh hourly.
Map your Magento categories to each marketplace’s taxonomy (eMAG has ~5,000 categories, mapping matters for visibility).
Pull orders back via marketplace API into sales_order with a marketplace_id custom attribute.
Update stock + price across all 3 from a single Magento source-of-truth (with safety margins for slow-syncing marketplaces).
For eMAG specifically: monitor performance score, cancel-rate, and delivery-time metrics — bad scores hurt rankings.
Was this helpful?
How do you handle Hungarian-language admin + Magyar diacritics (ő, ű, á, é) in Magento?
Hungarian (Magyar) is a Uralic language — very different from neighbouring Slavic/Germanic neighbours, with a 44-letter alphabet including the diacritics ő, ű, á, é, í, ó, ú (and the digraphs cs, dz, dzs, gy, ly, ny, sz, ty, zs). Magento support is mostly fine but needs careful setup:
Database collation must be utf8mb4_unicode_ci (or utf8mb4_hungarian_ci for Hungarian-specific sort). Default utf8mb4_general_ci works but sorts ő after z — not what HU shoppers expect.
Hungarian language pack — composer require mageplaza/hungarian-language-pack-magento-2 or community pack. Covers admin + frontend strings (~85% coverage). We patch the missing ~15% for customer-facing UI (checkout, account dashboard, emails).
Postcode validation — Hungarian postcodes are 4 digits (e.g., 1051 Budapest), not 5 like DE/IT/ES. Magento’s default validator accepts this but we add stricter regex.
Address format — HU uses reverse name order (Family-name First-name) and reverse address (Postcode City, Street Number, Floor/Door). We override customer_address formatters.
Hungarian customer-service strings — emails, transactional copy, error messages translated and reviewed by a native HU speaker.
Date / number / currency formatting — Hungarian uses 2026. máj. 18. (with period and trailing dot), 1 234,56 Ft (space thousands, comma decimal, “Ft” suffix).
We deliver a Magento where every diacritic renders correctly, sorts correctly, and emails-correctly to name@kovács.hu domains.
Was this helpful?
eMAG.hu is dominant — how deep should the integration go?
eMAG is roughly 40%+ of Hungarian online retail — if you sell physical goods in HU, you almost certainly need an eMAG channel. Integration depth depends on volume:
Light (under 500 SKUs) — XML feed + manual order fulfilment. Magento exports product/price/stock daily via cron to an eMAG-format XML the eMAG seller dashboard pulls. Orders managed in the eMAG dashboard, shipped from your warehouse, tracking pasted back. Good enough for under HUF 50M GMV on eMAG.
Medium (500–5k SKUs) — full API integration. eMAG Marketplace API (REST, OAuth2) for products, orders, stock, returns, invoices. Real-time inventory sync. Performance score monitoring. Magento ↔ eMAG bidirectional sync via a Magento module (we build custom or use a Mirakl/Channable connector).
Heavy (5k+ SKUs or > HUF 500M GMV on eMAG) — full integration plus: dynamic repricing (auto-match competitors within margin floors), Genius / FBE (Fulfilled By eMAG) integration, eMAG advertising API (sponsored products), returns automation, eMAG-specific Online Számla NAV reporting (eMAG invoices on behalf of you in some cases, but the NAV report still owes to you).
Critical: monitor your eMAG performance score daily — cancel-rate, on-time-delivery, response-time. Below 4.5/5 you get demoted in rankings; below 4.0 you get suspended. Magento dashboard + Slack alerts keep this visible.
NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság) is the Hungarian Data Protection Authority — the body that enforces GDPR in Hungary, on top of 2011. évi CXII. törvény (Hungarian Information Act). NAIH is moderately strict but more pragmatic than France’s CNIL or Germany’s DSK.
Concrete Magento checklist:
Cookie consent — granular, per-purpose opt-in. Pre-ticked checkboxes prohibited. “Reject all” button must be as accessible as “Accept all”.
Hungarian-language banner — legally required to be in Hungarian for HU-targeted sites. Tools: Cookiebot, Axeptio, CookieFirst, or NAIH-vetted local providers.
Privacy policy — in Hungarian, naming NAIH as supervisory authority, including the controller’s Adószám.
DSAR routing — right-to-access, right-to-erasure, right-to-portability per GDPR Art. 15–20. We wire Magento’s native GDPR module (or extend) so HU customers can self-serve in Hungarian.
Breach notification — NAIH expects notification within 72 hours of a breach, in Hungarian, via their portal.
Data localisation — not strictly required for HU, but NAIH prefers EU-region hosting (Cloud99 / Maxer / OVHcloud / AWS Frankfurt all qualify).
NAIH fines have been moderate compared to CNIL (largest ~HUF 100M / ~€250k), but they trigger reputational damage with HU media.
Was this helpful?
Should I host on Cloud99, Maxer, or AWS Frankfurt for Hungarian data residency?
Depends on your volume + DevOps tolerance + data-residency posture:
Cloud99 — Hungarian managed-hosting (Budapest DCs). Strong on Hungarian customer support (HU + EN), familiar with Online Számla / NAV + ÁFA setups. Good for HUF 50M–500M Magento stores. Less auto-scaling than hyperscalers; more hands-on DevOps from us.
Maxer Hosting — another Hungarian provider, popular with Shoprenter migrants. Hungarian-language admin + invoice in HUF. Mid-tier reliability, good price/perf.
AWS Frankfurt (eu-central-1) — not technically Hungarian residency but Frankfurt is the closest hyperscaler region (latency ~10–15ms to Budapest), GDPR-compliant, NAIH-acceptable. Best for HUF 500M+ stores wanting auto-scaling, Cloudfront, RDS, ElastiCache.
Adobe Commerce Cloud (Frankfurt region) — best if you’re already on Adobe Commerce license. Fully managed, 24/7 Adobe support, Fastly CDN. Costs €25k+/yr.
OVHcloud / Hetzner Helsinki — budget EU options, work fine for Hungary if you don’t need ms-level latency.
NAIH doesn’t mandate HU-only hosting, but some conservative Hungarian B2B clients (especially in regulated sectors) prefer HU-soil residency for optics — in that case Cloud99 / Maxer win on the procurement-questionnaire alone.
Was this helpful?
What does a Magento build cost and how long does it take for Hungarian merchants?
Two scenarios published at the canonical $25/hr rate:
$499 Audit — ~20 hours @ $25/hr. HUF parity ~HUF 180,000 at current FX. Deliverable: a written audit of your existing Hungarian Magento store covering Barion / OTP SimplePay setup, Online Számla (NAV) reporting health, ÁFA 27% / 18% / 5% tax-class correctness, NAIH cookie compliance, eMAG.hu feed if applicable, Core Web Vitals, and a 90-day improvement roadmap. Delivered in 3–5 business days.
$4,999 Build — ~200 hours @ $25/hr. HUF parity ~HUF 1,800,000 at current FX. Deliverable: full Magento 2 build or migration from Shoprenter / Shopify / WooCommerce / Magento 1, with Hyvä storefront, Barion + OTP SimplePay + Stripe + Klarna checkout, Online Számla NAV real-time XML integration, ÁFA multi-rate rebuild, Adószám + VIES validation, NAIH cookie banner, eMAG.hu / Vatera / Jófogás feeds, Hungarian admin + storefront with full Magyar diacritics. Delivered in 4–8 weeks.
Custom Enterprise — for multi-region HU+RO+SK+HR, full Online Számla pipeline at high invoice volume, B2B with Adószám + KATA/KIVA awareness, or eMAG-Marketplace seller at scale. Quoted on scope.
Credentials: Adobe-Certified Magento 2 Developer + Hyvä partner-tier, 8 years of CEE Magento builds (HU + RO + PL + CZ + SK), 200+ stores shipped, 5-star Upwork track record. Hungarian Adószám + invoice on request via my Indian Kft-equivalent for VIES-validated cross-border B2B.
Was this helpful?
Edge cases — Budapest boutique vs Debrecen B2B vs eMAG-Hungary marketplace-seller — what changes?
The three Hungarian Magento personas, with what changes per persona:
Budapest boutique (DTC fashion / beauty / wine) — small SKU count, brand-led, mobile-first traffic. Focus: Hyvä Lighthouse 95+, Barion + Klarna + Apple/Google Pay, NAIH cookie banner, Hungarian + English bilingual storefront, eMAG.hu lifestyle category feed. Online Számla NAV via Számlázz.hu middleware. Budget HUF 1.8M–5M.
Debrecen B2B (industrial / parts / wholesale) — large SKU count (10k+), Adószám-validated B2B customers, Net-30 terms, ÁFA reverse-charge for EU intra-Community, KATA/KIVA-aware invoicing. Focus: company-account hierarchies, quote-builder, BoQ uploads, MOQ enforcement. Online Számla NAV with direct XML (high volume justifies the integration). Cloud99 or Maxer hosting for HU-soil B2B optics. Budget HUF 5M–25M.
eMAG-Hungary marketplace-seller (multi-channel retail) — Magento as inventory + order hub, eMAG.hu as primary sales channel (60%+ of revenue), own .hu store as secondary, occasional cross-listing on Vatera. Focus: eMAG Marketplace API depth, real-time stock sync, dynamic repricing, eMAG performance score monitoring, returns automation. Online Számla NAV reporting handles both Magento and eMAG orders (eMAG invoices on the seller’s behalf but the NAV obligation is the seller’s). Budget HUF 5M–15M.
The audit step pins down which persona you are before quoting — the deliverables look different for each.
Was this helpful?
Request a quote
I'll reply within 2-4 hours business with a written quote and timeline.