2026'da E-Ticaret Entegrasyonu — Hızlı Okuma
Modern e-ticaret operasyonu artık "bir web sitesi artı birkaç pazaryeri" değildir. 2026'da orta segment bir satıcı tipik olarak 3-10 pazaryeri, 1-2 ERP, bir muhasebe / e-fatura gateway'i, bir WMS, 4-8 kargo firması, 2-4 ödeme altyapısı, CRM, BI ve reklam teknolojisi bağlar. Entegrasyon mimarisi olmadan bunların her biri insanlar tarafından mutabık kılınması gereken birer silodur. Modern entegrasyon, verileri kanonik bir şemaya normalleştirmek ve olayları her tüketiciye yayınlamak için API öncelikli, olay tabanlı, idempotent bir merkez — genellikle bir iPaaS veya Zunapro gibi birleşik bir ticaret platformu — kullanır. Bu rehber, bunu 2026'da doğru yapmak için gereken on katmanı kapsıyor.
1. 2026 Entegrasyon Mimarisine Genel Bakış
Tek tek katmanlara yakınlaşmadan önce bütün resmi görmek faydalıdır. Modern bir e-ticaret entegrasyon mimarisi, noktadan noktaya spagetti yerine hub-and-spoke (yıldız) yapıdadır. Her sistem hub ile konuşur; hub her sistemle konuşur. Yeni bir pazaryeri eklemek altı aylık bir proje değil, bir konfigürasyon görevi haline gelir.
Pazaryerleri — Satış Katmanı
Trendyol, Hepsiburada, Amazon, eBay, Etsy, Allegro, Çiçeksepeti, N11 · REST + GraphQL API'leri · sipariş olayları için webhook'lar
ERP — Ana Veri Katmanı
SAP S/4HANA, Microsoft Dynamics 365, Netsuite, Odoo, Logo, Mikro, Nebim · satın alma, envanter, finans ana verisi
Muhasebe + e-Fatura — Uyum Katmanı
e-Fatura/e-Arşiv (GIB), KSeF (PL), SDI (IT), PPF (FR) · yapılı XML faturalar · aylık vergi raporlama
Lojistik — Sevkiyat Katmanı
Aras Kargo, Yurtiçi Kargo, MNG, PTT, UPS, DHL, FedEx, Trendyol Express, HepsiJet · AWB üretimi, takip, iadeler
Ödemeler — Para Katmanı
iyzico, PayTR, Stripe, Adyen, Mollie, PayU · 3DS2 doğrulama, yakalama, iade, settlement mutabakatı
CRM, BI, Reklam — İçgörü Katmanı
Salesforce, HubSpot, Power BI, Tableau, GA4, Meta Ads, Google Ads · müşteri 360, atıf, LTV
Tüm sistemleri tek panelden bağlamaya hazır mısınız?
Zunapro, entegrasyon öncelikli bir ticaret platformudur: pazaryerleri, ERP'ler, e-fatura gateway'leri, kargo firmaları ve ödeme altyapıları için 60+ hazır konnektör. Yeni bir kanalı aylar yerine dakikalar içinde ekleyin.
2. Pazaryeri Entegrasyon Katmanı — API'ler, Webhook'lar ve Rate Limit'ler
Pazaryeri Entegrasyonu Neden Göründüğünden Daha Zor
Dışarıdan bakıldığında, "Trendyol'da bir ürün listele" tek bir API çağrısı gibi görünür. Gerçekte, her pazaryeri kendine özgü bir kimlik doğrulama (HMAC, OAuth 2.0, API key + secret, JWT), kendine özgü ürün şemaları (Trendyol categoryId, Hepsiburada productId, Amazon ASIN, eBay itemId), kendine özgü stok ve fiyat endpoint'leri, kendine özgü sipariş durum makineleri ve — en önemlisi — kendine özgü rate limit'ler ile gelir. Trendyol, çoğu endpoint'te tedarikçi başına yaklaşık 200 istek/dakika uygular; Amazon Selling Partner API kaynak başına karmaşık bir token bucket uygular; eBay'in Trading API'si varsayılan olarak 5.000 çağrı/gün kapağına sahiptir. Bu limitlerden herhangi birine çarptığınızda entegrasyonunuz sessizleşir.
Kanonik Pazaryeri Nesne Modeli
Her entegrasyon hub'ının ilk işi, her pazaryerinin kendine özgü şemasını tek bir kanonik modele çevirmektir. Zunapro'da bu modelin altı üst seviye varlığı vardır:
- Product — başlık, açıklama, marka, boyutlar, ağırlık, görseller, kategori ile ana SKU
- Listing — bir ürünün kanala özgü eşleştirmesi (Trendyol barkod, Amazon ASIN, eBay itemId)
- Stock — depo başına miktar, opsiyonel kanal düzeyinde rezervasyonlar
- Price — taban fiyat, kanala özgü override, para birimi, geçerli-başlangıç / geçerli-bitiş
- Order — başlık + satırlar + müşteri + kargo + ödeme, pazaryerine özgü ek alanlarla
- Return / Claim — kanonik bir taksonomiye eşlenen sebep kodlarıyla RMA iş akışı
Webhook vs Polling — Doğru Karışım
Her pazaryeri, sipariş olaylarını hub'ınıza iletmek için iki yol sunar: webhook (push) ve polling (pull). Webhook'lar dramatik ölçüde daha hızlıdır — pazaryeri siparişinden entegrasyon hub'ına tipik medyan gecikme 150-500 ms — ve polling'den 2-3 kat daha az API bütçesi tüketir. Ancak endpoint'iniz çöktüğünde, ağ aksaklıkları POST'u düşürdüğünde veya pazaryerinin kuyruğu sıcak çalıştığında webhook'lar sessizce başarısız olur. 2026'nın en iyi pratiği:
- Düşük gecikmeli olaylar için birincil yol olarak webhook'lar (order.created, payment.captured)
- Kısa aralıklı polling (1-5 dk) kaçırılan webhook'lar için güvenlik ağı olarak
- Uzun aralıklı mutabakat (12-24 sa) yavaş kaymayı yakalamak için tam pazaryeri anlık görüntüsüne karşı
- Idempotency anahtarları her endpoint'te, böylece mükerrer olaylar asla mükerrer sipariş üretmez
2026 Pazaryeri API Olgunluk Seviyeleri
Rate-limit ipucu: Her pazaryeri istemcisinin önüne bir token-bucket scheduler kurun. Her pazaryeri kendi bucket'ını alır; ani operasyonlar başarısız olmak yerine kuyruğa girer. Zunapro'nun outbound kuyruğu, çağrıları yeniden denemeden önce jitter'lı exponential backoff ile 60 saniyeye kadar tutar. Zunapro'nun 10 pazaryerini tek kuyrukta nasıl orkestre ettiğini görün →
3. ERP Entegrasyonu — Ana Veri Omurgası
Gerçek ERP'de Yaşar
ERP — SAP S/4HANA, Microsoft Dynamics 365, Netsuite, Odoo, Logo, Mikro, Nebim, IFS — ürün ana verisi, tedarikçi ilişkileri, satınalma siparişleri, GL kayıtları, maliyetler ve depo bazlı envanter için tek gerçek kaynağıdır. ERP ile çelişen her şey, tanım gereği yanlıştır. Bu nedenle pazaryeri entegrasyonu ERP'nin etrafından değil, içinden akmalıdır. İki kanonik akış:
- Giden (ERP → pazaryerleri): ürün ana verisi, depo başına stok, taban fiyatlar, kategori eşleştirmeleri
- Gelen (pazaryerleri → ERP): müşteri siparişleri, iadeler, settlement raporları, komisyon faturaları
Üç ERP Entegrasyon Deseni
2026'da bir ERP'ye nasıl bağlandığınız, ERP'nin dönemine ve lisanslama modeline bağlıdır:
- Yerel REST/OData API'leri — modern ERP'ler (Dynamics 365, Netsuite, S/4HANA Cloud, Odoo 17+) OAuth 2.0 ile RESTful endpoint'ler sunar. Hub onları doğrudan çağırır. Bu en temiz modeldir.
- Middleware / konnektör — hibrit ERP'ler (S/4HANA on-prem, eski Dynamics, SAP Business One) için hub, RFC, SOAP veya IDoc'a çeviren bir middleware katmanı (SAP CPI, Boomi, MuleSoft veya Zunapro'nun kendi konnektörü) ile konuşur.
- Dosya tabanlı — eski ERP'ler (eski Logo, eski Mikro, özel Cobol sistemler) sıklıkla yalnızca SFTP üzerinden CSV / XML drop'ları sunar. Hub alımı zamanlar ve dosyadan kanonik olaylar üretir.
Ana Veri Yönü — Her Zaman Tek Yönlü
En yaygın ERP entegrasyon hatası, ana verinin çift yönlü akmasına izin vermektir. Bir ürün başlığı hem ERP'de hem de pazaryeri panelinde düzenlenebilirse her değişiklikte write-write çakışması alırsınız. 2026 kuralı net: ana veri ERP'den kanallara tek yönlüdür. Kanala özgü veri (Trendyol kategorisi, pazarlama metni varyantı, kanal fiyat override'ı) kanal katmanından kataloğa tek yönlüdür. Her alanın tek bir sahibi vardır.
İşlemsel Veri — Net Tetikleyicilerle Çift Yönlü
İşlemsel akışlar çift yönlüdür ancak olay tabanlıdır, durum paylaşımlı değildir. Bir pazaryeri siparişi hub'a gelir, normalleştirilir, bir order.created olayı tetikler ve pazaryerine özgü bir belge tipiyle ERP'ye satış siparişi olarak gönderilir. Sevkiyat durumu, toplama, paketleme ve sevkiyat olayları her biri ayrı bir olay olarak WMS'den ERP üzerinden pazaryerine geri akar.
💡 ERP'nizi aylar yerine günler içinde bağlayın
Zunapro'nun SAP, Dynamics, Netsuite, Odoo, Logo, Mikro ve Nebim için hazır konnektörleri standart kapsamlar için 3-7 iş gününde canlıya alınır. Özel alan eşleştirme, ana veri yönü ve olay tetikleyicileri kodlanmaz, yapılandırılır.
4. Muhasebe & e-Fatura Entegrasyonu — Uyum Katmanı
Muhasebe Neden Sadece Bir Rapor Değil
Muhasebe entegrasyonu, "geçen ay çok sattık" ile "işte her komisyonu, iadeyi ve döviz kuru düzeltmesini kaynağıyla mutabık kılınmış denetlenmiş kar-zarar tablosu" arasındaki farktır. 2026'da çoğu vergi otoritesi ikinci cevabı makine okunabilir biçimde talep ediyor. Türkiye'nin e-Fatura / e-Arşiv, Polonya'nın KSeF'i, İtalya'nın SDI'sı ve Fransa'nın PPF (Portail Public de Facturation)'si, siparişin alınmasından dakikalar sonra düzenlenmiş yapılı XML faturaların regüle edilmiş bir gateway üzerinden düzenlenmesini gerektirir.
Evrensel e-Fatura Entegrasyon Deseni
Bölgesel farklılıklara rağmen her e-fatura rejimi aynı beş adımlı deseni izler:
- Yakala — sipariş başlık, satırlar, vergi dökümü ve müşteri vergi kimliği ile OMS'ye gelir
- Oluştur — OMS, kanonik fatura nesnesini (KSeF için FA(2), e-Fatura için UBL 2.1, SDI için FatturaPA) oluşturur
- Gönder — fatura imzalanır (XAdES veya eşdeğeri) ve gateway API'sine POST edilir
- Onayla — gateway tekil bir tanımlayıcı döner (e-Fatura UUID, KSeF 10 karakter kodu, SDI alındı ID'si)
- İlişikle — tanımlayıcı siparişe işlenir; PDF temsili oluşturulup müşteriye sunulur
Türk e-Fatura / e-Arşiv 2026
Türkiye'nin e-Fatura (kayıtlı mükellefler arasında B2B) ve e-Arşiv (B2C ve kayıtsız mükelleflere B2B) rejimleri Gelir İdaresi Başkanlığı (GIB) tarafından yönetilir. 2026 eşikleri:
- e-Fatura — yıllık brüt cirosu ₺3 milyonun üzerindeki mükellefler için zorunlu, ayrıca tüm e-ticaret aracıları ve birçok sektörel liste
- e-Arşiv — e-ticaret satıcıları ve çoğu online hizmet için zorunlu; bir günlük düzenleme penceresi
- Format — UBL-TR 2.1 yapılı XML
- Özel KDV kuralları — pazaryeri tevkifat düzeltmeleri fatura başlığında yansıtılmalıdır
Çok Ülkeli Sınır Ötesi Uyum
2026'nın sınır ötesi satıcısı aynı anda birden fazla rejim arasında jonglörlük yapıyor. Allegro PL, Amazon DE ve Trendyol TR'de satış yapan tipik bir Türk KOBİ, aynı anda üç farklı e-fatura çerçevesi tetikler. Entegrasyon hub'ının yapması gerekenler:
- Alıcının ülkesini sipariş kargo adresinden ve vergi kimliği formatından tespit etmek
- Doğru e-fatura gateway'ine yönlendirme yapmak (TR için GIB, PL için KSeF, OSS değilse DE için satıcının ülke gateway'i)
- Doğru KDV oranı (Türk KDV %20, Polonya PTU %23, Alman USt %19) ve para birimini uygulamak
- OSS eşiklerini takip etmek ve sınır ötesi B2C işlemlerini satıcının üç aylık OSS beyanında raporlamak
Mutabakat ipucu: Her ödeme altyapısı komisyonu (iyzico komisyonu, Trendyol pazaryeri komisyonu, döviz marjı), temel işlemin raporlandığı gün muhasebe sistemine ayrı bir gider satırı olarak işlenmelidir. Komisyonları gelirden netlemek geçici raporları temiz gösterir ancak her denetim izini bozar. Zunapro'nun otomatik defter mutabakatını görün →
5. Lojistik & Kargo Entegrasyonu — Fiyat Karşılaştırma, Etiketler, Takip
2026'nın Çok Kargolu Gerçeği
2026'da ciddi hiçbir e-ticaret operasyonu tek kargo ile çalışmıyor. Orta segment satıcı tipik olarak 4-8 kargo entegre ediyor: bir dahili paket dolabı ağı (PL'de InPost, TR'de PTT dolapları), 2-3 yerli kargo (Türkiye'de Aras Kargo, Yurtiçi Kargo, MNG; Polonya'da DPD, GLS, DHL Parcel), 1-2 uluslararası entegratör (DHL Express, UPS, FedEx) ve pazaryerine özel hizmetler (Trendyol Express, HepsiJet, Allegro One). Her kargo kendi API'sini, kendi AWB şemasını, kendi takip-olay taksonomisini ve kendi alım rezervasyon akışını gönderir.
Fiyat Karşılaştırma — Tasarruf Yapan
Fiyat karşılaştırma (rate shopping), sipariş anında mevcut her kargodan canlı kargo fiyatları almak ve maliyet, SLA ve müşteri tarafından seçilen hizmet seviyesine göre en optimali seçme pratiğidir. İyi ayarlanmış bir fiyat karşılaştırma motoru, orta segment satıcılar için yıllık kargo harcamasından %8-18 tasarruf sağlar. 2026 fiyat karşılaştırıcısı girdi olarak şunları alır: ağırlık, boyutlar, çıkış posta kodu, varış posta kodu, beyan edilen değer, gümrük bayrağı, müşteri tarafından seçilen hizmet seviyesi; çıktı olarak şunları döner: ek ücretler ve ETA'lar ile sıralanmış kargo teklifleri.
Beş Lojistik API Operasyonu
- Fiyat sorgusu — ödeme öncesi kargo maliyeti + ETA tahmini
- Etiket üretimi — sevkiyat detaylarını POST edin, PDF/ZPL AWB etiketi + takip numarası alın
- Alım rezervasyonu — belirli bir depo + pencere için kurye alımı zamanlama
- Takip alımı — kargo takip olaylarının webhook veya polling ile alınması, kanonik bir zaman çizelgesine normalleştirilmesi
- İade etiketi — ters lojistik kodlarıyla gelen RMA etiketleri üretmek
Takip Olayı Normalleştirme
Her kargo kendi olay sözlüğünü yayınlar — OUT_FOR_DELIVERY, DAGITIMDA, EN_LIVRAISON — ancak müşteriler kargo bağımsız tek ve tutarlı bir zaman çizelgesi bekler. Entegrasyon hub'ı bunu bir kanonik olay taksonomisine normalleştirmelidir:
shipment.created— AWB üretildi, alım bekliyorshipment.picked_up— kurye depodan teslim aldıshipment.in_transit— kargo ağında hareket ediyorshipment.out_for_delivery— son kilometre aracı atandıshipment.delivered— teslim alındı imzası alındıshipment.exception— başarısız teslimat, adres sorunu, gümrük tutmasıshipment.returned— teslim edilemez, gönderene iade
6. Ödeme Altyapısı Entegrasyonu — Yetkilendirme, Yakalama, İade, Mutabakat
İki Ödeme Entegrasyon Akışı
2026'da ödeme altyapısı entegrasyonunun iki farklı boyutu var. Birincisi müşteriye dönük yetkilendirme akışı: ödeme sayfasında alışveriş yapan kart bilgilerini girer (veya BLIK / Apple Pay / Google Pay / cüzdan seçer), gateway 3DS2 ile doğrular, bir işlem token'ı döner ve OMS işlemi yakalar veya tutar. İkincisi arka ofis mutabakat akışı: gün sonunda gateway, temizlenen her yüklemeyi, kesilen komisyonu ve döner rezervi listeleyen bir settlement dosyası (CSV, MT940 veya tescilli JSON) gönderir. Hub her settlement satırını kaynak siparişiyle eşler ve net tutarı muhasebeye işler.
Çoklu-PSP Yönlendirme
Çoğu orta segment satıcı, dayanıklılık ve kart BIN'ine göre yetkilendirme oranlarını optimize etmek için 2-4 ödeme hizmeti sağlayıcı entegre eder. Tipik 2026 stack'i:
- iyzico veya PayTR — Türk ihraç kartlar için birincil acquirer (yetkilendirme oranı %92-95)
- Stripe veya Adyen — uluslararası kartlar, çoklu para birimi, AB SCA-hazır
- Yerel cüzdanlar — Apple Pay, Google Pay, Masterpass, Papara
- BNPL — Klarna, Allegro Pay, Stripe Capital, Sipay Taksit
OMS, kart BIN'i, para birimi, müşteri coğrafyası ve sepet büyüklüğü göz önünde bulundurarak her işlemi yetkilendirme olasılığı en yüksek PSP'ye yönlendirir. PSP 1'deki başarısız yetkilendirmeler 200 ms içinde "yeniden deneme" için PSP 2'ye kademe iner — aksi takdirde kaybedilecek siparişlerin %3-7'sini kurtaran bir desen.
Settlement Mutabakatı — Gizli Ağır Yük
Ödeme entegrasyonunun en az tahmin edilen parçası settlement mutabakatıdır. Bir PSP, tipik bir günlük yüklemeyi T+1 veya T+2 gün sonra bir veya iki batch'te, komisyonlar, döner rezerv ve chargeback'ler düşülerek settle eder. Entegrasyon hub'ı şunları yapmalıdır:
- Günlük settlement dosyasını alır (format değişir; iyzico CSV, PayTR JSON, Stripe Reports API, Adyen Sales Day Report)
- Her settlement satırını işlem referansı üzerinden kaynak siparişiyle eşler
- Brüt tutarı siparişe, komisyonu "PSP komisyonu" gider GL'sine, neti banka hesabına işler
- Uyumsuzlukları (yetim yüklemeler, eksik settlement'lar, komisyon farkları) insan incelemesi için işaretler
- Orijinal işlemlere anahtarlanmış bir chargeback / iade zaman çizelgesi sürdürür
💳 Çoklu-PSP yönlendirme ve mutabakat, kutudan çıkmış
Zunapro; iyzico, PayTR, Stripe, Adyen ve Mollie için yerel konnektörler sunar. Çoklu acquirer yönlendirme, settlement eşleştirme, iade üzerine refund ve GL kaydı tamamen otomatik gerçekleşir.
7. Sipariş Yönetim Sistemi (OMS) — Operasyonel Beyin
OMS Gerçekten Ne Yapar
OMS mimarinin merkezinde oturur ve sipariş yaşam döngüsünü "alındı"dan "settle edildi"ye kadar sahiplenir. Her kanaldan siparişleri alır, kanonik bir şemada saklar, envanteri tahsis eder, hangi deponun hangi satırı karşılayacağına karar verir, gerektiğinde sevkiyatları böler, WMS'de toplama ve paketlemeyi tetikler, e-fatura düzenler, kargo etiketleri sipariş eder, ödemeleri yakalar ve müşteri hizmetlerine tek bir sipariş zaman çizelgesi sunar. Gerçek bir OMS olmadan bunların her biri bağlantısız araçlar arasında manuel bir dikiş haline gelir.
OMS Durum Makinesi
Modern bir OMS sipariş başına deterministik bir durum makinesi sunar. Tipik durumlar:
received— sipariş kanaldan geldi, doğrulama bekliyorvalidated— dolandırıcılık kontrolü geçti, vergi yeniden hesaplandı, envanter rezerve edildiallocated— depo ve sevkiyat planı belirlendipicking— WMS'de toplama görevi oluşturuldupacked— ürünler paketlendi, AWB talep edildishipped— kargoya teslim edildi, takip aktifdelivered— kargo tarafından teslim alındı imzası kaydedildicompleted— iade penceresi kapandı, gelir tanındıcancelled/refunded— iade işlenmiş terminal durumlar
Her geçiş, diğer sistemlerin tüketebileceği bir alan olayı yayınlar — shipped tetiklendiğinde muhasebe kayıt atar, delivered tetiklendiğinde müşteri pazarlaması "teşekkürler" gönderir, BI her durumda dönüşüm hunisini günceller.
Envanter Tahsis Stratejileri
Birden fazla depoya sahip bir OMS, hangi deponun hangi siparişi karşılayacağına karar vermelidir. Yaygın stratejiler:
- Müşteriye en yakın — teslimat süresini ve kargo maliyetini minimize edin (B2C için varsayılan)
- En yüksek stok öncelikli — ölü stoğu azaltmak için yavaş satanları konsantre tutun
- Kanala sabitlenmiş — Amazon siparişleri için Amazon FBA stoğu, Amazon dışı için pazaryeri FBM stoğu
- Maliyet optimize — en düşük birleşik toplama + sevkiyat maliyetli depoyu seçin
- Bölünmüş sevkiyat — tek bir depo tüm satırlara sahip değilse, akıllıca bölün ve müşteriyi bilgilendirin
8. Birleşik Ürün Kataloğu — Bir SKU, Çok Kanal
Katalog Temeldir
Diğer her entegrasyon katmanı birleşik bir ürün kataloğuna bağlıdır. Aynı fiziksel SKU üç kez var olursa — bir kez ERP'de, bir kez Shopify'da, bir kez pazaryeri panelinde — diğer her entegrasyon onları senkronda tutmak için savaşır. 2026 mimarisi, kanala özgü eşleştirmeleri türetilmiş özellikler olarak tutan tek bir ana katalog konusunda ısrarcıdır.
Ana Özellikler vs Kanal Özellikleri
Katalog modeli iki tür özelliği ayırt eder:
- Ana özellikler — SKU, GTIN/barkod, boyutlar, ağırlık, menşe ülke, tehlikeli madde bayrağı, marka. Bir kez ayarlanır, her yerde kullanılır.
- Kanal özellikleri — Trendyol categoryId, Amazon ASIN + browse node, Hepsiburada productId, pazaryerine özgü pazarlama başlığı. Kanal başına ayarlanır.
Bir ana özelliğe değişiklik (örneğin tedarikçinin paketlemeyi değiştirmesi nedeniyle boyutları güncellemek) otomatik olarak her kanala yayılır. Bir kanal özelliğine değişiklik (örneğin SEO için Trendyol başlığını ince ayarlamak) o kanala kapsanır ve diğerlerini kirletmez.
Kategori Eşleştirme — En Zor Problem
Her pazaryeri sıklıkla 10.000+ yaprağa kadar derin farklı bir kategori ağacı tutar. 5.000 SKU'luk bir kataloğu Trendyol + Hepsiburada + Amazon + Allegro kategorilerine manuel olarak eşlemek haftalarca insan emeği alır ve pazaryerleri ağaçlarını yeniden düzenledikçe zamanla bozulur. Zunapro dahil modern entegrasyon platformları ML destekli kategori eşleştirme kullanır: model, başlık, marka, özellikler ve etiketli bir eğitim setine dayanarak her SKU için en olası hedef kategoriyi önerir ve operatör tek tıkla onaylar. İlk geçişte doğruluk genellikle %92-96'dır; geri kalan birkaç yüzde manuel ilgi alır.
Kanallar Arası Stok Tahsisi
Bir fiziksel SKU + on kanal = aynı anda onu satmaya çalışan on yer. Stok tahsis kuralları, her kanalın herhangi bir anda eldeki miktarın ne kadarını satabileceğine karar verir:
- Paylaşılan havuz — her kanal tam depo stoğunu görür; aşırı satış saniye altı senkronla önlenir (senkronunuz yeterince hızlıysa işe yarar)
- Kanal tamponu — senkron gecikmesini emmek için her kanalda her zaman 1-2 birim rezerve tutun
- Kanal kotası — kanal başına sabit tahsis (örneğin %60 Trendyol, %30 Hepsiburada, %10 kendi mağaza) — pazarlama temposu için faydalı
- Kademeli görünürlük — yüksek marjlı kanallarda tam stok, komisyon ağırlıklı olanlarda kısıtlı stok gösterin
9. iPaaS vs Özel Geliştirme — 2026'da Doğru Seçim
Özel Entegrasyonun Toplam Maliyeti
Yaygın bir 2020 varsayımı — "mühendislerimiz var, kendimiz yaparız" — 2026'da haklı çıkarmak daha zor hale geliyor. Tipik orta segment entegrasyon kapsamı (5 pazaryeri + 1 ERP + e-fatura + 3 kargo + 2 PSP + WMS) için gerçekçi bir kur ve sürdür bütçesi şöyle görünüyor:
- İlk geliştirme — 6-9 ay × 2 backend mühendis + 1 PM = yaklaşık $220K-$340K tam yüklü maliyet
- Sürekli bakım — API değişikliklerini, yeni pazaryeri özelliklerini, regülasyon güncellemelerini emmek için sonsuza kadar 1,5-2 FTE
- Fırsat maliyeti — bu mühendisler ürün farklılaşması üzerinde çalışmıyor
- Risk primi — özel entegrasyon projelerinin %60-70'i orijinal zaman çizelgesini >%30 kaçırır (sektör kıyaslaması)
iPaaS / Birleşik Platform Alternatifi
Zunapro gibi birleşik bir ticaret entegrasyon platformu şunları sağlar:
- 60+ sistem için önceden inşa edilmiş, savaşta test edilmiş konnektörler
- Kanonik şema ve olay yönlendiricisi dahil
- Gözlemlenebilirlik, retry, idempotency ve circuit-breaker'lar kutudan çıkmış
- API kırıcı değişimlerin satıcı tarafından sürekli emilmesi
- SLA destekli uptime (%99.95-99.99)
Üç yıllık ufukta, birleşik platform yolunun TCO'su eşdeğer kapsam için özel geliştirmeden tipik olarak 4-7 kat daha düşüktür, üstelik önemli ölçüde daha hızlı değer üretir.
Karar Çerçevesi — Ne Zaman Geliştirmek, Ne Zaman Satın Almak
10. Güvenlik, Gözlemlenebilirlik ve Devreye Alma Planı
Güvenlik — Tartışmasız Olanlar
Bir entegrasyon hub'ı işlettiğiniz her sistem için API kimlik bilgilerini tutar. Hub'ın ele geçirilmesi, tüm operasyonun ele geçirilmesidir. 2026'nın tartışmasız gereklilikleri:
- Şifrelenmiş kimlik bilgisi vault'u — API anahtarları ve sırlar HSM destekli ana anahtarlarla durağan halde şifrelenmiş olarak saklanır; asla düz konfigürasyon dosyalarında değil
- Kiracı başına kimlik bilgisi izolasyonu — çok kiracılı platformlar A kiracısının kimlik bilgilerinin bir kod hatası yoluyla bile B kiracısı tarafından okunamayacağını garanti etmelidir
- Refresh rotasyonlu OAuth 2.0 — uzun ömürlü API anahtarları geride kaldı; rotasyonlu kısa ömürlü token'lar geliyor
- Webhook imza doğrulama — her gelen webhook HMAC imzalıdır; doğrulanmayan herhangi bir payload'u reddedin
- Rate-limit'li admin endpoint'leri — doğrulama denemeleri kapaklı, IP izin listeleri opsiyonel
- Denetim kaydı — her kimlik bilgisi dokunuşu, her katalog değişikliği, her sipariş düzenlemesi aktör + zaman damgası ile kaydedilir
- SOC 2 / ISO 27001 — finansal işlem işleyen herhangi bir platform için temel gereklilik
Gözlemlenebilirlik — Göremediğinizi İşletemezsiniz
Üretim entegrasyonu gözlemlenebilirlik olmadan imkansızdır. Minimum 2026 kurulumu:
- Yapılı log'lar — JSON formatlı, her sistem hop'unda yayılan correlation-id
- Dağıtık trace'ler — bir olayın pazaryeri → hub → ERP → e-fatura → muhasebe yolunu gösteren OpenTelemetry span'ları
- Metrik dashboard'ları — RPS, konnektör başına p50/p95/p99 gecikme, hata oranı, kuyruk derinliği
- Uyarılar — konnektör >5 dk kapalı, hata oranı >%1, kuyruk derinliği büyüyor, settlement dosyası eksik durumlarında çağrılar
- Replay yeteneği — her webhook payload'u arşivlenir ve son 30 gün için yeniden oynatılabilir
- SLO / hata bütçesi — üç aylık inceleme ile yayımlanmış SLO'lar
2026 Devreye Alma Planı — Adım Adım
Zunapro'da orta segment bir satıcı için tipik entegrasyon devreye alma:
- Hafta 1 — Keşif ve eşleştirme: mevcut sistemlerin envanteri, sahiplerin belirlenmesi, mevcut API'lerin listesi, güncel sorunların belgelenmesi
- Hafta 2 — Katalog konsolidasyonu: ERP'yi bağlayın, ana SKU'ları Zunapro'nun kanonik kataloğuna içe aktarın, dedup ve barkod doğrulaması çalıştırın
- Hafta 3 — Pazaryeri bağlantıları: en üst 1-2 pazaryerini bağlayın, kataloğu yansıtın, fiyat + stok akışını uçtan uca doğrulayın
- Hafta 4 — e-Fatura + muhasebe: e-Fatura/e-Arşiv gateway'ini ve muhasebe sistemini bağlayın, test siparişlerinde UBL çıktısını doğrulayın
- Hafta 5 — Lojistik & ödemeler: kargoları bağlayın, fiyat karşılaştırmayı yapılandırın, PSP'leri bağlayın, iade akışını doğrulayın
- Hafta 6 — OMS iş akışları: sipariş durumlarını, tahsis kurallarını, iade politikalarını yapılandırın; müşteri hizmetleri ekibini eğitin
- Hafta 7 — Yumuşak lansman: trafiğin %10'unu yönlendirin, metrikleri gözlemleyin, kenar durumları düzeltin
- Hafta 8 — Tam geçiş: yeni stack'te %100 trafik, eski noktadan noktaya script'leri devre dışı bırakın
- Hafta 9 ve sonrası — Genişleme: sürdürülebilir bir tempoda ek pazaryerleri, ek kargolar, sınır ötesi kanallar ekleyin
Her sistemi tek panelde merkezîleştirin — 10 dakikada başlayın
Pazaryerleri + ERP + e-Fatura + muhasebe + lojistik + ödemeler — Zunapro tüm e-ticaret operasyon stack'ini orkestre eder. Hazır konnektörler, idempotent olaylar, SLA destekli uptime, noktadan noktaya script yok.
Şimdi Entegrasyona Başla →2026 Entegrasyon Yaklaşımı Karşılaştırması — Yan Yana
Bir entegrasyon yaklaşımı seçmek için en faydalı tek artefakt yan yana bir puan kartıdır. Aşağıdaki tablo, orta segment satıcılar için önemli olan boyutlara karşı 2026'nın baskın üç desenini özetler.
| Boyut | Özel Geliştirme | Jenerik iPaaS | Birleşik Ticaret Platformu |
|---|---|---|---|
| İlk pazaryeri canlıya alma süresi | 3-6 ay | 4-8 hafta | 10 dakika - 1 gün |
| Pazaryeri API kırıcı değişimleri | Sonsuza dek size ait | Konnektör satıcısı yamalar | Platform sessizce emer |
| e-Fatura / KSeF / e-Fatura hazır | Sıfırdan geliştir | Eklenti olarak mevcut | Yerel, dahil |
| 3 yıllık TCO (orta segment kapsam) | $800K-$1.4M | $180K-$340K | $60K-$160K |
| Operasyonel uptime SLA | Kendi kendine yönetilen | Tipik %99.9 | %99.95-99.99 |
| Gereken alan bilgisi | Yüksek — her katman | Orta — iş akışları | Düşük — yapılandırma |
| En uygun | Hiperölçek, benzersiz IP | Sektörler arası kullanım | Orta segment e-ticaret |
Tabloyu okumak: 2026 orta segment e-ticaret operasyonlarının %90'ı için birleşik platform yolu hız, TCO ve güvenilirlik konusunda en iyi karışımı sunar. Özel geliştirme yalnızca entegrasyon mimarisinin kendisi rekabet avantajı olduğunda uygundur — ki pazaryeri operatörü için bu neredeyse hiç olmaz.
E-Ticaret Entegrasyonu SSS 2026
2026'da e-ticaret sistem entegrasyonu gerçekte ne anlama geliyor?
2026'da e-ticaret sistem entegrasyonu; pazaryerleri, ERP, muhasebe, WMS, lojistik kargo firmaları, ödeme altyapıları, CRM, BI gibi tüm operasyonel araçları tek, olay tabanlı bir veri dokusuna bağlamak demektir. Böylece tek bir ürün, tek bir stok birimi ve tek bir sipariş her yerde aynı varlık olur.
Modern entegrasyon API öncelikli (REST + GraphQL + webhook), idempotent, gözlemlenebilir ve aylar içinde birbirinden uzaklaşan noktadan noktaya script'ler yerine Zunapro gibi bir iPaaS ya da birleşik ticaret platformu üzerine kuruludur.
iPaaS, ESB ve middleware arasındaki fark nedir?
ESB (Enterprise Service Bus), 2000'lerden kalma eski, şirket içi entegrasyon modelidir. Middleware, sistemler arasındaki herhangi bir yapıştırıcı yazılım için kullanılan genel bir terimdir. iPaaS (Integration Platform as a Service), 2026'nın bulut yerel halefidir: çok kiracılı, az kodlu, hazır konnektörler, olay akışı ve gözlemlenebilirlik içerir.
Zunapro gibi birleşik ticaret platformları, iPaaS altyapısını siparişler, SKU'lar, vergiler ve iadeler gibi yerel e-ticaret iş mantığıyla birleştirerek bir adım daha ileri gider; böylece her kavramı sıfırdan modellemek zorunda kalmazsınız.
Pazaryerlerini ERP sistemime nasıl entegre ederim?
2026'nın en iyi pratiği hub-and-spoke (yıldız) mimarisidir. Her pazaryerini (Trendyol, Hepsiburada, Amazon, eBay, Etsy, Allegro vb.) REST API'leri üzerinden merkezi bir entegrasyon merkezine bağlayın. Hub; siparişleri, ürünleri ve stokları kanonik bir şemaya normalleştirir ve bunları ERP'ye (SAP, Microsoft Dynamics 365, Netsuite, Odoo, Logo, Mikro, Nebim) kendi API'si veya middleware aracılığıyla iletir.
Stok ve fiyat güncellemeleri ters yönde webhook'lar veya 1-15 dakikalık pull işleri ile akar. Zunapro, büyük Türk ve global ERP'ler için hazır konnektörler sunar, böylece ilk gün entegrasyonu özel kod değil yapılandırma haline gelir.
Sipariş Yönetim Sistemi (OMS) nedir ve gerçekten gerekli mi?
Sipariş Yönetim Sistemi; her kanaldan siparişleri toplayan, envanteri tahsis eden, sevkiyatları depolar arasında bölen, toplama ve paketlemeyi tetikleyen ve müşteri hizmetlerine tek bir sipariş zaman çizelgesi sunan operasyonel beyindir.
İkiden fazla kanalda satış yapıyor, birden fazla depo işletiyor veya günde 50'den fazla sipariş işliyorsanız OMS zorunlu hale gelir — alternatif, elektronik tablolarda günlük insan mutabakatıdır. Zunapro'nun sipariş modülü aynı panelde tam bir OMS artı pazaryeri konnektörleri sunar, böylece "ayrı bir OMS satın alma" gereği yoktur.
Pazaryerleri arasında gerçek zamanlı stok senkronizasyonu nasıl çalışır?
Gerçek anlamda gerçek zamanlı stok senkronu üç katman kullanır: (1) her sipariş, iade veya depo düzeltmesi ile tetiklenen bir olay tabanlı push, (2) webhook kaçırmalarını yakalayan kısa aralıklı bir mutabakat işi (genelde 1-5 dakika) ve (3) tam pazaryeri kataloğu anlık görüntülerine karşı yavaş 12-24 saatlik bir kayma düzeltme taraması.
SKU ve barkod eşleştirme tekilleştirmenin anahtarlarıdır; mükerrer listelerdeki en düşük stok değeri gerçeğin kaynağıdır. Bu üç katman olmadan, yalnızca webhook katmanı ne kadar akıllı olursa olsun, ölçekte aşırı satış matematiksel olarak kaçınılmazdır.
Birleşik ürün kataloğu nedir ve neden önemlidir?
Birleşik ürün kataloğu, her kanalın okuduğu tek bir ana SKU tablosudur. Her pazaryeri eşleştirmesi (Trendyol categoryId, Amazon ASIN, Hepsiburada productId) ayrı bir ürün değil, türetilmiş bir özelliktir.
Bu, mükerrer bakımı ortadan kaldırır, fiyatlandırma kurallarını deterministik yapar ve tek bir içerik değişikliğini (başlık, görsel, açıklama) saniyeler içinde onlarca kanala yaymanızı sağlar. Bu olmadan içerik kayması kaçınılmazdır ve marka tutarlılığı aylar içinde ölür.
2026'da ödeme altyapıları stack'in geri kalanıyla nasıl entegre olur?
Ödeme altyapıları (iyzico, PayTR, Stripe, Adyen, Mollie, PayU) iki akışla entegre olur. Müşteriye dönük akış, yetkilendirme için hosted-pages ya da 3DS2 yönlendirme kullanır ve OMS'ye bir işlem token'ı döner. Mutabakat akışı ise webhook'lar ile birlikte günlük settlement dosyalarını (CSV/MT940) kullanarak yüklemeleri siparişlere, komisyonları muhasebeye, iadeleri iade işlemlerine eşler.
İşlem başına PSP komisyonları muhasebe sistemine gider satırı olarak işlenmelidir, gelirden netlenmemelidir; aksi takdirde gelir raporlaması gerçekten kayar ve her denetim aynı konuşmayı yeniden açar.
Tam bir e-ticaret entegrasyon projesi ne kadar sürer?
Zunapro gibi birleşik bir platformla: tek kanallı KOBİ kurulumu için 1-2 hafta, çok pazaryerli + ERP + muhasebe stack'i için 4-6 hafta, özel iş akışları ve SAP/Dynamics içeren kurumsal seviye için 8-12 hafta.
Özel noktadan noktaya geliştirmeyle: 4-9 ay ve sektör kıyaslamalarına göre %60-70 bütçe aşımı olasılığı. Birleşik platform yolu 2026'da neredeyse her zaman daha ucuz ve daha güvenilirdir.
Webhook'lar nedir ve polling'den farkı nedir?
Webhook'lar push bildirimleridir: kaynak sistemde bir olay gerçekleştiğinde (yeni sipariş, stok değişikliği, ödeme yakalama), payload'u sizin endpoint'inize HTTP POST olarak gönderir. Polling pull'dur: sisteminiz kaynaktan her N saniyede bir bir şeyin değişip değişmediğini sorar.
Webhook'lar daha düşük gecikme süresi (milisaniye - dakika) ve daha düşük bant genişliği sağlar ancak idempotent bir alıcı, retry toleransı ve kaçırılan olaylar için yeniden oynatma yeteneği gerektirir. 2026'nın en iyi pratiği birincil yol olarak webhook'lar artı güvenlik ağı olarak polling kullanmaktır.
Lojistik firmalarını ve etiket basmayı aynı panele entegre edebilir miyim?
Evet. Modern lojistik entegrasyonu, fiyat almak, AWB etiketi üretmek, takip olayları göndermek ve alım talep etmek için kargo API'lerini (Aras Kargo, Yurtiçi Kargo, MNG, PTT, UPS, DHL, FedEx, Trendyol Express, HepsiJet) kullanır.
Çoklu kargo etiket basımı, ağırlık / varış noktası / SLA bazında otomatik fiyat karşılaştırması ve sipariş başına tek bir takip zaman çizelgesi her 2026 OMS için temel gerekliliklerdir. Zunapro, tüm büyük Türk kargo firmaları ve global entegratörler için yerel konnektörler sunar.
E-fatura (e-Fatura, KSeF, SDI) uyumu pazaryerleriyle nasıl entegre olur?
E-fatura uyum çerçeveleri — Türkiye'de GIB üzerinden e-Fatura / e-Arşiv, Polonya'da KSeF, İtalya'da SDI, Fransa'da PPF — siparişin alınmasından sonra dar bir pencere içinde düzenlenmiş yapılı XML faturaların regüle edilmiş bir gateway üzerinden düzenlenmesini gerektirir.
Entegrasyon deseni ülke fark etmeksizin aynıdır: pazaryeri siparişi OMS'ye gelir, OMS sipariş başlığı + satırları + vergi dökümü ile e-fatura sağlayıcısı API'sini çağırır, gateway bir UUID / tanımlayıcı döner ve bu tanımlayıcı siparişe ve sevkiyata iliştirilir. Zunapro bunu Türk e-Fatura / e-Arşiv için otomatikleştirir ve 2026'da Polonya pazarı için KSeF'i devreye almaktadır.
Idempotency nedir ve sipariş entegrasyonu için neden önemlidir?
Idempotency, bir işlemin kaç kez çalıştırılırsa çalıştırılsın aynı sonucu üretmesi anlamına gelir. Entegrasyonda her sipariş içe aktarma, stok güncelleme ve ödeme yakalama endpoint'i çağırandan tekil bir idempotency anahtarı kabul etmelidir; aynı anahtar iki kez geldiğinde (bir retry, mükerrer bir webhook, ağ aksaklığı nedeniyle), alıcı mükerrer bir kayıt oluşturmak yerine orijinal sonucu döner.
Idempotency anahtarları olmadan pazaryeri entegrasyonu sessizce mükerrer siparişler, çift çekimler ve hayalet stok üretir — ve bunu yalnızca haftalar sonra mutabakatta keşfedersiniz. Zunapro'daki her endpoint tasarım gereği idempotent'tir.
Kendi entegrasyon katmanımı mı geliştirmeliyim yoksa bir platform mu kullanmalıyım?
2026'da yalnızca e-ticaret entegrasyonu rekabet avantajınız ise geliştirin (nadir). Aksi halde satın alın. 5 pazaryeri + ERP + muhasebe + 3 kargo + 2 ödeme altyapısı için tipik özel bir entegrasyon katmanı 6-9 ayda geliştirilir, sonsuza kadar 1,5-2 FTE bakım gerektirir ve 3 yıllık ufukta eşdeğer SaaS aboneliğinin 4-7 katına mal olur.
Zunapro gibi birleşik platformlar, her API kırıcı değişimini, her yeni pazaryeri kategorisini, her regülasyon güncellemesini emer — aksi halde tüm bir mühendislik ekibini kalıcı olarak tüketecek ve sıfır rekabet farklılığı üretecek bir iştir bu.
Sınır ötesi entegrasyonda çoklu para birimi, çoklu vergi ve döviz kurunu nasıl yönetirim?
Tüm parasal değerleri iki sütunda saklayın: orijinal para birimi + ana/raporlama para birimi, ayrıca dönüşüm anının döviz kuru ve zaman damgası. ECB veya TCMB günlük kurlarını çekin ve geçmiş siparişlerin tam olarak yeniden üretilebilmesi için sipariş alındığı anda anlık görüntü alın.
Vergi hesaplaması varış ülkesi farkındalıklı olmalıdır (AB OSS kuralları, Türkiye KDV, ABD satış vergisi nexus) ve hem ödeme sayfasının hem de muhasebenin çağırdığı bir hizmet olarak izole edilmelidir. Tek bir sütunda para birimlerini karıştırmak, sınır ötesi muhasebe entegrasyonlarının başarısız olmasının en yaygın nedenidir — hata, çeyrek sonu döviz yeniden değerlemesi gelene kadar görünmezdir.
Zunapro hem Türk hem uluslararası pazaryerlerini destekliyor mu?
Evet. Zunapro; Türk pazaryerleri (Trendyol, Hepsiburada, N11, Çiçeksepeti, PttAvm, Pazarama) ve uluslararası olanlar (Amazon, eBay, Etsy, Allegro, Emag, Bol.com) için yerel konnektörler sunar; bunlara ek olarak DTC platformlar (Shopify, WooCommerce, BigCommerce, Magento, PrestaShop) için de konnektörler vardır.
Tüm kanallar tek bir kanonik katalog ve OMS'yi besler, böylece Türk bir satıcıdan Polonya veya Alman bir pazaryerine sınır ötesi genişleme platform değişikliği gerektirmez — yalnızca yeni konnektörü açmak ve kategori eşleştirmeyi onaylamak yeterlidir.
Her e-ticaret sistemini tek panelde bağlayın — 10 dakikada başlayın
Pazaryerleri · ERP · e-Fatura · muhasebe · lojistik · ödemeler — tek kanonik katalog, tek olay tabanlı hub, tek operasyon paneli. Noktadan noktaya script yok, aylar süren projeler yok. Birleşik entegrasyon mimarinizi bugün başlatın.
🚀 Birleşik Entegrasyonu Şimdi Başlat →Bu konuda yardım alın
İlgili hizmetimiz: Pazaryeri