Edge cases, Budapest boutique vs Debrecen B2B vs eMAG-Hungary marketplace-seller, what changes?
Categories:
Magento Developer Hungary
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?