Magento Developer Romania: 12 questions answered.

Romania’s data protection authority is ANSPDCP (Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal). GDPR applies as-is across the EU, but ANSPDCP has issued specific guidance + enforcement actions:

• Legea nr. 190/2018, the Romanian national law implementing GDPR. Layered on top, adds rules around employee monitoring + biometric data.
• Cookie consent, ANSPDCP follows EDPB guidance: explicit opt-in, no pre-ticked checkboxes, “Reject all” as prominent as “Accept all”. Active enforcement since 2022, fines RON 5,000-100,000 + EUR equivalents for cookie-wall violations.
• Cookie banner copy, must be in Romanian (primary language) + offer alternatives. Cookie purposes broken down (analytics / marketing / functional). Withdrawal as easy as consent.
• Data residency, ANSPDCP prefers EU-region hosting (Frankfurt, Paris, Amsterdam OK). Many RO merchants choose AWS Frankfurt or ZooM Hosting (RO-based).
• DSAR routing, data subject access requests must be answered within 30 days in Romanian.

We ship a Romanian-language cookie banner (Cookiebot or a Magento-native module) with per-purpose granularity, plus a privacy policy template reviewed against ANSPDCP guidance.

Three very different Romanian Magento profiles, each needing a different build:

• Bucharest boutique (fashion / beauty / specialty food), RON 500k, 5M GMV, single-storefront, mobile-heavy (70%+ traffic). Priority: Hyvä speed, Netopia + Klarna BNPL, OLX.ro + Instagram Shop feeds, Romanian-language admin + transactional emails. e-Factura mandatory but volume manageable. Typical Build-tier project.
• Cluj-Napoca IT-niche (B2B SaaS / electronics / hardware), technical buyers, RON 5-50M GMV, multi-currency RON + EUR, B2B Net-30 standard. Priority: CUI + VIES validation, Net-30 terms, Adobe Commerce B2B Companies module, ERP integration (SAP / SeniorERP), tax-exclusive pricing for B2B, multi-store CEE expansion. Often Enterprise-tier.
• eMAG-marketplace-seller-at-scale, RON 25M+ GMV, 10k, 100k SKUs, eMAG is the primary channel (60-90% of volume). Priority: direct eMAG Marketplace API integration (not Channable), FBE stock reservation, sub-minute order acknowledgment (eMAG penalises slow ack), repricing engine, multi-warehouse fulfillment. Always Enterprise-tier.

We scope-match in the audit phase so you don’t overpay for capabilities you don’t need, and don’t under-spec on what eMAG-at-scale demands.

Honest, fixed-price math:

• Audit tier, $499 (~RON 2,300 at parity). ~20 hours at $25/hr. You get a written audit covering Netopia / e-Factura / eMAG / CUI / TVA / Core Web Vitals + fixed-price quotes for every finding. Turnaround: 5-7 business days.
• Build tier, $4,999 (~RON 22,800). ~200 hours at $25/hr. Complete Magento build or Hyvä migration with Netopia + EuPlătesc + PayU + Stripe + Klarna, e-Factura ANAF SPV pipeline, eMAG feed, CUI + VIES validation, ANSPDCP-compliant cookie banner, 14 days post-launch coverage. Turnaround: 4-6 weeks.
• Enterprise, custom. Multi-region RO + HU + BG split, eMAG-marketplace-at-scale, full ERP integration (SAP / Charisma / SeniorERP), Adobe Commerce Cloud. Quoted after audit.

Credentials: Adobe Certified Magento 2 Developer (badge ID verifiable on Adobe). Ten years and 200+ stores shipped. Direct contracts billed in USD via Wise / SWIFT, RON invoice with TVA reverse-charge available for RO-registered SRLs. CUI on request.

CUI (Cod Unic de Înregistrare) is the Romanian company ID, 2-10 digits, optionally prefixed with RO for VAT-registered companies. Two separate validations matter:

• CUI lookup against ANAF, the Romanian tax authority publishes a free API (webservicesp.anaf.ro/PlatitorTvaRest/api/v8/ws/tva) that returns company name, address, TVA registration status, and inactive-trader flag. We call this on Magento customer registration to auto-fill company name + address from CUI, and to reject inactive traders.
• VIES validation, for EU intra-community B2B, the CUI prefixed with RO must validate via VIES (EU-wide VAT validation). Required for 0% TVA reverse-charge on cross-border B2B sales.

Magento integration steps:

1. Add a cui attribute to customer entity (or B2B company if on Adobe Commerce).
2. On registration, call ANAF API, auto-fill name + address, set is_tva_payer flag.
3. Cache ANAF response 30 days; re-validate on address change.
4. For cross-border EU B2B: call VIES, apply 0% TVA reverse-charge if valid + customer outside RO.
5. For RO-domestic B2B: still apply 19% TVA but issue full fiscal factură with CUI.

e-Factura is Romania’s mandatory e-invoicing system, run by ANAF (Agenția Națională de Administrare Fiscală). The platform is SPV (Spațiul Privat Virtual), specifically the e-Factura RO module that accepts UBL 2.1 RO_CIUS XML invoices.

Timeline:

• 1 July 2024, mandatory for all B2B transactions (including B2G which was already required).
• 1 January 2025, extended to B2C transactions > RON 100. Most cross-segment B2C ecommerce sales already in scope.
• Penalties for non-compliance start at RON 5,000 for small companies and RON 10,000 for large ones, plus the invoice is treated as legally invalid.

Magento integration steps:

1. Configure ANAF API credentials in admin (OAuth 2.0 client ID + cert).
2. On invoice_save_after, generate UBL 2.1 RO_CIUS-compliant XML using the customer CUI + line items + TVA breakdown.
3. POST the XML to ANAF SPV via the upload endpoint, ANAF returns a unique ID + status.
4. Poll status (or use webhook): received → processed → validated (or rejected with error code).
5. Store the validated XML against sales_invoice + attach to the order PDF (Factur-X equivalent, PDF/A-3 with embedded XML).
6. For rejection, surface error code in admin + email merchant.

We integrate this on every RO Build tier, tested against the ANAF sandbox before going live.

Correct, Romania uses EET (Eastern European Time, UTC+2), which is 1 hour ahead of CET. Only Romania, Bulgaria, Greece, Cyprus, Finland, and the Baltics use EET in the EU. This actually helps with India overlap:

• India Standard Time = UTC+5:30
• Romania = UTC+2 (EET, winter) or UTC+3 (EEST, summer)
• Overlap window: 12 PM, 4 PM IST = 8:30 AM, 12:30 PM EET (winter), that’s 3-4 working hours of overlap, slightly less than CET (4-6 hours) but enough for daily standups + reviews.

Practical workflow:

• Daily standup at 9 AM EET / 11:30 AM IST, covers your morning, our late morning.
• Mid-day review at 1 PM EET / 3:30 PM IST, covers your lunch hand-off, our afternoon.
• Async via Slack / WhatsApp for the rest.

We’ve worked this way with Bucharest, Cluj-Napoca, and Timișoara clients for years, the 3-4 hour overlap is enough if standups + reviews are calendared.

eMAG.ro is Romania’s dominant marketplace, ~50%+ of all RO ecommerce flows through it (eMAG retail + Marketplace combined). If you sell in Romania at scale, you almost certainly need an eMAG presence either as direct seller (eMAG Marketplace) or fulfilled-by-eMAG (FBE).

Two integration paths from Magento:

• Channable, SaaS feed tool, the most common route. Magento exports product feed (CSV / XML) → Channable normalises + maps attributes → pushes to eMAG via API. Order sync flows back: eMAG → Channable → Magento. Good for < 50k SKUs and standard catalogues. ~€200-800 /mo depending on volume.
• BaseLinker, Polish multi-marketplace tool, strong on CEE marketplaces (eMAG.ro, Allegro.pl, Emag.bg, Emag.hu). Cheaper than Channable for CEE-focused sellers. Includes repricing engine.
• Direct eMAG Marketplace API, for high-volume sellers we build a Magento → eMAG API connector (PHP cron + queue). Full control over pricing rules, FBE stock reservation, order acknowledgment SLAs (eMAG penalises slow ack). This is the Enterprise-tier path.

Attribute mapping is the hard part, eMAG has 200+ category-specific attribute trees, each with mandatory fields. We pre-build the category ↔ attribute set mapping during the audit.

Quick decision matrix for a Romanian merchant:

• Gomag, Romanian-built SaaS, dominant in the RON 500k, 5M segment. Strengths: native eMAG.ro feed, Netopia + EuPlătesc built-in, e-Factura mostly handled, Romanian-language admin. Weaknesses: locked-in templates, hard to customize, no B2B, no headless, monthly fees scale fast above RON 5M GMV.
• Shopify, great early-stage DTC but weak on Romanian rails. Netopia mobilPay needs a third-party app (Payu Shopify is OK), no native e-Factura ANAF integration, eMAG feed via third-party apps. Best if your traffic is largely outside Romania.
• Magento Open Source (Adobe Commerce CE), free + open-source, you own the code. Full control for Netopia + EuPlătesc + e-Factura + eMAG. Right call above RON 5M GMV, B2B, multi-store CEE expansion, or eMAG-marketplace-at-scale.
• Adobe Commerce (paid), only worth it above RON 50M GMV or if you need B2B Companies module, page-builder, or Frankfurt cloud SLAs.

We migrate Gomag → Magento Open Source for ~RON 22,800 ($4,999) on the Build tier.

Three serious players in Romania, each with a Magento module:

• Netopia mobilPay (PlatiOnline), the market leader by transaction volume. Owns ~40% of RO online card-processing. Native Magento 2 module from Netopia, supports recurring, 3DS2, Apple Pay / Google Pay. Best for medium-to-large RO merchants.
• EuPlătesc, second-largest, Romanian PSP, strong on SMEs. Magento 2 module is solid. Slightly lower fees than Netopia for low-volume merchants. Supports recurring + tokenization.
• PayU Romania, international PayU group with strong RO presence (especially via PayU LATAM / EE infrastructure). Magento 2 module excellent, multi-currency RON + EUR, instant settlement, broad PSP rail.
• Stripe, available in Romania since 2021 (Atlas), supports RON. Best if you also sell in other markets and want one rail. RO-issued cards work but Netopia / EuPlătesc routing fees are cheaper for domestic RO transactions.
• Klarna, available in Romania for BNPL since 2023, growing fast in fashion + electronics.

We typically wire Netopia + PayU + Stripe as a triple-rail (Netopia for domestic conversion, PayU for cross-border, Stripe for international). Klarna added if your AOV justifies BNPL.

Yes, depends on the channel type:

• OLX.ro, Romania’s biggest classifieds site, used for both C2C and B2C. Magento → OLX feed via Channable or a custom listing-API connector. OLX is most effective for fashion, electronics, and home goods. Lower commission than eMAG but lower volume too.
• Altex.ro, major Romanian electronics retailer, runs a marketplace where third-party sellers can list. Feed format is XML or CSV via SFTP. Strong for electronics, white goods, IT hardware. Strict mandatory-attribute requirements (EAN, energy class, warranty terms).
• Mobexpert, Romanian furniture chain, also has a marketplace component for furniture + home accessories. CSV feed with category-specific attributes (material, dimensions, assembly required).
• Compari.ro / Price.ro, price-comparison engines, still meaningful traffic source in Romania. Feed format Google Shopping-compatible XML.

Best practice: single Magento feed pipeline (we usually use Channable or a custom feed-export module) with per-channel attribute mapping, per-channel pricing rules (e.g. +5% on Mobexpert to absorb commission), and per-channel stock buffers (don’t list every SKU on every channel).

This is one of the most common Romanian Magento bugs, incorrectly encoded diacritics showing as ? or Ã in product names, customer addresses, transactional emails, and invoice PDFs.

Three layers to get right:

1. MySQL collation, the database must use utf8mb4_unicode_ci (Magento default) or ideally utf8mb4_romanian_ci for the customer-name / product-name columns. utf8 alone (3-byte) breaks on some symbols. Convert with ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4.
2. PHP / Magento config, app/etc/env.php must specify the charset, default_charset in php.ini should be UTF-8, and Magento\Framework\Locale must be configured for ro_RO.
3. Output layer, HTML <meta charset="utf-8">, email templates set as UTF-8 (not Latin-2 or Windows-1250 which some legacy ESPs default to), PDF invoices generated with TCPDF or DOMPDF must explicitly embed a font that includes Romanian glyphs (DejaVu Sans is the safe pick; Helvetica doesn’t cover them).

We audit all 3 layers + run a diacritics-stress-test (sample order with name “&Ș;tefân Țicleanu”) on every RO build before launch.

Romania has the following TVA rates:

• 19%, standard rate (most goods + services).
• 9%, reduced (food, books, restaurant meals, medical, water, hotel accommodation).
• 5%, super-reduced (residential housing under conditions, social housing, some cultural events, school books).

Magento configuration:

1. Create 3 tax classes in Stores → Tax Zones & Rates (TVA-19, TVA-9, TVA-5).
2. Create 3 tax rules per rate, scoped to RO destination.
3. Assign each product’s tax class based on its category (we wire this via a custom category_id → tax_class observer so admins don’t set it per product).
4. For EU B2B intra-community reverse-charge: override to 0% if a valid VIES-validated RO-prefixed CUI (or any EU TVA number) is on the customer.
5. For RO-domestic B2B: still 19% TVA but generate the e-Factura XML with the CUI on the invoice (mandatory).

Tax-inclusive prices on storefront (EU B2C rule); tax-exclusive on B2B if explicitly opted-in. Romania’s TVA threshold for compulsory registration is RON 300,000 turnover.