Magento developer in Turkey

All four are common in Türkiye, but they serve very different stages:

• T-Soft, IdeaSoft, Ticimax, Turkish SaaS platforms, dominant in the ₺1M, ₺50M segment. Fast to launch, monthly fee, native iyzico + Trendyol + e-Fatura modules. Limited customization, if you outgrow their templates or need bespoke B2B / multi-store / ERP integration, you hit a wall.
• Magento 2 / Adobe Commerce, open-source, dominant globally in the ₺50M+ segment. Total control, multi-store / multi-currency / B2B native, every TR PSP (iyzico, PayTR, Param) has a Magento module, marketplace integrations (Trendyol, Hepsiburada) are battle-tested. Higher upfront build cost, but no per-order fees and full ownership.

Rule of thumb: stay on Ticimax / IdeaSoft / T-Soft if you’re < ₺50M revenue and the templates fit. Move to Magento when you need multi-store, custom B2B, headless / Hyvä, or international expansion (KSA / AE / EU).

All three are Magento-supported. The right pick depends on your volume + features needed:

• iyzico, Türkiye’s dominant PSP, acquired by PayU then spun out. Best documentation, most Magento community modules, fastest onboarding (1-3 days). Strong on installment plans (taksit), BIN-based routing, marketplace seller payouts. ~2.45% + ₺0.25 typical.
• PayTR, #2 Turkish PSP, sharper pricing for high-volume merchants, strong recurring/subscription billing, good Magento module. ~2.25% typical.
• Param, #3, good for niche use cases (NFC, QR-code in-store, B2B token-payment). Less Magento community traction.
• Stripe (TR), supports Turkish merchants since 2024 but coverage is limited; CB scheme issues with some BIN ranges. Useful as a USD/EUR-secondary, not as your primary TR rail.

Our default for a new TR build is iyzico primary + PayTR secondary. Both support 3DS2 + installment plans (taksit) natively.

BDDK (Bankacılık Düzenleme ve Denetleme Kurumu, Turkish banking regulator) enforces 3D Secure 2 on every card transaction issued by a Turkish bank. Unlike EU PSD2, there is no “low-risk skip”, no transaction-amount exemption, no merchant-initiated bypass. Every card payment triggers 3DS challenge.

Magento checkout impacts:

• Checkout flow must accommodate a full-screen 3DS challenge redirect / iframe, the bank’s authentication step, not the PSP’s.
• Order placement timing, you cannot create the sales_order until 3DS callback succeeds. Cart should hold via sales_quote with a short reservation TTL.
• iyzico / PayTR / Param all handle the 3DS flow server-side; you just embed their HPP (hosted payment page) or use their JS SDK with the 3DS handshake.
• Mobile checkout, ~70% of TR e-commerce is mobile; ensure the 3DS modal renders inside the Magento mobile theme without breaking the back-stack.
• Abandonment monitoring, 3DS challenge is the #1 checkout drop-off point in TR. Wire analytics to track 3DS-callback success rate and intervene on bank-side timeouts.

We harden the 3DS flow + monitor success rates per acquirer bank as standard on every TR build.

Two Turkish identifiers, two different validators:

• VKN (Vergi Kimlik Numarası), 10-digit corporate tax ID for Turkish A.Ş. / Ltd. Şti. / sole-trader businesses. Used on B2B invoices + e-Fatura. Validated via GİB (Revenue Admin) sorgu API, free public endpoint that returns company name, address, and active status.
• TC Kimlik No, 11-digit citizen ID for Turkish individuals. Required on e-Arşiv (B2C) invoices when the customer is Turkish. Has a deterministic checksum (algorithm published by MERNİS); no API call needed for format validation, but full identity verification requires the MERNİS sorgu API (paid).

Magento integration steps:

1. Add vkn + tc_kimlik_no attributes to the customer entity (or company if you’re on Adobe Commerce B2B).
2. Show VKN field only for B2B (Şirket / Kurumsal), TC Kimlik No only for B2C (Bireysel). Toggle via customer-group.
3. Server-side: validate VKN against GİB sorgu API on registration; checksum-validate TC Kimlik No client-side then server-side.
4. Pass the validated ID into the e-Fatura / e-Arşiv XML generator at order completion.
5. Cache validations 30 days, re-validate on any company-info change.

GİB (Gelir İdaresi Başkanlığı, Turkish Revenue Administration) requires electronic invoicing for almost every merchant above small-trader thresholds. Two distinct formats:

• e-Fatura, B2B / B2G e-invoice (between VKN-holders). Mandatory for any single invoice above 5,000 TL or total daily B2B billing above 30,000 TL to the same customer. Routed through GİB’s closed e-Fatura system (sender + receiver both registered).
• e-Arşiv (e-Arşiv Fatura), B2C e-invoice (to TC Kimlik No-holders or VKN-holders not on e-Fatura). Mandatory for all e-commerce sales since 2020 if your annual revenue exceeds the GİB threshold (currently ₺3M, dropping).

Magento integration: at order completion, generate the appropriate XML format (UBL-TR), sign with the merchant’s e-imza (electronic signature certificate), then submit via a certified PDP (Özel Entegratör), Logo, Mikro, Foriba, Uyumsoft, Pennylane, or similar. The PDP handles GİB routing + archival for 10 years (mandatory retention).

Magento → PDP API integration is what we ship: XML mapping from sales_invoice + customer VKN/TC + line items + KDV per rate.

Türkiye has four standard KDV rates, raised in 2023 (from 18% → 20% etc.):

• 20%, standard rate (most goods + services).
• 10%, reduced (textile + apparel, basic food, books, transport, restaurants).
• 1%, super-reduced (basic groceries, milk/bread/grain, newspapers, agricultural products).
• 0%, exempt (exports, intra-Customs-Union with EU under certain conditions, gold/silver bullion, some education + healthcare).

Magento configuration:

1. Create 4 tax classes in Stores → Tax Zones & Rates (KDV-20, KDV-10, KDV-1, KDV-0).
2. Create 4 tax rules per rate, scoped to TR (or destination-based if exporting).
3. Assign each product’s tax class based on its GTIP code (Turkish customs classification), we wire this via a category_id → tax_class mapping observer.
4. For exports: 0% KDV with proper customs documentation (Gümrük Çıkış Beyannamesi); the export-mode override is detected from shipping country.
5. Tax-inclusive prices on storefront (mandatory in TR retail); KDV breakdown displayed on the e-Fatura / e-Arşiv invoice line items.

Turkish Lira lost 50%+ value against USD/EUR between 2024 and 2026. If you reprice annually (or worse, set TRY prices once and forget), your margins evaporate in weeks. Monthly repricing isn’t optional, it’s mandatory survival.

The Magento automation we ship:

• USD/EUR base-price + monthly FX multiplier, store each SKU’s “true cost” in USD or EUR, then apply a monthly-updated FX rate (TCMB, Turkish Central Bank, daily reference rate is free) to derive TRY storefront price.
• Bulk price rules, Magento Catalog Price Rules with date-bound priority. We schedule a monthly cron that updates the FX multiplier and triggers full reindex.
• Competitor monitoring, scrape Trendyol + Hepsiburada listings for your top-100 SKUs daily, flag when a competitor is 10%+ below you, surface in a Magento dashboard for the merchant to review.
• Markup floor / ceiling, enforce min-margin per category (e.g. never sell apparel below 35% margin even if FX moves) and max-spike caps (don’t shock-price a customer mid-day).
• Marketplace sync, same repriced TRY value pushed to Trendyol / Hepsiburada / n11 / Pttavm feeds within 15 minutes of update.
• Audit log, every price change recorded with old/new/reason/source so accounting can reconcile to KDV filings.

We’ve shipped this exact pipeline on three TR stores in 2025 alone, margin protection visible within the first month.

Türkiye’s marketplace landscape is concentrated:

• Trendyol, dominant #1, ~40M+ active users, 50%+ of Turkish e-commerce GMV. If you’re serious about TR you must be on Trendyol.
• Hepsiburada, #2, premium positioning, stronger on electronics + home.
• n11, #3, broad long-tail, owned by Doğuş Group.
• Pttavm, PTT (post office) owned, growing fast on logistics-bundled categories.
• Amazon.com.tr, launched 2018, smaller in TR than globally but growing.

Magento integration pattern:

1. Use a Magento ↔ Trendyol module (Magedelight, Webkul, or custom) wired to Trendyol’s Partner API. Same for Hepsiburada (Partner API), n11 (Pro Seller API), Pttavm.
2. Push products + variants + stock + prices from Magento → marketplace. Pull orders back into Magento for unified fulfillment.
3. Per-marketplace category mapping, Magento category → Trendyol category (their taxonomy is huge, ~3,000 categories). One-time mapping plus delta-update.
4. Stock guard, avoid overselling by holding a buffer (10-15% of physical stock not exposed to marketplaces).
5. Order webhook, marketplace order → Magento order with marketplace-prefixed increment ID, fulfillment routed through your usual carrier (Aras, Yurtiçi, MNG, PTT).
6. Repricing sync, monthly TRY repricing (see above) pushes to all marketplace listings within 15 minutes.

For Trendyol Power Seller / Hepsiburada Premium status, we wire the additional commission tier + featured-placement APIs.

KVKK (Kişisel Verilerin Korunması Kanunu, Law No. 6698-2016) is Türkiye’s personal-data protection law. It’s similar to GDPR but not identical, enforced by the KVKK Kurumu (KVKK Authority):

• VERBİS registration, if you process personal data above the threshold, you must register as a Data Controller in VERBİS (Veri Sorumluları Sicili). This is not a GDPR equivalent, even if you’re GDPR-compliant for EU customers, you still need separate VERBİS registration to operate in Türkiye.
• Explicit consent (Açık Rıza), KVKK Art. 5 requires explicit, freely-given, informed consent for processing, similar to GDPR but the bar is interpreted slightly differently.
• Cross-border data transfer, KVKK is more restrictive than GDPR. Sending TR customer data outside Türkiye requires explicit consent or a KVKK Authority approval of the destination country’s adequacy.
• Data-subject rights, right to access, rectification, erasure, similar to GDPR Art. 15-17. DSAR requests are routed through the store's published privacy-request channel.
• Aydınlatma Metni (Information Notice), you must display an explicit KVKK information notice before collecting any data, not the same wording as a GDPR privacy policy.

Magento integration: KVKK-compliant cookie consent banner (Cookiebot or custom), Aydınlatma Metni on every form, DSAR endpoint, VERBİS-compliant data inventory.

For help implementing this on your store, message me on WhatsApp (https://wa.me/918401270422).

Real, daily, 2.5 hours of working overlap:

• India Standard Time = UTC+5:30
• Türkiye Time (TRT) = UTC+3 (no DST since 2016, permanent summer time)
• Overlap window: 12 PM, 2:30 PM IST = 9:30 AM, 12 PM TRT

That covers your morning standup, mid-morning review, and lunch hand-off. Daily 11 AM TRT review on staging is the typical cadence. The overlap is tighter than France (4-6h) but wider than UAE (3h) or US East Coast (1-2h end-of-day). If you need late-day overlap (post-3 PM TRT) we flex 2-3 days/week. Slack / WhatsApp async covers the rest. We’ve worked this way with Istanbul, Ankara, Izmir, and Bursa clients for years.

Standard tiers (USD-billed with monthly-refreshed TRY parity):

• Pricing is a fixed written quote for your scope. Send the details on WhatsApp and I reply within one working day. 5-7 working days. Single-store iyzico fix, KDV reconfig, e-Fatura readiness check.
• Fixed quote on request. 10-14 working days. Full Hyvä migration, iyzico + 3DS2 build, e-Fatura pipeline, Trendyol + Hepsiburada feeds.
• Custom Enterprise, quoted, 4-8 weeks. Trendyol-scale marketplace seller, B2B textile/carpet exporter, multi-region TR + KSA + AE.

Credentials to check on any TR Magento freelancer / agency:

• Adobe Commerce Certified Developer, check the public Adobe Credential Manager (we’re listed).
• Hyvä Themes partner, matters if you want a fast frontend (which you do for TR mobile traffic).
• iyzico / PayTR partner experience, ask for 2-3 prior TR client references and check their checkout flows.
• e-Fatura PDP integration experience, ask which PDPs (Foriba / Logo / Mikro / Uyumsoft) they’ve shipped against.
• Trendyol / Hepsiburada feed shipped, ask for a screenshot of a live merchant’s Magento → Trendyol sync.

FX volatility means we re-FX-lock the quote monthly if the project extends past 30 days. TRY parity is informational, USD is the billed currency.

Three very different Magento builds:

• Istanbul textile exporter, B2B-heavy, multi-currency (USD/EUR primary, TRY domestic), FOB/CIF Incoterms, wholesale tier pricing (5/10/50/100-unit breaks), VKN-validated B2B-only accounts, e-Fatura via PDP, KDV 0% on exports with Gümrük Çıkış Beyannamesi, multi-language (TR + EN + AR for Gulf buyers), shipping integration with Aras Kargo / DHL / Aramex. Hyvä Checkout for fast PDP. Catalog: ~500-5,000 SKUs.
• Ankara local-only B2B, B2B industrial / construction / spare parts. Local fulfillment via Yurtiçi / MNG, no marketplace integration (sales are direct + tender-driven), heavy emphasis on VKN-validated company accounts, customer-specific catalogues + Net-30/60 payment terms, ERP integration (Logo / Mikro / Netsis) for inventory + invoicing, KDV 20% standard, e-Fatura mandatory. Catalog: 5,000-50,000 SKUs.
• Trendyol-scale marketplace seller, B2C-only, 80%+ of orders come from Trendyol / Hepsiburada / n11, Magento storefront is a small fraction (10-20%) but used for brand-building + repeat customers. Stock-availability and pricing automation is critical, one outdated SKU mis-sold on Trendyol is a 1-star review and a delisting. Repricing automation + competitor monitoring weighs more than checkout UX. e-Arşiv mandatory for every B2C order. Catalog: 1,000-100,000 SKUs.

We scope the audit to your specific shape on day 1, same Magento, very different architecture and module choices.