Magento developer for Türkiye stores

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 routing via aydinlatma@yourstore.com.tr typical.
• 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.

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 (all at $25/hr, USD-billed with monthly-refreshed TRY parity):

• Audit — $499 (~20h @ $25/hr) — ~TRY 16,500 parity at quote signing (FX-locked, refreshed monthly if work extends). 5–7 working days. Single-store iyzico fix, KDV reconfig, e-Fatura readiness check.
• Build — $4,999 (~200h @ $25/hr) — ~TRY 165,000 parity. 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.